GESTION DE LA CHAÎNE LOGISTIQUE LOGICIELLE – PARTIE 4

Maîtriser les notions de base

Les équipes d’ingénierie doivent réduire les risques de sécurité, maintenir l’intégrité et la santé des logiciels tout en améliorant le flux de développement. Maintenant que nous avons compris ce qu’est une chaîne logistique logicielle et à quelles mutations le secteur est soumis, il est temps de se demander comment tout ceci s’articule avec la gestion de la chaîne logistique logicielle.

Récapitulation des directives de la chaîne logistique

Pour orienter notre propos, nous allons utiliser l’analyse de la chaîne logistique de fabrication exposée dans la partie 1 et les quatre principes de Deming, qui concernent à la fois les chaînes logistiques de fabrication et les chaînes logistiques logicielles. 

Rappelons ces principes et voyons comment ils s’appliquent au développement de logiciels : 

  • 1. Faire appel à de meilleurs fournisseurs et en choisir moins 
  • 2. Utiliser des composants de haute qualité provenant de ces fournisseurs 
  • 3. Corriger les défauts tôt, et ne jamais laisser les défauts connus se propager en aval
  • 4. Créer un processus transparent et suivre l'utilisation des composants

partie 4.1

Expliquons maintenant comment tout cela s’applique au processus de développement logiciel

La nécessité de l’automatisation continue

Non sans difficultés, le secteur et le monde sont en passe de reconnaître le volume de consommation des composants et l’écosystème colossal de fournisseurs auprès desquels vous pouvez vous approvisionner. Il est probable qu’il subsiste toujours une part de vérification manuelle, mais le volume extrême d’artefacts rend impossible d’examiner leur état de santé de cette façon. Quel que soit l’aspect de la chaîne logistique logicielle sur lequel vous vous penchez, la résolution des problèmes à grande échelle suppose l’automatisation. En refusant d’adopter ces pratiques, les entreprises sont probablement vouées à l’échec.

Dans le passé, les chaînes logistiques de fabrication ont adopté l’automatisation, et les équipes de développement logiciel doivent aujourd’hui suivre le même chemin. Les informations sur les fournisseurs et sur la qualité et la sécurité de leurs projets doivent être mises à la disposition des développeurs au moment où ils sélectionnent les composants et de façon continue tout au long du cycle de développement. Elles doivent être régulièrement mises à jour une fois l’application en production. 

L’automatisation au niveau des tests, du développement proprement dit et du déploiement a permis d’obtenir une amélioration significative des performances. De la même façon, les investissements réalisés dans l’automatisation de la chaîne logistique logicielle ont permis d’améliorer l’efficacité et de mieux contrôler les risques. L’automatisation peut libérer le potentiel de développement d’une organisation. Une telle occasion d’augmenter simultanément la vitesse, l’efficacité, la sécurité et la qualité est rare.

Quel que soit l’aspect de la chaîne logistique logicielle sur lequel vous vous penchez, la résolution des problèmes à grande échelle suppose l’automatisation.

1. Faire appel à de meilleurs fournisseurs et en choisir moins

Comme pour la fabrication, tous les fournisseurs ne fournissent pas de composants de qualité et d’intégrité comparables. Des études ont montré que certains projets open source utilisent des licences restrictives et des sous-composants vulnérables, et que certains projets mettent globalement à jour la qualité de leurs composants de façon beaucoup plus consciencieuse que d’autres. Pourtant, on fait souvent peu de cas de savoir qui crée réellement les composants open source qu’un développeur est sur le point d’utiliser.

Et enfin, il faut savoir que le nombre de fournisseurs de composants est tout simplement dur à se représenter. Dans le rapport sur l’état de la chaîne logistique logicielle en 2020, nous avons constaté que les grandes entreprises de développement téléchargeaient en moyenne 373 000 composants open source par an, et que ces téléchargements correspondaient en moyenne à 3 552 projets open source (ou fournisseurs).

partie 4.9

