Une SBOM, ou « software bill of materials » (liste des composants logiciels), est une liste des composants et des dépendances qui constituent un produit logiciel donné. Elle comprend l'ensemble des bibliothèques, modules, frameworks et autres ressources externes nécessaires à la création du logiciel, ainsi que les relations qui les lient. En substance, une SBOM représente la chaîne d'approvisionnement numérique d'un système logiciel. Et cette obligation s'applique désormais à tous les fournisseurs qui vendent des logiciels au gouvernement fédéral. Tous ceux qui développent ou exploitent des logiciels peuvent également en tirer profit.
Les SBOM font partie intégrante de la communauté open source depuis plus d’une décennie, mais elles ont suscité davantage d’intérêt dans les milieux de la cybersécurité depuis la vague d’attaques visant la chaîne d’approvisionnement logicielle des entreprises et des agences gouvernementales américaines en 2020 et 2021.
Le piratage de SolarWinds par l’ , et plus particulièrement le fait que des agences fédérales, notamment le Département de la Sécurité intérieure et le Département du Trésor, aient déployé à leur insu un composant infecté par un cheval de Troie permettant aux pirates d’accéder aux systèmes informatiques des victimes, a donné lieu à un décret de l’ publié sur mai 2021 exigeant que tout fournisseur vendant des logiciels au gouvernement fédéral détaille ses composants dans une liste SBOM.
En raison de la complexité de la chaîne d'approvisionnement logicielle, un seul composant logiciel peut avoir un impact disproportionné sur sa sécurité. Mais les utilisateurs n'ont qu'une visibilité très limitée sur les composants imbriqués dans leurs applications les plus stratégiques pour l'entreprise. Disposer d'une liste des « composants » de leurs produits peut leur permettre de mieux cerner leurs risques de sécurité et leur fournir une feuille de route pour détecter les vulnérabilités avant qu'elles ne provoquent une crise.
Quelle est l'origine du SBOM ?
L'importance accrue accordée aux SBOM trouve son origine dans le décret présidentiel (EO) n° 14028 du président Biden, intitulé « » (Améliorer la cybersécurité de la nation), qui charge l'Institut national des normes et des technologies (NIST) ainsi que d'autres agences fédérales de renforcer la cybersécurité par le biais d'une série d'initiatives liées à la sécurité et à l'intégrité de la chaîne d'approvisionnement logicielle, afin de mieux protéger les réseaux du gouvernement fédéral.
Ce décret présidentiel a été adopté en grande partie en réponse à la recrudescence des cyberattaques visant les entreprises américaines et le gouvernement américain en 2020 et ’21. Les attaques commises au cours de cette période ont été plus fréquentes et plus graves, et deux des plus préjudiciables — celle visant SolarWinds et l'attaque par ransomware contre le Colonial Pipeline — ont motivé la publication de ce décret présidentiel.
Lors de l'attaque contre SolarWinds, un seul composant infecté par un cheval de Troie au sein du logiciel Orion de cette entreprise basée au Texas, utilisé pour surveiller et gérer les réseaux et infrastructures informatiques, a permis à des pirates informatiques d'accéder de manière in e aux systèmes de milliers d'organisations, parmi lesquelles des entreprises du classement Fortune 500 , plusieurs agences gouvernementales fédérales et même la société américaine de cybersécurité qui a finalement détecté la faille. Jusqu'à 18 000 victimes issues des secteurs privé et public d' , ont téléchargé le logiciel infecté, même si elles ont été moins nombreuses à être par la suite compromises.
L'attaque par ransomware contre Colonial Pipeline visait une seule organisation, mais elle a eu des répercussions considérables sur les infrastructures du pays. Lorsque l'entreprise, qui fournit environ 45 % du carburant de la côte Est, a découvert cette attaque, elle a été contrainte de mettre hors ligne ses systèmes informatiques essentiels afin de contenir la menace, ce qui a entraîné l'arrêt effectif de ses activités. Les pénuries de carburant qui en ont résulté ont provoqué une vague d'achats de panique et une flambée des prix de l'essence.
Ce décret présidentiel tient compte des enseignements tirés de ces incidents de sécurité et d'autres encore, et vise à favoriser la collaboration entre les secteurs public et privé afin de contrer des cyberattaques de plus en plus sophistiquées. Plus précisément, il définit plusieurs objectifs :
- Renforcer le partage d’informations —Le décret présidentiel ordonne la suppression de tout obstacle contractuel au partage d’informations sur les menaces entre le gouvernement et le secteur privé, et exige que les prestataires de services informatiques partagent les informations relatives aux menaces, aux vulnérabilités et aux incidents susceptibles d’avoir un impact sur le gouvernement fédéral.
- Moderniser la cybersécurité des pouvoirs publics —Le décret présidentiel charge le gouvernement fédéral de mettre en place des normes et des bonnes pratiques plus strictes en matière de cybersécurité. Il s'agit notamment d'adopter des services cloud sécurisés , de mettre en œuvre un modèle de sécurité « zero-trust » , ainsi que de mettre en place l'authentification multifactorielle (MFA) et des procédures de chiffrement.
- Renforcer la sécurité de la chaîne d'approvisionnement logicielle —Le gouvernement s'apprête à établir des normes de sécurité de base en matière de développement logiciel pour les logiciels qu'il acquiert auprès de prestataires. Le ministère du Commerce et l'Administration nationale des télécommunications et de l'information (NTIA) doivent publier les éléments constitutifs d'une nomenclature logicielle qui répertorie et décrit en détail les composants individuels qui composent un produit logiciel.
- Mise en place d’un comité d’examen de la cybersécurité —Le gouvernement va créer un comité d’examen de la cybersécurité ( ) , coprésidé par des experts du secteur public et du secteur privé, qui se réunira à la suite d’un incident majeur de cybersécurité afin d’analyser les faits et de formuler des recommandations visant à améliorer la sécurité.
- Élaborer un guide d’intervention en cas d’incident —Les responsables informatiques du gouvernement doivent mettre au point un guide standard « » destiné à la gestion des incidents de sécurité, afin de garantir que toutes les agences fédérales puissent réagir efficacement aux cyberattaques et remédier aux dommages causés.
- Améliorer la détection des incidents —L'ordonnance exécutive exige la mise en œuvre d'un système de détection et de réponse aux menaces au niveau des terminaux (EDR) , commun à l'ensemble de l'administration, ainsi que l'amélioration du partage d'informations au sein du gouvernement fédéral afin de mieux détecter les incidents de cybersécurité.
- Améliorer les enquêtes et les mesures correctives —Le gouvernement va mettre en place des exigences en matière de journalisation des événements de cybersécurité pour l'ensemble des agences fédérales, afin d'améliorer les enquêtes et les mesures correctives relatives aux incidents de cybersécurité sur les réseaux du gouvernement fédéral.
Ce décret présidentiel a défini des objectifs immédiats que plusieurs agences gouvernementales doivent atteindre, mais il a des répercussions en cascade sur l'ensemble de la chaîne d'approvisionnement des marchés publics fédéraux. Plus précisément, ce décret présidentiel concerne trois groupes :
- Les agences fédérales exécutives —— Les principales agences gouvernementales sont chargées de moderniser leur environnement technologique et leurs pratiques en matière de sécurité.
- Les prestataires fédéraux —Les prestataires travaillant pour le compte du gouvernement américain, y compris les fournisseurs de logiciels commerciaux prêts à l'emploi (COTS), peuvent s'attendre à ce que de nouvelles normes de cybersécurité soient intégrées aux clauses contractuelles. Elles sont également tenues de communiquer davantage d'informations sur les incidents informatiques.
- Entreprises privées —Les entreprises privées seront soumises à une nouvelle législation en matière de cybersécurité et à un renforcement de l'application des lois et politiques existantes, l'accent étant davantage mis sur la sécurité de la chaîne d'approvisionnement des logiciels d' et sur la déclaration des incidents de cybersécurité . On met également davantage l'accent sur la transparence grâce à un projet d'étiquetage de sécurité destiné aux consommateurs sur les logiciels et les appareils de l'Internet des objets (IoT), ce qui se traduit par de nouvelles exigences de sécurité et de nouvelles normes d'évaluation pour ces fournisseurs.
Pourquoi les SBOM sont-elles importantes aujourd'hui ?
Les SBOM sont importantes car elles permettent aux organisations d'identifier et de corriger les vulnérabilités susceptibles d'exister dans leurs logiciels et leurs dépendances. Les applications modernes sont développées à partir d'une chaîne d'approvisionnement en composants logiciels tout aussi complexe que celles utilisées par les fabricants de biens matériels. Une application type est constituée de dizaines de composants, combinant à la fois du code propriétaire et des composants réutilisables provenant de tiers. Si un développeur peut vérifier le code qu’il a écrit lui-même pour détecter les erreurs et les fautes, il a en revanche moins de visibilité sur le code provenant de tiers. Les pirates en sont conscients et en tirent parti, en ciblant des composants tiers, sachant qu'ils ont ainsi de grandes chances d'échapper à la détection.
«Lorsqu’une vulnérabilité est découverte ou divulguée, les SBOM permettent de déterminer où cette version du logiciel est utilisée au sein de l’organisation. »
Outre l'incident désormais tristement célèbre de SolarWinds, une série d'attaques visant la chaîne d'approvisionnement au cours des dernières années a mis en évidence les effets dévastateurs que ce scénario peut avoir. Des pirates ont exploité une vulnérabilité critique dans le logiciel open source Apache Log4j , une bibliothèque de journalisation quasi omniprésente qui enregistre les activités de millions d'applications Java. Des pirates ont également exploité quatre vulnérabilités « zero-day » distinctes de type « » dans Microsoft Exchange Server pour accéder aux réseaux de 30 000 organisations américaines.
Une SBOM peut aider une entreprise à mieux se prémunir contre ce type d'attaques visant la chaîne d'approvisionnement et à hiérarchiser sa gestion des risques. Par exemple, il peut utiliser les SBOM pour, dans un premier temps, éliminer l'utilisation de bibliothèques présentant des vulnérabilités connues, puis s'assurer qu'il utilise bien la dernière version de chaque bibliothèque open source. Lorsqu'une vulnérabilité est découverte ou rendue publique, les SBOM permettent de déterminer où cette version du logiciel est utilisée au sein de l'organisation. De manière plus générale, les SBOM permettent aux organisations de prendre des décisions plus éclairées concernant les logiciels qu'elles utilisent et incitent les éditeurs de logiciels à proposer des produits plus sûrs.
Quels sont les éléments constitutifs d'une SBOM ?
Dans le document « juillet 2021 », la NTIA a publié « The Minimum Elements For a Software Bill of Materials », qui présente les exigences du gouvernement fédéral en matière d’ concernant une nomenclature logicielle (SBOM). Elle classe les composants de base d'une SBOM en trois catégories : les champs de données, le soutien à l'automatisation, ainsi que les pratiques et les processus. Voici un aperçu plus détaillé de chacun d'entre eux.
Champs de données
Les champs de données doivent permettre d'identifier de manière précise chaque composant afin qu'il puisse être suivi tout au long de la chaîne logistique logicielle et recoupé avec les bases de données de vulnérabilités et de licences. La NTIA définit sept champs de données :
- Nom du fournisseur : Nom de l'organisme qui crée et identifie le composant.
- Nom du composant : Nom attribué à une unité logicielle par le fournisseur d'origine.
- Version du composant : Informations relatives à la version et à la compilation du composant utilisé dans un produit logiciel.
- Autres identifiants uniques : les clés de recherche « » et d'autres informations, telles qu'un identifiant issu du dictionnaire CPE du NIST ( ), pouvant servir à identifier un composant.
- Relations de dépendance : Description des dépendances entre le composant et d'autres logiciels. Par exemple, le composant A est intégré au logiciel B.
- Auteur des données SBOM : Nom de l'organisme ayant créé les données SBOM du composant.
- Horodatage : Date et heure auxquelles les données SBOM ont été compilées.
Prise en charge de l'automatisation
Étant donné qu'il n'est pas envisageable pour les professionnels de la sécurité de rechercher manuellement les composants compromis dans chaque SBOM, la NTIA exige que chaque SBOM prenne en charge l'automatisation via l'un des trois formats lisibles par machine suivants :
- Cyclone DX
- Échange de données sur les progiciels (SPDX)
- Étiquettes d'identification logicielle (SWID)
[Read also: Here’s your security automation playbook for 2023]
Pratiques et processus
Les pratiques et processus garantissent l'exactitude d'un document SBOM tout au long du cycle de vie d'un produit logiciel. La NTIA énonce plusieurs éléments minimaux à prendre en compte, notamment :
- Fréquence : Chaque fois qu'un composant logiciel est mis à jour avec une nouvelle version ou une nouvelle version finale, une nouvelle SBOM doit être générée afin de refléter la nouvelle version du logiciel. Cela inclut les versions logicielles destinées à intégrer un composant ou une dépendance mise à jour. De même, si le fournisseur souhaite corriger une erreur ou mettre à jour des informations figurant dans les données existantes de la nomenclature technique (SBOM), il doit émettre une nouvelle nomenclature technique révisée.
- Pour en savoir plus : Une SBOM doit inclure tous les composants de niveau supérieur et répertorier leurs dépendances.
- Les « inconnues connues » : Il arrive parfois que les développeurs reconnaissent qu’ils ne connaissent pas toutes les relations de dépendance d’un composant. Dans ces cas-là, la SBOM doit indiquer clairement que les données sont incomplètes et expliquer où des liens pourraient exister.
- Distribution et mise à disposition : Les SBOM doivent être mises à la disposition des personnes qui en ont besoin en temps utile et qui disposent des autorisations d'accès et des rôles appropriés.
- Contrôle d'accès : Les organisations qui souhaitent préserver la confidentialité des données SBOM doivent définir les conditions applicables, y compris les autorisations et les dispositions permettant aux utilisateurs d'intégrer ces données dans leurs outils de sécurité.
- Tolérance vis-à-vis des erreurs : La gestion des données SBOM étant une pratique en constante évolution, les utilisateurs doivent faire preuve de tolérance face aux erreurs fortuites. Les fournisseurs devraient fournir des données actualisées dès que des problèmes sont identifiés dans les SBOM antérieures, et les utilisateurs devraient accueillir favorablement ces mises à jour et corrections sans pénalité, afin d'encourager une amélioration continue.
Les exigences en matière de SBOM devraient continuer à se multiplier et à évoluer. Les prochaines mises à jour des lignes directrices pourraient inclure davantage de champs de données, ainsi que l'ajout de scores de sécurité, de listes de vulnérabilités et d'autres informations. Bien que les organisations ne soient tenues de respecter que les exigences minimales relatives à une SBOM, l'ajout d'informations supplémentaires pertinentes concernant un produit logiciel témoignera d'un engagement fort en faveur de la transparence et de la sécurité.
En quoi consiste le cycle de vie du développement d'une SBOM ?
Idéalement, les SBOM devraient être générées automatiquement à chaque déploiement de logiciel et comporter un inventaire aussi complet que possible. Le cycle de vie de la SBOM contribue à faciliter ce processus en proposant une méthode permettant d'identifier les applications, de créer des SBOM et de les mettre à la disposition des utilisateurs finaux.
«Les SBOM doivent être générées automatiquement à chaque déploiement de logiciel et inclure un inventaire aussi complet que possible. »
Il se compose des cinq étapes suivantes :
- Identification des actifs —La première étape consiste à identifier l'application pour laquelle vous devez fournir une SBOM. Il est recommandé d'utiliser un outil de découverte des ressources afin de bénéficier d'une visibilité complète sur toutes vos applications.
- Analyse des données d'application —Les données d'application nécessaires à l'établissement de la SBOM sont collectées.
- Création de la SBOM —Le fichier SBOM est créé, comprenant toutes les données pertinentes relatives à l'application. Cette opération doit être effectuée à chaque nouvelle version de l'application afin de garantir que la SBOM corresponde toujours à l'état actuel du logiciel.
- Stockage des SBOM —Les SBOM doivent être stockées de manière centralisée et sécurisée, à l'aide d'un système de chiffrement.
- Fonctionnalité de recherche dans la SBOM —La dernière étape consiste à garantir la fonctionnalité de recherche dans la SBOM afin que l'utilisateur final puisse identifier toute vulnérabilité potentielle.
Quelles sont les normes relatives aux SBOM ?
Une norme SBOM est un schéma permettant de détailler la composition d'un logiciel dans un fichier lisible par machine, qui peut être exploité par d'autres outils tels que les scanners de vulnérabilités et les outils de suivi des licences logicielles. À l'heure actuelle, il existe trois normes principales pour la création de SBOM et leur partage avec les utilisateurs finaux :
- SPDX —La norme SPDX (Software Package Data Exchange), développée par la Linux Foundation, est un format largement adopté pour la transmission de données SBOM, telles que les composants d’une application, ses licences, ses droits d’auteur et ses informations de sécurité, dans divers formats de fichiers.
- CycloneDX —CycloneDX est une autre norme ouverte, développée par la communauté OWASP. Il repose sur la norme SPDX, mais a été simplifié afin d'en faciliter la mise en œuvre et l'utilisation
- SWID —Les SWID, abréviation de « Software Identification Tags », constituent un type de métadonnées pouvant être générées automatiquement par de nombreuses applications afin de décrire et de contextualiser les composants d'un logiciel.
La NTIA a retenu ces trois normes relatives aux SBOM car, outre le fait qu'elles sont lisibles par l'homme, elles sont également lisibles par machine et permettent l'automatisation, ce qui facilite leur utilisation par les utilisateurs finaux et leur déploiement à l'échelle de leur organisation.
[À lire également : L'avenir de la gestion des risques passe par l'automatisation]
Quels sont les défis liés à la création et à l'utilisation d'une SBOM ?
Comme pour tout nouveau système, la création et l'utilisation d'une SBOM posent certains défis.
L'un des principaux obstacles réside dans l'absence de normalisation. Les SBOM sont susceptibles d'être particulièrement efficaces lorsque l'ensemble de la chaîne d'approvisionnement respecte les mêmes normes, processus et outils. Toutefois, à ce stade précoce, il n'existe guère de consensus sur aucun de ces points, et un manque d'uniformité entre les éditeurs de logiciels et les utilisateurs finaux est inévitable. Cela peut entraîner un surcroît de temps consacré à l'analyse et à l'adaptation des SBOM en fonction des besoins.
«Les SBOM sont susceptibles d’être particulièrement efficaces lorsque l’ensemble de la chaîne d’approvisionnement respecte les mêmes normes, processus et outils. » Toutefois, à ce stade précoce, il n’y a guère de consensus sur aucun de ces points. »
Un autre défi réside dans la nécessité d'adapter en permanence les SBOM. À chaque nouvelle version d'une application, celle-ci doit inclure une nouvelle liste SBOM reflétant l'état actuel de l'application. Il est donc essentiel d'adopter des outils de gestion des SBOM capables d'intégrer la génération des SBOM dans le cycle de vie du développement logiciel.
L'adaptation des SBOM à mesure que vous intégrez de nouveaux partenaires dans votre chaîne d'approvisionnement peut également poser problème si vous utilisez des méthodes traditionnelles pour les générer, telles que les tableurs et les e-mails. De plus, ces méthodes manuelles prennent beaucoup de temps, sont sources d'erreurs et peuvent compliquer le suivi des relations hiérarchiques entre les composants.
Quelles sont les bonnes pratiques à suivre pour créer une SBOM efficace ?
Les bonnes pratiques suivantes peuvent vous aider à créer des SBOM efficaces :
- Utilisez un format cohérent —. Il est important de respecter un format standard lors de la structuration des données SBOM. Les formats SPDX, CycloneDX et SWID sont les plus courants, mais au final, le choix du format importe moins que le fait de l'utiliser de manière cohérente.
- Automatiser la création de la SBOM —La génération automatique de SBOM dans le cadre de votre pipeline de livraison logicielle présente plusieurs avantages. Avant tout, cela permettra aux développeurs de gagner du temps, car ils n'auront plus à créer manuellement chaque SBOM. Cela augmente également les chances que les SBOM s'intègrent de manière systématique à votre cycle de livraison logicielle. Enfin, cela vous permet de respecter les exigences fixées par le décret présidentiel de Biden concernant la fourniture de services informatiques au gouvernement fédéral.
- Mettez à jour les SBOM à chaque nouvelle version —Une SBOM doit être spécifique à chaque version du logiciel, y compris à chaque mise à jour de l'application. L'automatisation est ici essentielle ; si les développeurs doivent mettre à jour manuellement leur SBOM à chaque mise à jour de l'application, ils seront bien moins enclins à le faire.
- Veillez à inclure des métadonnées complètes —Bien qu’il n’existe pas de normes universelles en matière de SBOM, vous devriez prendre l’habitude d’inclure autant de métadonnées que possible dans chaque SBOM. Cela permettra de réduire la quantité d'informations que vos utilisateurs finaux devront rechercher manuellement et démontrera votre engagement en matière de sécurité et de transparence. Cela facilite également les mises à jour.
