SBOM : sécuriser la chaîne d’approvisionnement logicielle

Alors que les acteurs malveillants ciblent les chaînes d’approvisionnement, le renforcement de la cybersécurité a récemment été le moteur de l’adoption du cadre Software Bill of Materials (SBOM) par les entreprises.

Grâce à une simple liste des composants qui constituent un produit logiciel, les SBOM améliorent la transparence entre acheteurs et vendeurs de logiciels, offrent la visibilité nécessaire pour identifier les vulnérabilités et permettent une réponse rapide aux incidents. Les SBOM s’attaquent directement aux inefficacités du processus de développement logiciel qui créent un déficit de visibilité entre les clients qui s’appuient sur les fonctionnalités du logiciel et les connaissances du développeur ou du fournisseur concernant sa conception et ses composants sources.

Les SBOM offrent également une protection contre les risques liés aux licences et à la conformité associés aux SLA grâce à un inventaire détaillé des composants logiciels. Lorsque l’on examine l’efficacité potentielle de l’adoption des SBOM, la standardisation des pratiques de la chaîne d’approvisionnement logicielle ne présente aucun inconvénient puisqu’elle atténue les risques critiques liés à l’informatique, à l’entreprise et aux tiers et réduit les coûts d’une organisation.

Cet article examine les nomenclatures logicielles, les données des fichiers, les normes existantes, les avantages, les cas d’usage et ce que les SBOM impliquent pour la cybersécurité.

Aller à :

• Qu’est-ce qu’une nomenclature logicielle (SBOM) ?
• Que contient un fichier SBOM ?
• Besoin de standardisation
• Le Vulnerability-Exploitability eXchange (VEX)
• Avantages de l’adoption des SBOM
• Comment créer une SBOM
• Preuve de concept : SBOM dans le secteur de la santé
• Ce que les SBOM impliquent pour la cybersécurité

Qu’est-ce qu’une nomenclature logicielle (SBOM) ?

Une nomenclature logicielle (SBOM) est un inventaire lisible par machine des composants, dépendances, métadonnées et relations hiérarchiques d’un produit logiciel donné. Avec un univers de composants open source et propriétaires, les SBOM assurent la transparence en identifiant les éléments présentant des risques ou ultérieurement considérés comme vulnérables aux attaques.

Le cadre SBOM concerne les unités logicielles identifiées par les développeurs et les fournisseurs, appelées composants et les données associées, appelées attributs. Dans son ensemble, un produit logiciel constitue le composant principal et contient souvent plusieurs composants en amont, avec une entrée SBOM pour chacun afin de former un fichier collectif.

L’étiquette nutritionnelle des logiciels

Tout comme ils consultent une étiquette nutritionnelle dans un supermarché, les organismes peuvent utiliser les SBOM pour évaluer le code source d’un produit avant de l’acheter. Lorsque le médecin informe par la suite le client d’une nouvelle allergie ou d’un problème de santé, c’est au patient de revenir sur ses achats et de jeter les aliments concernés. 

Dans le cas des composants logiciels, les vulnérabilités exploitables sont régulièrement identifiées et nécessitent une remédiation prioritaire. Sans l’équivalent d’une étiquette nutritionnelle pour les logiciels utilisés, les organismes auraient du mal à corriger les systèmes vulnérables. Les renseignements sur les menaces peuvent aider à analyser les environnements informatiques à la recherche des logiciels malveillants les plus récents, mais il ne s’agit que d’une couche de sécurité contre les menaces zero-day.

À lire aussi : Des failles dans la chaîne d’approvisionnement découvertes dans le dépôt de paquets Python

Le problème des chaînes d’approvisionnement logicielles

Puisque tous les logiciels contiennent des vulnérabilités, comprendre les composants du code acheté, utilisé ou développé devient de plus en plus essentiel pour préserver l’intégrité des environnements informatiques.

Il n’existe pas de stratégie de gestion des logiciels totalement à l’abri des risques ; les organismes doivent donc s’efforcer d’être conscients des risques. Au nouveau millénaire, l’essor de la méthode de programmation Agile se traduit par des cycles de développement plus courts et des déploiements d’applications plus fréquents, ce qui accroît également le risque de versions instables. Si l’on ajoute le mélange de composants logiciels open source et propriétaires dans les solutions, la chaîne d’approvisionnement logicielle est, à juste titre, complexe.

Compte tenu du volume considérable de développements en cours, les organismes doivent adopter une approche plus offensive de la gestion des risques liés aux tiers.

Cas d’usage des SBOM

Les principaux cas d’usage des SBOM résident dans leur application à la gestion des vulnérabilités de la chaîne d’approvisionnement et aux processus d’assurance de l’intégrité des produits.

À lire aussi : Comment se défendre contre les vulnérabilités courantes de la sécurité informatique

Que contient un fichier SBOM ?