Contrairement aux fournisseurs physiques utilisés dans les chaînes logistiques traditionnelles, une fois qu’un projet open source est publié, il n’est jamais retiré de la circulation. Cela signifie que les développeurs peuvent continuer à utiliser par inadvertance des projets devenus obsolètes, y compris ceux d’entre eux qui ont été complètement abandonnés par leurs mainteneurs.

Un examen des équipes qui se cachent derrière ces projets peut vous faire gagner beaucoup de temps et vous épargner de nombreux efforts.

Processus de contrôle des fournisseurs et évaluation de la santé du projet 

Pour les entreprises, le choix d’un projet open source doit être considéré comme une décision stratégique importante. Changer de fournisseur (projet open source) représente un effort bien plus important que d’échanger un simple composant pour un autre. Comme pour les fournisseurs traditionnels, les projets open source ont de bonnes et de mauvaises pratiques, avec des conséquences sur la qualité globale de leurs composants.

Les chaînes logistiques de fabrication traditionnelles sélectionnent intentionnellement des composants spécifiques auprès de fournisseurs approuvés. Elles s’appuient également sur des pratiques d’approvisionnement formalisées. Cette façon de faire a généralement tendance à restreindre le nombre de fournisseurs.

Introduire cette pratique dans le développement améliore la qualité. Le développeur n’a pas besoin de jongler incessamment entre les tâches, les changements de contexte sont moins fréquents, et il peut se concentrer sur un nombre restreint de sujets. Cela accélère également le « mean time to repair » lorsque des défauts sont découverts.

Automatio_animated-wide

Les équipes de développement s’appuient encore souvent sur une palette non restreinte de ressources qui offrent une totale liberté à chaque développeur ou équipe de développement en matière d’approvisionnement. Devoir gérer ces 3 552 projets peut nuire considérablement à l’efficacité et à la rapidité des développeurs, des critères essentiels dans toute démarche agile, de DevOps ou de livraison continue. 

De nombreuses équipes préfèrent recourir à des projets logiciels connus par leur équipe ou qui sont les plus populaires dans une catégorie donnée. L’analyse des fournisseurs dans notre rapport 2021 a montré que la popularité était un mauvais indicateur de qualité, 29 % des projets populaires contenant au moins une vulnérabilité de sécurité connue. Pour les projets dont la popularité était moindre, la moyenne était de seulement 6,5 %. Que cela soit dû à une plus grande vigilance des chercheurs en sécurité ou à d’autres facteurs, le fossé qui existe entre les deux chiffres mérite d’être expliqué.

Une analyse des fournisseurs populaires en 2021 a indiqué que la popularité était un mauvais indicateur de la qualité.

Nos informations suggèrent qu’il faut se focaliser sur un petit nombre d’indicateurs clés, notamment :

  • 1. Une meilleure hygiène de mise à jour. Le délai moyen de mise à jour (MTTU) correspond au temps moyen nécessaire à la mise à jour d’un projet lorsque de nouvelles versions de ses dépendances sont disponibles. 
  • 2. La maturité du projet. Un projet dont le développement est actif depuis plusieurs années est plus susceptible d’être stable.
  • 3. Le nombre de mainteneurs. Avoir un nombre suffisant de personnes chargées de la maintenance est fondamental. 
  • 4. La fréquence des nouvelles versions. Dans les projets bien gérés, le code est plus souvent archivé et de nouvelles version sont publiées plus fréquemment. 
  • 5. La sécurité (mesurée par des taux de vulnérabilités plus faibles).

partie 4.10

Tenir compte de ces caractéristiques vous permettra de simplifier votre recherche de projets open source software de meilleure qualité et augmentera considérablement l’hygiène de votre chaîne logistique logicielle, ce qui aura également pour effet de réduire la dette technique et les freins à l’innovation.

CE QU’IL FAUT RECHERCHER : des projets gérés par un groupe de développeurs motivés et réactifs, qui suivent un ensemble de directives de contribution claires et concrètes et qui disposent d’une communauté active dont les membres contribuent régulièrement à améliorer le code source.

