Une SBOM, ou nomenclature logicielle, est une liste des composants et dépendances qui composent un produit logiciel particulier. Il comprend toutes les bibliothèques, modules, cadres et autres ressources externes nécessaires pour construire le logiciel et les relations entre eux. En substance, une SBOM représente la chaîne d’approvisionnement numérique d’un système logiciel. Et elle est désormais requise de tous les fournisseurs vendant des logiciels au gouvernement fédéral. Tous ceux qui créent ou exploitent des logiciels peuvent également en bénéficier.
Les SBOM font partie de la communauté open source depuis plus d’une décennie, mais elles ont attiré plus d’attention dans les cercles de cybersécurité depuis la vague d’attaques de chaîne d’approvisionnement logicielle contre les entreprises américaines et les agences gouvernementales en 2020 et 2021.
Le piratage de SolarWinds, en particulier, où les agences fédérales, y compris le Département de la sécurité intérieure et le Département du Trésor, avaient involontairement déployé un composant trojanisé qui permettait aux attaquants d’accéder aux systèmes informatiques des victimes, a incité un décret à mai 2021 exiger que tout fournisseur vendant des logiciels au gouvernement fédéral détaille ses composants dans une SBOM.
En raison de la complexité de la chaîne d’approvisionnement logicielle, un seul composant logiciel peut avoir un impact sur sa sécurité. Mais les utilisateurs ont une visibilité minimale sur les composants imbriqués dans leurs applications les plus critiques pour l’entreprise. Disposer d’une liste d’« ingrédients » de produits peut leur donner une meilleure idée de leurs risques de sécurité et fournit une feuille de route pour suivre les vulnérabilités avant qu’elles ne créent une crise.
Quelle est l’origine de la SBOM ?
Le nouvel accent mis sur les SBOM provenait du décret exécutif (EO) 14028 du président Biden sur l’amélioration de la cybersécurité de la nation, qui charge l’Institut national des normes et de la technologie (NIST) et d’autres agences fédérales d’améliorer la cybersécurité grâce à diverses 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.
L’EO a largement réagi à l’explosion des cyberattaques contre les entreprises américaines et le gouvernement américain en 2020 et ’21. Les attaques au cours de cette période étaient plus fréquentes et plus graves, avec deux des attaques les plus préjudiciables : SolarWinds et l’ attaque de ransomware Colonial Pipeline, ce qui a stimulé l’EO.
Dans l’attaque SolarWinds, un composant unique trojancé dans le logiciel Orion de la société basée au Texas, qui est utilisé pour surveiller et gérer les réseaux et l’infrastructure informatiques, a permis aux pirates informatiques d’accéder aux systèmes de milliers d’organisations, y compris des entreprises du Fortune 500 , plusieurs agences gouvernementales fédérales, et même la société de cybersécurité américaine qui a finalement détecté la violation. Jusqu’à 18 000 victimes du secteur privé et public ont téléchargé le logiciel infecté, bien que moins aient été compromises par la suite.
L’attaque par rançongiciel Colonial Pipeline a ciblé une seule organisation, mais a eu un impact considérable sur l’infrastructure du pays. Lorsque l’entreprise, qui fournit environ 45 % du carburant de la côte Est, a découvert l’attaque, elle a été contrainte de mettre hors ligne des systèmes informatiques critiques pour contenir la menace, ce qui a effectivement interrompu ses opérations. Les pénuries de carburant qui en ont résulté ont entraîné une poussée de panique et une hausse des prix du gaz.
[Lire également : ce que le décret Biden signifie pour les cadres technologiques]
L’EO reflète les leçons tirées de ces incidents et d’autres incidents de sécurité et cherche à favoriser la collaboration entre les secteurs public et privé afin d’atténuer les cyberattaques de plus en plus sophistiquées. Plus précisément, il décrit plusieurs objectifs :
- Améliorer le partage d’informations : l’EO demande que tous les obstacles contractuels au partage d’informations sur les menaces entre le gouvernement et le secteur privé soient supprimés et exige que les fournisseurs de services informatiques partagent des informations sur les menaces, les vulnérabilités et les incidents qui pourraient potentiellement avoir un impact sur le gouvernement fédéral.
- Moderniser la cybersécurité gouvernementale : l’EO charge le gouvernement fédéral d’instaurer des normes et des meilleures pratiques de cybersécurité plus strictes. Il s’agit notamment d’adopter des services cloud sécurisés, d’utiliser un modèle de sécurité Zero Trust et de mettre en œuvre des routines d’ authentification multifacteur (AMF) et de chiffrement.
- Renforcer la sécurité de la chaîne d’approvisionnement logicielle : le gouvernement doit établir des normes de sécurité de développement logiciel de base pour le logiciel qu’il achète auprès des sous-traitants. Le Département du commerce et la National Telecommunications and Information Administration (NTIA) doivent publier des éléments pour une nomenclature logicielle qui répertorie et détaille les composants individuels qui composent un produit logiciel.
- Établir un comité d’examen de la sécurité en matière de cybersécurité : le gouvernement créera un comité qui sera co-présidé par des experts du gouvernement et du secteur privé qui se réuniront à la suite d’un incident de cybersécurité important pour analyser ce qui s’est passé et faire des recommandations pour améliorer la sécurité.
- Créer un guide de réponse aux incidents : les responsables informatiques du gouvernement doivent développer un guide standard pour répondre aux incidents de sécurité afin de s’assurer que toutes les agences fédérales peuvent réagir efficacement aux cyberattaques et remédier à leurs dommages.
- Améliorer la détection des incidents : l’EO exige qu’un système de détection et de réponse (EDR) des endpoints à l’échelle du gouvernement soit mis en œuvre et que le partage d’informations au sein du gouvernement fédéral soit amélioré pour une meilleure détection des incidents de cybersécurité.
- Améliorer l’enquête et la remédiation : le gouvernement créera des exigences de journal des événements de cybersécurité pour toutes les agences fédérales afin d’améliorer l’enquête et la remédiation des incidents de cybersécurité sur les réseaux du gouvernement fédéral.
L’OE a défini des objectifs immédiats que plusieurs agences gouvernementales doivent atteindre, mais cela a un effet en cascade sur l’ensemble de la chaîne d’approvisionnement fédérale des contrats. Plus précisément, l’EO affecte trois groupes :
- Agences exécutives fédérales : les agences gouvernementales de haut niveau sont chargées de moderniser leur environnement technologique et leurs pratiques de sécurité.
- Sous-traitants fédéraux : les sous-traitants faisant affaire avec le gouvernement américain, y compris les fournisseurs de logiciels commerciaux prêts à l’emploi (COTS), peuvent s’attendre à de nouvelles normes de cybersécurité intégrées aux conditions contractuelles. Ils sont également tenus de partager plus d’informations sur les cyber-incidents.
- Entreprises privées : les entreprises privées seront soumises à une nouvelle législation en matière de cybersécurité et à une application accrue des lois et politiques existantes, en mettant davantage l’accent sur la sécurité de la chaîne d’approvisionnement logicielle et le signalement des cyberincidents. L’accent est également mis sur la transparence grâce à l’étiquetage de sécurité des consommateurs proposé sur les logiciels et les appareils Internet des objets (IdO), ce qui entraîne de nouvelles exigences de sécurité et des normes d’évaluation pour ces fournisseurs.
Pourquoi les SBOM sont-elles importantes aujourd’hui ?
Les SBOM sont importantes car elles peuvent aider les organisations à identifier et à corriger les vulnérabilités qui peuvent exister dans leurs logiciels et leurs dépendances. Les applications modernes sont développées à l’aide d’une chaîne d’approvisionnement de composants logiciels aussi complexes que ceux utilisés par les fabricants de biens physiques. Une application typique est construite à partir de dizaines de composants à l’aide d’un mélange de code propriétaire et de composants tiers réutilisables. Bien qu’un développeur puisse examiner n’importe quel code qu’il a écrit pour détecter les erreurs, il a moins de visibilité sur le code tiers. Les pirates informatiques comprennent et exploitent cela, ciblant les composants tiers en sachant qu’ils échapperont probablement à la détection.
« Lorsqu’une vulnérabilité est découverte ou divulguée, les SBOM peuvent aider à déterminer où cette version logicielle est utilisée dans l’organisation. »
Outre le tristement célèbre incident SolarWinds, une série d’attaques de 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. Les attaquants ont exploité une vulnérabilité critique dans le logiciel open source Apache Log4j , une bibliothèque de journaux presque omniprésente qui enregistre les activités dans des millions d’applications basées sur Java. Les pirates informatiques ont également tiré parti de quatre vulnérabilités zero-day distinctes dans Microsoft Exchange Server pour accéder aux réseaux de 30 000 organisations américaines.
Une SBOM peut aider une entreprise à mieux se protéger contre ces types d’attaques de la chaîne d’approvisionnement et à hiérarchiser sa gestion des risques. Par exemple, il peut utiliser des SBOM pour éliminer d’abord l’utilisation de bibliothèques avec des vulnérabilités connues, puis pour s’assurer qu’il utilise la dernière version de chaque bibliothèque open source. Lorsqu’une vulnérabilité est découverte ou divulguée, les SBOM peuvent aider à déterminer où cette version logicielle est utilisée dans l’organisation. Plus généralement, les SBOM permettent aux organisations de prendre des décisions mieux informées sur les logiciels qu’elles utilisent et encouragent les fournisseurs de logiciels à produire des produits plus sécurisés.
Quels sont les composants d’une SBOM ?
En juillet 2021, la NTIA a publié « Les éléments minimums pour une nomenclature logicielle », décrivant les exigences du gouvernement fédéral pour une SBOM. Il divise les composants de référence d’une SBOM en trois catégories : champs de données, prise en charge de l’automatisation, pratiques et processus. Voici un aperçu plus approfondi de chacun d’entre eux.
Champs de données
Les champs de données doivent identifier efficacement chaque composant afin qu’il puisse être surveillé sur la chaîne d’approvisionnement du logiciel et référencé par rapport aux bases de données de vulnérabilités et de licences. La NTIA spécifie sept champs de données :
- Nom du fournisseur : nom de l’organisation qui crée et identifie le composant.
- Nom du composant : le nom attribué à une unité logicielle par le fournisseur d’origine.
- Version du composant : les détails de la version et de la construction du composant utilisé dans un produit logiciel.
- Autres identifiants uniques : clés de recherche et autres informations, telles qu’un identifiant du dictionnaire CPE du NIST, qui peuvent être utilisées pour identifier un composant.
- Relation de dépendance : description des dépendances entre le composant et d’autres logiciels. Par exemple, le composant A est inclus dans le logiciel B.
- Auteur des données SBOM : nom de l’organisation qui a 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 possible pour les professionnels de la sécurité de rechercher manuellement les composants compromis dans chaque SBOM, NTIA exige que chaque SBOM prenne en charge l’automatisation via l’un des trois formats lisibles par machine :
- Cyclone DX
- Échange de données du package logiciel (SPDX )
- Balises d’identification du logiciel (SWID)
[Lire également : Voici votre guide d’automatisation de la sécurité pour 2023]
Pratiques et processus
Les pratiques et processus garantissent la précision d’un document SBOM tout au long du cycle de vie d’un produit logiciel. Le NTIA décrit plusieurs éléments minimum à traiter, notamment :
- Fréquence : chaque fois qu’un composant logiciel est mis à jour avec une nouvelle version, une nouvelle SBOM doit être générée pour refléter la nouvelle version du logiciel. Cela inclut les versions logicielles pour intégrer un composant ou une dépendance mis à jour. De même, si le fournisseur souhaite corriger une erreur ou mettre à jour les informations dans les données SBOM existantes, il doit émettre une nouvelle SBOM révisée.
- Profondeur : une SBOM doit inclure tous les composants de niveau supérieur et répertorier leurs dépendances.
- Inconnus connus : les développeurs reconnaissent parfois qu’ils ne connaissent pas toutes les relations de dépendance concernant un composant. Dans ces cas, la SBOM doit indiquer clairement que les données sont incomplètes et expliquer où des relations peuvent exister.
- Distribution et livraison : les SBOM doivent être disponibles pour ceux qui en ont besoin en temps opportun et disposer des permissions 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 spécifier les conditions, y compris les allocations et les aménagements pour que les utilisateurs intègrent les données SBOM dans leurs outils de sécurité.
- Accommodation des erreurs : étant donné que la gestion des données SBOM est une pratique en constante évolution, les utilisateurs doivent être tolérants aux erreurs accidentelles. Les fournisseurs doivent proposer des données mises à jour, car les problèmes sont identifiés dans les SBOM passées, et les utilisateurs doivent accepter ces mises à jour et corrections sans pénalité pour encourager une amélioration continue.
Les exigences SBOM continueront probablement à croître et à évoluer. Davantage de champs de données et l’ajout de scores de sécurité, de listes de vulnérabilités et d’autres informations peuvent être accompagnés de directives mises à jour. Bien que les organisations soient uniquement tenues de répondre aux exigences minimales d’une SBOM, inclure des informations pertinentes supplémentaires sur un produit logiciel montrera un engagement fort en matière de transparence et de sécurité.
Qu’est-ce que le cycle de vie du développement SBOM ?
Idéalement, les SBOM doivent être générées automatiquement chaque fois que le logiciel est déployé et inclure un inventaire aussi complet que possible. Le cycle de vie SBOM facilite cela en fournissant un processus d’identification des applications, en créant des SBOM et en les mettant à la disposition des utilisateurs finaux.
« Les nomenclatures doivent être générées automatiquement chaque fois que le logiciel est déployé et inclure un inventaire aussi complet que possible. »
Il se compose des cinq étapes suivantes :
- Découverte des actifs : la première étape consiste à trouver l’application pour laquelle vous devez fournir une SBOM. Il est préférable d’utiliser un outil de découverte des actifs pour assurer une visibilité complète sur toutes vos applications.
- Analyse des données d’application : les données d’application requises pour le SBOM sont collectées.
- Création SBOM : le fichier SBOM est créé, y compris toutes les données d’application pertinentes. Cela doit être fait chaque fois qu’il y a une nouvelle version de l’application pour s’assurer que la SBOM correspond toujours à l’état actuel du logiciel.
- Stockage SBOM : les SBOM doivent être stockés de manière centralisée et sécurisée à l’aide du chiffrement.
- Recherche SBOM : l’étape finale consiste à assurer la fonctionnalité de recherche pour le SBOM afin que l’utilisateur final puisse rechercher toute vulnérabilité potentielle.
Quelles sont les normes SBOM ?
Une norme SBOM est un schéma pour détailler la composition du logiciel dans un fichier lisible par machine qui peut être consommé par d’autres outils tels que les scanners de vulnérabilité et les traceurs de licences logicielles. Actuellement, il existe trois normes principales pour générer des SBOM et les partager 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 communiquer les données SBOM telles que les composants, licences, droits d’auteur et informations de sécurité d’une application dans plusieurs formats de fichiers.
- CycloneDX—CycloneDX est une autre norme ouverte, développée par la communauté OWASP. Il est basé sur la norme SPDX, mais a été rationalisé pour une mise en œuvre et une utilisation plus faciles
- SWID—SWID, abréviation de Software Identification Tags, est un type de métadonnées qui peut être généré automatiquement par de nombreuses applications pour décrire et contextualiser les composants du logiciel.
La NTIA a sélectionné ces trois normes SBOM comme acceptables, car, en plus d’être lisibles par l’homme, elles sont également lisibles par machine et peuvent prendre en charge l’automatisation pour faciliter l’utilisation et la mise à l’échelle des SBOM par les utilisateurs finaux dans l’ensemble de leur organisation.
[Lire également : l’avenir de la gestion des risques est axé sur 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.
Un obstacle principal est le manque de standardisation. Les SBOM sont susceptibles d’être plus efficaces lorsque l’ensemble de la chaîne d’approvisionnement adhère aux mêmes normes, processus et outils. Cependant, ces premiers jours, il existe peu de consensus sur l’un d’entre eux, et un manque d’uniformité entre les fournisseurs de logiciels et les utilisateurs finaux est inévitable. Cela peut entraîner un temps supplémentaire passé à disséquer et à adapter les SBOM à la commande.
« Les nomenclatures sont susceptibles d’être plus efficaces lorsque l’ensemble de la chaîne d’approvisionnement adhère aux mêmes normes, processus et outils. Cependant, ces premiers jours, il y a peu de consensus sur l’un de ces points. »
Un autre défi est la nécessité d’adapter continuellement les SBOM. Chaque fois qu’il existe une nouvelle version d’une application, elle doit inclure une nouvelle SBOM qui reflète l’état actuel de l’application. Il est donc essentiel d’adopter des outils de gestion SBOM qui peuvent intégrer la génération SBOM dans le cycle de vie du développement logiciel.
La mise à l’échelle des SBOM alors que vous prenez en charge plus de partenaires de la chaîne d’approvisionnement peut également être un problème si vous utilisez des méthodes traditionnelles pour les générer, telles que des feuilles de calcul et des e-mails. De plus, ces méthodes manuelles prennent du temps, sont sujettes aux erreurs et peuvent rendre difficile le suivi des relations hiérarchiques entre les composants.
Quelles sont les meilleures pratiques pour créer une SBOM efficace ?
Les meilleures pratiques suivantes peuvent vous aider à créer des SBOM efficaces :
- Utilisez un format cohérent : il est important de suivre un format standard lors de la structuration des données SBOM. SPDX, CycloneDX et SWID sont les plus populaires, mais en fin de compte, votre choix de format est moins important que de l’utiliser de manière cohérente.
- Automatisez la création de SBOM : la génération automatique de SBOM dans le cadre de votre pipeline de livraison de logiciels présente plusieurs avantages. Cela permettra principalement aux développeurs de gagner du temps, car ils n’auront pas à créer chaque SBOM manuellement. Il est également plus probable que les SBOM fassent partie intégrante de votre cycle de mise à disposition de logiciels. Enfin, il vous permet de répondre aux exigences définies par l’EO Biden pour fournir des services informatiques au gouvernement fédéral.
- Mettre à jour les SBOM avec chaque version : une SBOM doit être spécifique à chaque version du logiciel, y compris chaque fois qu’une application est mise à jour. L’automatisation est essentielle ici ; si les développeurs doivent mettre à jour manuellement leur SBOM à chaque mise à jour d’application, elle est beaucoup moins susceptible de se produire.
- Inclure des métadonnées complètes : bien qu’il n’y ait pas de normes SBOM universelles, vous devez vous entraîner à inclure autant de métadonnées que possible dans chaque SBOM. Cela réduira la quantité d’informations dont vos utilisateurs finaux auront besoin pour rechercher manuellement et démontrer votre engagement en faveur de la sécurité et de la transparence. Il facilite également la mise à jour.