Bien que quelques formats gagnent du terrain, il n’existe pas de structure SBOM universellement acceptée. La National Telecommunication and Information Administration (NTIA) reconnaît que les attributs de référence des composants actuellement proposés sont volontairement élémentaires, tout en laissant la possibilité de poursuivre leur développement et de les adapter selon le secteur. Le groupe de travail de la NTIA sur le cadre de transparence des composants logiciels a déclaré :

“C’est l’une des principales raisons d’établir un ensemble d’informations aussi élémentaire comme point de départ, plutôt que d’exiger dès le début un ensemble d’attributs plus robuste, dont la collecte et la maintenance pourraient nécessiter davantage de temps et de ressources.«

Les attributs de référence proposés pour les composants

Certains attributs peuvent nécessiter plusieurs données, comme les noms des fournisseurs, tandis que l’auteur du fichier SBOM peut ne pas être en mesure de renseigner certains autres champs en fonction de la visibilité dont il dispose. Dans ce dernier cas, l’auteur doit préciser si les données du champ sont inconnues, inexistantes, partiellement connues ou connues.

Parmi les autres attributs potentiels à prendre en compte figurent les informations d’utilisation, les licences, les dates de fin de vie, les avis de tiers, les regroupements de composants et la manière dont les composants affectent les systèmes en aval. Dans tous les cas, l’authentification cryptographique des SBOM est impérative pour vérifier leur authenticité.

L’importance des relations entre composants

Qu’ils soient open source, propriétaires ou combinés, les composants qui s’intègrent aux logiciels actuels et leurs relations ont un impact sur les résultats des organismes. En partant du composant principal, les développeurs et les fournisseurs peuvent définir les relations avec les composants en amont qui concernent l’historique de la chaîne d’approvisionnement du produit.

À lire aussi : Les cyberattaques multipartites entraînent de lourdes pertes

Dans le graphique suivant, la NTIA fournit un exemple conceptuel de représentation des relations d’une application logicielle. Dans cet exemple, la SBOM contient quatre composants : le composant principal et trois composants en amont. Bien que d’autres composants puissent exister au-delà de ces quatre éléments, les auteurs de SBOM doivent travailler avec les connaissances disponibles. Comme le montrent l’organigramme et le tableau, les SBOM peuvent donner une image détaillée des composants et de leurs relations au sein de la chaîne d’approvisionnement logicielle.

Besoin de standardisation

Les SBOM doivent respecter des formats acceptés par le secteur, qui permettent l’interopérabilité entre différents secteurs et organismes afin de rendre leur adoption possible. Quelques normes étant déjà en place, les organismes disposent du cadre nécessaire pour rédiger, maintenir et partager rapidement les données des composants logiciels.

SPDX : Software Package Data Exchange

Développé par la Linux Foundation en 2010, Software Package Data Exchange (SPDX) est le principal standard ouvert pour les formats SBOM. Les fichiers SPDX incluent les composants logiciels, les droits d’auteur, les licences et les références de sécurité.

La spécification SPDX respecte la norme minimale proposée par la NTIA pour une SBOM et les cas d’usage de l’analyse des vulnérabilités, de la conformité des licences et plus encore. Avec SPDX Lite, les organismes peuvent utiliser un sous-ensemble compact de la norme SPDX pour échanger des données. En août 2021, SPDX est devenu une norme officielle sous la référence ISO/IEC 5962.

SWID : Software Identification Tagging

Vers la fin des années 2010, l’International Organizations for Standards (ISO) a commencé à développer une norme permettant d’étiqueter les composants logiciels avec des identifiants lisibles par machine. Les balises Software Identification (SWID), comme on les appelle désormais, sont des métadonnées structurées intégrées aux logiciels qui communiquent le nom du produit logiciel, sa version, ses développeurs, ses relations et plus encore.

À l’instar de la gestion des actifs logiciels (SAM), les balises SWID peuvent contribuer à automatiser la gestion des correctifs, la validation de l’intégrité des logiciels, la détection des vulnérabilités et l’autorisation ou le blocage des installations de logiciels. La norme ISO/IEC 19770-2 a été confirmée en 2012 et mise à jour en 2015.

CycloneDX d’OWASP

La fondation OWASP a conçu CycloneDX en 2017 dans le cadre de sa solution open source d’analyse des composants logiciels, Dependency-Track. Avec des cas d’usage tels que l’identification des vulnérabilités, la conformité des licences et l’analyse des composants obsolètes, CycloneDX est un standard léger destiné à de nombreux secteurs. La quatrième itération de CycloneDX (1.3) a été publiée en mai 2021.

À lire aussi : OWASP nomme une nouvelle vulnérabilité critique pour la première fois depuis des années

Le Vulnerability-Exploitability eXchange (VEX)