CE DONT IL FAUT SE MÉFIER : les projets qui n’ont pas été mis à jour depuis des années, en particulier ceux avec un seul ou deux mainteneurs qui n’interagissent pas vraiment avec les utilisateurs ou qui sont peu impliqués. Un projet qui ne comprend qu’un seul commit est susceptible de résoudre un problème à court terme, mais il peut être source d’ennuis pour le futur.

2. Utiliser des composants de haute qualité provenant de ces fournisseurs

Maintenant que vous avez choisi un fournisseur, vous allez peut-être penser que le plus dur est fait. La qualité des composants utilisés pour construire une machine détermine le bon ou le mauvais fonctionnement de ladite machine. Il en va de même pour le développement logiciel : certains composants sont meilleurs que d’autres, même s’il proviennent de fournisseurs jugés fiables. 

Certains acteurs du secteur parlent de « contrôle des versions ». Pour notre part, nous préférons le terme « gestion des dépendances » (et plus spécifiquement la gestion des microdépendances, que nous aborderons plus tard). 

Il existe trois raisons pour lesquelles la gestion des dépendances (ou le « contrôle des versions ») devient une pratique incontournable dans la gestion des chaînes logistiques logicielles :

  • 1. Une fois qu’un composant est partagé dans un repository public, il y reste pour toujours, même si d’autres versions plus récentes et plus sûres sont publiées.
  • 2. La vitesse incroyable à laquelle les nouvelles versions des dépendances sont publiées.
  • 3. Le fait que les dépendances open source résistent généralement mal à l’épreuve du temps. Pour le dire simplement : choisir la bonne version dès le début n’offre pas de garantie à long terme. 

Actuellement, une application contient en moyenne 128 dépendances open source, et le projet open source moyen publie 10 versions par an. Des chiffres propres à décourager plus d’une équipe, et qui rappellent encore une fois la nécessité de l’automatisation.

Actuellement, une application contient en moyenne 128 dépendances open source, et le projet open source moyen publie 10 versions par an, ce qui peut décourager de nombreuses équipes.

Pour vous aider à comprendre comment sélectionner les meilleurs composants pour votre chaîne logistique logicielle, nous avons élaboré 8 règles générales.  Elles se renforcent et se complètent les unes les autres et sont listées ci-dessous : 

  • 1. Ne choisissez pas une version alpha, bêta ou jalon. En clair, évitez les versions qui sont en cours de test et qui nécessitent des mises au point avant d’être publiées. 
  • 2. Évitez de faire une mise à niveau vers une version vulnérable, même si elle est la plus récente. Cela peut paraître évident, mais rien n’est parfois proposé pour ce dont vous avez besoin, ce qui nous amène à la règle 3. 
  • 3. Si plusieurs versions ont une vulnérabilité connue, choisissez la version dont la vulnérabilité est la moins dangereuse.
  • 4. Si le projet open source a publié plusieurs nouvelles versions d’un composant de manière rapprochée, choisissez toujours la version la plus récente.
  • 5. Si vous effectuez une mise à niveau sans choisir une version dès le départ, utilisez un chemin de migration déjà éprouvé par d’autres utilisateurs. 
  • 6. Choisissez une version qui minimise les changements de code (une façon sophistiquée de dire qu’il faut choisir le composant qui causera le moins de problèmes pour l’application).
  • Choisissez la version utilisée par la majorité des développeurs. Attention ! Gardez à l’esprit que, comme pour les fournisseurs, le composant le plus couramment utilisé n’est pas toujours le meilleur. 
  • 8. Si aucune de ces règles ne s’applique, choisissez la version la plus récente. 

Comme nous l’avons dit précédemment, ces 8 règles se renforcent et se complètent les unes les autres.

partie 4.3

La dernière version n’est pas toujours supérieure aux versions précédentes.

Dans le but d’automatiser la prise de décision dans le cadre de la gestion des dépendances, certaines équipes d’ingénieurs ont choisi des outils qui récupèrent simplement la dernière version d’un composant, dès que celle-ci est disponible. Encore une fois, la nouveauté n’est pas toujours synonyme de qualité. 

