Le besoin de SBOM — Partie 2
Interlynk
Écrire des logiciels ou des composants logiciels depuis zéro est rare dans le développement logiciel moderne. Des bibliothèques et des frameworks préexistants fournissent la base pour développer de nouvelles fonctionnalités, et ce nouveau produit peut devenir la base d'un autre produit.
Cependant, cette superposition de logiciels et de composants peut créer des angles morts pour le développeur et les consommateurs. Dans Partie-1, nous avons discuté de la manière dont la superposition crée un défi pour identifier les vulnérabilités de type zero-day (expérimentées dans le monde entier avec log4shell).
D'autres risques sont associés aux logiciels de composition inconnue, notamment :
le risque d'inclure des composants avec une licence restrictive
des composants en fin de vie, ou
des composants influencés par des acteurs étatiques.
La fabrication a traité des préoccupations similaires dans la gestion de la chaîne d'approvisionnement et de l'inventaire en construisant des Bill of Materials (BOM), la gestion de l'obsolescence, la notification de changement de produit (PCN) et la gestion de la fin de vie (EOL).
SBOM apporte ces apprentissages et pratiques au développement logiciel.
Liste des matériaux logiciels (SBOM)
Au fond, le SBOM est un document décrivant les composants du logiciel, leurs fournisseurs et les relations entre les composants (couche), ainsi que quelques métadonnées pour en comprendre l'ensemble.
SBOM conceptuel — Source : Encadrer la transparence des composants logiciels
CISA recommande de construire des SBOM selon les spécifications existantes :
Ces spécifications sont très flexibles, et donc, CISA a également recommandé des éléments minimum pour un SBOM afin de s'assurer que le SBOM généré peut être utilisé pour traiter les risques mentionnés ci-dessus.
Cas d'utilisation SBOM
Un SBOM complet peut aider à résoudre les problèmes suivants :
1. Inventaire des composants Un SBOM complet inclut tous les composants, y compris les composants imbriqués, et peut donc constituer un inventaire de composants pour le produit.
2. Inventaire des licences Un SBOM complet inclut toutes les licences associées à chaque composant et, par conséquent, peut être utilisé pour créer et surveiller l'inventaire des licences. C'est une partie critique de la gestion des risques associés aux licences open-source.
3. Gestion des vulnérabilités Un composant bien décrit dans un SBOM suit des conventions de nommage de composants largement utilisées telles que CPE, PURL ou tag SWID. Un nom de composant exact peut être utilisé pour des recherches de vulnérabilités dans des bases de données telles que NVD et OSV. Comme le SBOM prend en charge les relations imbriquées (et bien d'autres types de relations), cela résout le problème de recherche de vulnérabilités décrit dans Partie-1.
4. Gestion de l'obsolescence et de la fin de vie Au fur et à mesure que le produit vieillit, la constitution d'un inventaire de composants permet au SBOM de suivre les composants obsolètes ou EOL.
5. Divulgation de l'exploitabilité des vulnérabilités Le SBOM peut être combiné avec VEX pour communiquer l'état des vulnérabilités associées au produit. Cela aide à réduire le bruit dans les cas où les outils d'analyse de composition logicielle analysent un produit. Une introduction à la divulgation de l'exploitabilité des vulnérabilités est ici.
Défis SBOM
Le potentiel des SBOM a été clair pour les organisations qui les construisent. Cependant, plusieurs cas d'utilisation décrits ci-dessus incluent des phrases : SBOM complet, composant bien décrit et nom exact du composant.
Construire un SBOM complet ou utiliser un nom exact pour un composant est un véritable défi. Ces défis peuvent frustrer les adopteurs précoces ou créer une résistance peu sincère contre les SBOM.
Dans la partie 3 — Comment les défis des SBOM sont des opportunités et non des risques.