Développé par la NTIA, le Vulnerability-Exploitability eXchange (VEX) fournit une déclaration sur le statut de vulnérabilités spécifiques dans les produits logiciels. En émettant un VEX, les fournisseurs de logiciels informent leurs clients de vulnérabilités spécifiques qui pourraient ne pas être exploitables. Voici quelques exemples de statuts de vulnérabilités non exploitables :

Comme les SBOM, le format VEX fournit un cadre favorisant davantage de transparence entre les parties prenantes du logiciel. Pour les organismes d’entreprise, le VEX est également lisible par machine et permet l’ingestion à grande échelle ainsi que l’automatisation de la gestion des vulnérabilités des composants logiciels.

Avantages de l’adoption des SBOM

Les nomenclatures logicielles sont utiles à tout organisme qui accorde de l’importance à la réduction des risques supplémentaires et aux bonnes pratiques de cybersécurité. Les fournisseurs de solutions de gestion des vulnérabilités, de gestion des risques liés aux tiers et d’analyse de la composition logicielle intègrent déjà des services SBOM pour aider les organismes dans leur transition.

• Rationaliser le partage d’informations sur les composants logiciels et les vulnérabilités
• Partager facilement une SBOM produit via des fichiers de données courants (json, xml, html, pdf ou txt)
• Renforcer l’intégrité de la chaîne d’approvisionnement grâce à des développeurs, fournisseurs et clients mieux informés
• Accélérer le déploiement et la restauration des correctifs essentiels et des mesures correctives
• Améliorer la tenue des registres pour les audits logiciels et les normes de conformité réglementaire
• Améliorer la visibilité sur les logiciels opérationnels, les composants et les relations entre les systèmes

Comment créer une SBOM

Les nomenclatures logicielles doivent être des documents évolutifs, mis à jour afin de fournir la visibilité la plus précise possible sur les composants du code source utilisés. Pour gérer les SBOM, les organismes doivent d’abord identifier les éléments pertinents de leur inventaire logiciel, tels que les informations non sécurisées, les vulnérabilités, les licences et les versions.

1. Collecter les données des composants, énumérer les données d’attributs et créer la SBOM
2. Effectuer les premières mises au point avant de produire le fichier principal des composants
3. Examiner et finaliser le fichier avant sa diffusion aux parties prenantes et aux clients potentiels
4. Surveiller l’intégrité du fichier, corriger les modifications identifiées et mettre le fichier à jour

Même si les prestataires fédéraux américains seront les premiers à être tenus de créer des SBOM, leurs défenseurs ont une vision mondiale de leur intégration au processus de développement logiciel. À mesure que les normes existantes gagneront en popularité, créer une SBOM associée pour chaque nouveau composant logiciel deviendra une bonne pratique. Il en résultera un écosystème plus robuste, fondé sur la transparence.

À lire aussi : Des attaquants exploitent une faille susceptible d’affecter des millions de routeurs et d’appareils IoT

Preuve de concept : SBOM dans le secteur de la santé

En octobre 2019, la NTIA a publié la phase I de son initiative visant à développer une preuve de concept de SBOM pour assurer la transparence des composants logiciels. Les fabricants de dispositifs médicaux (MDM) produisant des SBOM à l’usage des organismes de prestation de soins de santé (HDO) ont ouvert la voie, et le résultat a constitué une base pour la poursuite du développement.

Deux ans plus tard, la NTIA a achevé la phase II. Dans les conclusions publiées au début du mois, la phase II a validé les éléments de référence acceptés et SPDX, énuméré les composants logiciels standard et fourni un guide pratique pour les producteurs, tout en explorant les cas d’usage de VEX. Les objectifs de la phase III comprennent l’accélération de l’adoption dans le secteur de la santé, l’automatisation de l’échange de SBOM et le traitement des inefficacités liées aux produits et services en fin de vie.

Ce que les SBOM impliquent pour la cybersécurité

Parmi les objectifs de la sécurité de l’information — confidentialité, intégrité et disponibilité — les nomenclatures logicielles contribuent principalement à préserver l’intégrité des données et des systèmes des organismes. En tant que document formel sur les logiciels utilisés ou en cours de développement, les fichiers de composants logiciels peuvent introduire des risques supplémentaires lorsqu’il s’agit de protéger les secrets propriétaires. De même, une SBOM n’a pas d’incidence directe sur la disponibilité des données.

Les SBOM constituent un précédent dans le secteur, qui renforce la transparence entre les développeurs, les fournisseurs de logiciels et les clients. Grâce à des normes établies, les organismes peuvent communiquer de manière sécurisée à leurs partenaires les détails du code source pendant le processus contractuel. À mesure que les SBOM se généraliseront, les organismes seront mieux armés pour identifier les bogues, les vulnérabilités et les menaces zero-day. Pour les professionnels de la cybersécurité du monde entier, l’adoption des SBOM est clairement bénéfique.

À lire aussi : La faille de Kaseya souligne la vulnérabilité des services informatiques gérés