Ces mises à jour peuvent avoir des conséquences imprévues, comme l’ajout de tâches non planifiées et de risques de sécurité inutiles (par exemple, l’injection de logiciels malveillants et la confusion d’espaces de noms). Ce type de stratégie simpliste de mise à jour des dépendances peut entraîner de nombreuses frustrations et distraire les développeurs. Selon le Rapport sur l’état de la chaîne logistique logicielle en 2021, la meilleure version se situe en moyenne 2,7 versions avant la dernière version.  La gestion des dépendances ne doit pas consister à choisir systématiquement la dernière version, elle doit au contraire s’appuyer sur des politiques soigneusement pensées. 

Alors que vous essayez de ne conserver que les meilleurs composants dans votre chaîne logistique, les problèmes couramment rencontrés proviennent de ces dépendances transitoires, qui résident au plus profond des composants, et qui sont si difficiles à reconnaître. Face à ce problème, la seule solution est la transparence. Nous en reparlerons plus tard au moment où nous présenterons des techniques d’automatisation capables, en plus de cette transparence, de vous mener à l’hygiène, à la maintenabilité et à l’intégrité dont vous avez besoin pour votre chaîne logistique logicielle.

Alors que vous essayez de ne conserver que les meilleurs composants dans votre chaîne logistique, le problèmes couramment rencontrés proviennent des dépendances transitoires, qui résident au plus profond des composants, et qui sont si difficiles à reconnaître.

Le rôle des repository managers dans la gestion des dépendances

Les repository managers servent d’entrepôt local pour tous vos composants logiciels open source et InnerSource. Ils constituent une première étape fondamentale vers la gestion des dépendances dans le cadre de la gestion générale de votre chaîne logistique logicielle. En hébergeant les composants localement, les équipes de développement ont un accès plus efficace et contrôlé aux composants dans l’ensemble d’une entreprise. Les repository managers sont utilisés pour simplifier l’acquisition, la consommation, le partage et le déploiement des composants téléchargés à partir de repositories publics ainsi que d’autres composants et artefacts internes. 

Une fois que les composants sont mis en cache dans un repository manager, les développeurs et leurs outils de développement peuvent récupérer le composant localement autant de fois que nécessaire dans toute l’entreprise, quel que soit le nombre d’applications qui en ont besoin. Les repository managers appliquent le concept « download-once-use-many-times » (en français : télécharger une fois et utiliser de nombreuses fois), qui améliore les pratiques d’approvisionnement.  C’est une étape fondamentale dans l’amélioration des performances et du contrôle des composants tout au long de la chaîne logistique logicielle.

partie 4.4

Améliorer la qualité du code source propriétaire

Quelle que soit l’évolution de la chaîne logistique logicielle au cours des dix prochaines années et au-delà, il est probable que les développeurs continueront à assembler des composants et à les entretenir. La façon dont les entreprises se différencient et différencient leur produit commence à ce stade, quand des développeurs connectent les différents composants dont nous avons parlé et écrivent leur code unique. L’étape de conception du code source propriétaire est le moment où votre entreprise commence à apporter une réponse aux problèmes de ses clients.

Dans cet espace, la plupart des outils sont conçus pour faciliter le respect des directives de développement de la méthode agile, la priorité absolue étant le client et ses besoins. Les projets sont généralement évalués en examinant s’ils répondent ou non aux exigences et aux demandes des clients. Mais qu’en est-il des caractéristiques communes à tous les projets logiciels, à savoir la fiabilité, la vitesse et la sécurité ?  

Quand les équipes de développement se concentrent sur des critères comme la lisibilité du code, la réactivité, la maintenance, la fiabilité (etc.), elles parlent simplement de qualité du code.

L’étape de conception du code source propriétaire est le moment où votre entreprise commence à apporter une réponse aux problèmes de ses clients.

Visibility_animated-wide

Qualité du code automatisable

De nombreux facteurs entrent en jeu dans l’automatisation : l’architecture, la conception de l’API, le style de codage, le choix de la bibliothèque et le suivi des bonnes pratiques de codage, etc. Alors que certains d’entre eux, comme l’architecture et la conception, nécessitent des prises de décision et un discernement humains, d’autres peuvent être automatisés à l’aide d’outils d’analyse de code. Ces outils peuvent être un excellent moyen de garantir la conformité à des normes et d’intégrer des outils d’analyse dans le processus de développement. C’est aussi une première étape facile à suivre dans la priorisation de la qualité.

Les composants que vous sélectionnez dans la chaîne logistique logicielle n’ont aucune utilité si votre code propriétaire ne les utilise pas de façon efficace. Les outils d’évaluation de la qualité du code peuvent faciliter le développement à grande échelle et aider à gérer les interactions avec les logiciels tiers qui créent des problèmes avec votre logiciel. Citons notamment les bonnes pratiques en matière d’API, le flux d’informations et les erreurs de mise en œuvre courantes pour les bibliothèques cryptographiques.

3. Corriger les défauts tôt et ne jamais laisser les défauts connus se propager en aval

Bien que dans notre secteur, de manière schématique, les composants open source soient placés « en amont » (upstream) et les utilisateurs finaux du logiciel « en aval » (downstream), cette règle peut également s’appliquer à des tâches bien avant la phase de test.  Les équipes doivent également éviter de transmettre les défauts connus au sein de leur propre entreprise (que cela concerne la sécurité, les opérations ou même d’autres développeurs), surtout si les applications sont en phase de production.

La transmission d’un logiciel problématique ou les solutions de contournement bricolées pour des outils qui présentent des bugs est une autre forme de dette technique. Au bout du compte, cette dette doit être payée, que ce soit sous forme de reprises ou de refactorisations, des tâches généralement non planifiées et malvenues.

Aucun logiciel n’étant exempt de bugs, les équipes doivent faire preuve de discernement, mais il faut savoir qu’elles pèchent rarement par excès de prudence. Quand les ressources sont limitées ou des délais serrés, les groupes risquent de laisser des problèmes importants passer à l’étape suivante de la chaîne logistique logicielle.

La transmission d’un logiciel problématique ou les solutions de contournement bricolées pour des outils qui présentent des bugs est une autre forme de dette technique.

Les DevOps et les DevSecOps

Ce document cherche surtout à comprendre et à optimiser le fonctionnement des dépendances logicielles externes. Il faut rappeler qui supporte le poids des résultats de cette gestion : votre personnel interne. Bien que cela puisse varier d’une entreprise à l’autre, la majorité des équipes disposent de trois groupes spécialisés :

  • 1. Groupe Développement  : il conçoit et élabore des logiciels
  • 2. Groupe Opérations  : il déploie et gère le logiciel
  • 3. Groupe Sécurité  : il s’efforce de détecter les problèmes à différentes étapes du processus

Ces groupes sont composés de personnes qui assemblent, testent et livrent des logiciels pour votre entreprise. Dans les années 2000, un effort continu visant à améliorer l’agilité et la réactivité dans le processus de développement a mis en lumière les silos et les goulots d’étranglement qui existaient souvent entre les différents services d’une entreprise. Pour rationaliser ce travail, la solution était d’imbriquer davantage le développement et les opérations, un concept largement décrit sous le nom de « DevOps ».

Comme le fait remarquer Forrester Research à propos des pratiques DevOps :

DevOps fournit les informations objectives et la visibilité sur ces informations dont les organisations ont besoin pour prendre leurs décisions concernant la livraison des applications. Finis les rapports d’état périodiques, subjectifs et chronophages ! Grâce à DevOps, les entreprises obtiennent une visibilité en temps réel sur l’état de santé des applications et les progrès de livraison dans le cadre du travail effectué par les équipes.

— FORRESTER RESEARCH

Le succès de ce concept et sa valeur ont également permis de réduire les silos pour la sécurité (auparavant considérée comme entrave) et de créer les « DevSecOps ».

Il existe tant de façons dont une approche DevOps peut améliorer votre gestion de la chaîne logistique logicielle qu’il nous sera impossible de les mentionner toutes. Si cependant vous souhaitez vous renseigner, il existe des ressources dédiées.

Codage sécurisé, tests continus et concept « agir en amont »

Un des piliers des DevOps et des DevSecOps est le concept « agir en amont » (en anglais « Shift Left »). Cette expression correspond au principe qui veut que le test et la vérification de la qualité du code aient lieu dès le début du cycle de développement logiciel (SDLC).

En d’autres termes, le moyen le plus simple de transmettre des logiciels de meilleure qualité en aval est de ne pas repousser les tests à la fin d’un processus. Comme la plupart des descriptions de processus de développement logiciel sont schématisés par des diagrammes qui vont de gauche à droite, déplacer un événement vers une phase plus précoce du processus signifie le déplacer vers la gauche. 

partie 4.11

Bien sûr, chaque équipe de développement est différente et chaque processus est unique, mais l’objectif est d’éviter que les tests et les examens de sécurité ne soient qu’un jalon avant de passer à l’étape suivante.  Intégrer ces tâches au processus est l’un des principaux objectifs des mouvements DevOps, DevSecOps et de la Continuous Integration/Continuous Delivery.

Si « agir en amont » est devenu une sorte d’expression à la mode dans les pratiques de développement qui privilégient la rapidité, il faut rappeler que l’objectif est de mieux positionner les développeurs, qui sont souvent les plus exposés en ce qui concerne la qualité, la sécurité et les opérations. 

 

Chez Sonatype, quand nous employons l’expression « agir en amont », nous ne faisons que prendre en compte la remarque de Deming : « Vous ne pouvez pas inspecter la qualité de vos produits ».  Il faut commencer par le début.

4. Créer un processus transparent et suivre l'utilisation des composants

Il existe de nombreuses façons pour les entreprises d’effectuer le suivi de leurs composants logiciels, et c’est dans ce contexte que l’automatisation et les normalisations sont apparues. Tout comme les fournisseurs ont un bill of materials qui peut être audité lors d’un rappel de produit, les logiciels ont une option prévue pour les audits ou d’autres types d’examens.

Obtenir un software bill of materials (SBOM)

Les lecteurs qui sont à la recherche d’un moyen de résoudre des problèmes de chaîne logistique logicielle doivent commencer ici. Après tout, il est impossible de faire quoi que ce soit sans savoir ce qui se trouve dans votre logiciel. Comme l’a dit une étude de Gartner :

« Pour gérer et atténuer les risques dans les open source softwares, les responsables de la sécurité et des risques chargés des applications et des données doivent élaborer un software bill of materials détaillé (BOM) pour chaque application, ceci afin d’offrir une visibilité complète sur l’ensemble des composants ». – Gartner, 2019

Le problème est que si un mainteneur open source peut corriger rapidement et facilement une vulnérabilité, l’omniprésence d’un composant logiciel dans les services, les applications et l’infrastructure cloud peut rendre incroyablement difficile le déploiement d’une mise à jour dans des délais suffisamment courts. Mais même sans parler de délais, savent-ils vraiment que leur logiciel contient ce composant ? Et s’ils ne le savent pas, comment peuvent-ils corriger la vulnérabilité ?

— VENTUREBEAT

Qu’est ce qu’un software bill of materials ?

Un bill of materials (BOM) énumère les matières premières, les pièces et les composants présents par exemple dans des voitures, des appareils électroniques ou des produits alimentaires. Les BOM servent essentiellement de feuille de route pour la production et détaillent le parcours de chaque composant tout au long de la chaîne logistique.

En utilisant un BOM, une entreprise est capable d’identifier et de résoudre rapidement les problèmes de production. Par exemple, lorsqu’un airbag Takata défectueux a été trouvé en 2016, les constructeurs automobiles ont pu retrouver tous les véhicules concernés grâce à l’enregistrement des pièces contenu dans le BOM. À l’aide de ces données, les fabricants ont rapidement eu accès à la liste des pièces qui posaient problème et ont émis un avis de rappel.

Les BOM améliorent la sécurité et les performances et accélèrent la résolution des problèmes.

En bref, les BOM améliorent la sécurité et les performances et accélèrent la résolution des problèmes. Ces trois aspects correspondent aux exigences actuelles du développement logiciel.

Comment les BOM s’appliquent à l’ingénierie logicielle

Comme nous l’avons vu, la plupart des logiciels contiennent aujourd’hui une gamme importante et complexe de composants, à la fois propriétaires et open source. Lorsque vous travaillez avec un ensemble complexe de parties, il est essentiel de conserver une liste ouverte de l’ensemble des éléments et des emplacements de chaque source. Sans cela, vous risquez de ne pas pouvoir surveiller les composants que vous utilisez, et votre code peut rapidement devenir obsolète ou non sécurisé.

Un software bill of materials (SBOM) est une liste des composants qui constituent une application logicielle. Vous pouvez y trouver le nom des composants, des détails sur la licence, les numéros des versions et les fournisseurs. En fournissant une liste formalisée de détails qui permet de comprendre ce que contient le logiciel et d’agir en conséquence, le SBOM réduit les risques, tant pour le producteur que pour le consommateur.

partie 4-lectures-complémentaires

 

Bien qu’un SBOM soit incapable d’empêcher les vulnérabilités qui n’ont pas encore été découvertes, il peut aider à mettre au jour les problèmes plus tôt dans le processus et à réduire les chances qu’ils atterrissent dans votre logiciel. La force d’une chaîne logistique n’étant égale qu’à celle de son maillon le plus faible, les vulnérabilités logicielles invisibles peuvent avoir des conséquences catastrophiques.

partie 4.6

Les SBOM parviennent-ils à s’imposer dans le paysage ? 

Beaucoup d’entreprises ne disposent toujours pas d’une vue globale de ce que contient leur logiciel, tandis que d’autres ne semblent même pas s’en soucier. Depuis 2020, moins de 50 % des entreprises ont introduit la production de SBOM comme pratique standard dans le développement des logiciels. 

Mais l’augmentation des exigences lors de l’achat de logiciels semble changer la donne. Un nombre croissant d’entreprises demandent ou exigent un SBOM lors de l’achat et de l’intégration de logiciels. Selon des recherches effectuées par Garner :

D’ici 2025, 60 % des entreprises qui développent ou qui achètent des logiciels d’infrastructure critique exigeront et normaliseront les SBOM dans leur pratique d’ingénierie logicielle, contre moins de 20 % en 2022. D’ici 2024, dans un effort pour sécuriser la consommation d’open source softwares, 90 % des outils d’analyse de la composition logicielle seront capables de générer des SBOM et de les vérifier, contre 30 % en 2022. »

— ÉTUDE GARTNER, TELLE QUE RAPPORTÉE PAR SECURITY BOULEVARD

En particulier, la création et la maintenance d’un SBOM deviennent une condition pour vendre au Gouvernement fédéral des États-Unis. En mai 2021, le président Joe Biden a publié un décret présidentiel visant à améliorer la cybersécurité du pays. Le décret charge le Département du commerce et la National Telecommunications and Information Administration (NTIA) d’édicter des exigences minimales pour les SBOM dans le but de sécuriser la chaîne logistique logicielle.

En l’absence de SBOM, les entreprises n’ont aucun moyen de connaître les composants open source vulnérables qui sont envoyés dans leurs applications logicielles. 

De plus, sans SBOM, ces mêmes entreprises auront, à l’instar d’Equifax en 2017, le plus grand mal à réagir aux nouvelles divulgations de vulnérabilités de type « zero day » présentes dans les composants open source. Sans compter que des milliers d’entreprises n’en ont toujours pas fini avec les récentes vulnérabilités Log4j et Spring4Shell. Avec plus de 10 000 vulnérabilités divulguées chaque année, il y a 10 000 bonnes raisons de disposer d’un SBOM pour chacune de vos applications en production.

Avec plus de 10 000 vulnérabilités divulguées chaque année, il y a 10 000 bonnes raisons de disposer d’un SBOM pour chacune de vos applications en production.

Effectuer une analyse continue de la composition logicielle

Les groupes consacrés au développement et à la sécurité ont besoin de rapidité, de précision et d’exactitude. Plus rapidement et précisément vous pourrez identifier les composants open source d’une application, plus vous éviterez les faux positifs et les faux négatifs communs dans d’autres méthodologies, et plus votre solution d’analyse de la composition logicielle sera mature dans l’environnement DevOps. Bien que certaines parties de l’analyse de la composition logicielle (SCA) puissent aider d’autres étapes de la gestion de la chaîne logistique logicielle, nous avons choisi, par souci de synthèse, d’aborder plus en détail cette question dans notre section sur la transparence.

partie 4.7

La SCA consiste à examiner tous les composants d’un projet et à déterminer le risque potentiel (principalement le risque de sécurité) de ces composants. Ce type d’analyse est effectué à l’aide d’outils permettant de trouver et d’identifier les risques dans vos applications. Ces outils peuvent être automatisés et surveiller les composants tout au long du cycle de développement logiciel (SDLC).


Détection automatisée des logiciels malveillants et réaction face aux composants vulnérables

Plus une vulnérabilité est détectée de façon tardive, plus il faut de temps et d’efforts pour la résoudre. Tous les composants de votre logiciel peuvent être affectés par une vulnérabilité détectée, ceci quel qu’en soit le stade. L’utilisation de données de vulnérabilité précises le plus tôt possible dans le processus permet un meilleur contrôle sur votre chaîne logistique logicielle. Moins de faux positifs et de faux négatifs est la meilleure mesure de la précision et de l’exhaustivité.

  • Un faux positif est une vulnérabilité de sécurité connue attribuée à un composant qui ne porte pas la vulnérabilité. Dans la sécurité open source, cela se produit le plus souvent lorsque les correspondances des composants sont mal établies par le fournisseur et qu’il identifie à tort un paquet sécurisé comme un composant similaire (vulnérable). Il peut également arriver que les versions d’un composant qui présentent une vulnérabilité soient mal identifiées.
  • Un faux négatif ou un positif manqué est un type beaucoup plus grave d’échec d’analyse. Cela signifie qu’une vulnérabilité connue dans votre environnement, qui pourrait provoquer de graves dommages, n’a pas été détectée. Ce problème est courant avec les vulnérabilités transitoires qui sont enfouies profondément dans les composants logiciels. La peur d’un faux négatif peut conduire certaines solutions SCA moins avancées à surcharger votre boîte de réception (voir « Outils de sécurité à fort bruit de fond »).

partie 4.8

Autres considérations sur la SCA

La plupart des outils de test et d’analyse ont la tâche ardue de fournir les bonnes informations au bon moment, et c’est particulièrement vrai pour les logiciels SCA. Les équipes qui cherchent à évoluer doivent échapper à la mentalité qui veut que le « plus » corresponde nécessairement au « mieux ».

  • Outils de sécurité qui génèrent un bruit de fond important – Votre nouveau smartphone ou votre nouvel ordinateur vous submerge d’invites pour un programme qui requiert un accès spécial ? Les outils de développement eux aussi peuvent déclencher l’alarme trop fréquemment. Les outils SCA qui ne trient pas leurs résultats finissent par renvoyer la charge d’assurer la sécurité au vérificateur en demandant aux développeurs d’établir une longue liste des problèmes possibles.

    La surnotification de problèmes qui ont déjà été résolus ou dont la priorité est faible risque d’aboutir à une situation dans laquelle les avertissements importants sont ignorés. Elle peut aussi provoquer une baisse de la productivité.

  • Vulnérabilités en double : il est possible que plusieurs de vos progiciels soient vulnérables, chacun contenant plusieurs vulnérabilités. Cependant, la plupart du temps, une seule notification peut représenter une famille de problèmes. 

    Par exemple, recevoir 10 notifications concernant différentes instances et versions de Log4j dans votre environnement peut être considéré comme une perte de temps si les équipes ont déjà mis à niveau toutes les versions. Un seul avertissement suffit, et cet avertissement doit normalement disparaître après l’application de la mise à jour (et après que votre outil SCA l’a vérifiée).

  • Notifications personnalisées – Les responsables de la sécurité et de l’ingénierie doivent être en mesure de définir des politiques sur les types de logiciels autorisés au cours du cycle de développement logiciel.
Enveloppe Sonatype

Prêt à essayer les produits Nexus ?