Principaux points à retenir de cet article :
Une nomenclature logicielle (SBOM) répertorie chaque composant de votre logiciel, garantissant ainsi clarté et contrôle sur les chaînes d'approvisionnement.
Les SBOM permettent des réponses rapides aux vulnérabilités, comme on le voit avec Log4j et SolarWinds, renforçant les défenses de la chaîne d'approvisionnement.
Les mandats réglementaires tels que PCI DSS et les exigences gouvernementales lient directement la sécurité à l’adoption du SBOM.
L’automatisation de la génération SBOM élimine les erreurs et garantit un suivi des vulnérabilités à jour.
L'analyse SBOM sans agent de Wiz offre des informations en temps réel, aidant les équipes à rester au courant des environnements logiciels en constante évolution.
Qu'est-ce qu'un SBOM ?
Une nomenclature logicielle (SBOM) est un inventaire complet qui détaille chaque composant logiciel qui constitue une application. Il comprend des bibliothèques tierces open source et commerciales, des appels d'API, des versions et des licences.
Les applications utilisées dans l'écosystème de la chaîne d'approvisionnement sont un amalgame d'éléments provenant de plusieurs sources. Ces sources peuvent contenir des vulnérabilités que les cybercriminels pourraient exploiter lors d'attaques de la chaîne d'approvisionnement. Les SBOM facilitent la gestion des vulnérabilités en fournissant des informations sur ces éléments.
Lorsqu'ils sont intégrés au cycle de vie de livraison de logiciels (SDLC), les SBOM améliorent la visibilité sur l'état des correctifs et des licences des logiciels tiers et fournissent d'autres informations liées à la sécurité qui peuvent renforcer l'intégrité du code.
Le rôle de SBOM dans la sécurité de la chaîne d'approvisionnement des logiciels
Avec l’augmentation des attaques sur la chaîne d’approvisionnement, les SBOM sont devenus des outils essentiels pour le suivi et la sécurisation des composants logiciels. Gartner estime que d’ici 2025, 60 % des organisations auront besoin de SBOM dans le cadre de leurs pratiques de cybersécurité, soit une augmentation significative par rapport aux 20 % de 2022. Les mandats gouvernementaux, tels que le décret de la Maison Blanche sur l’amélioration de la cybersécurité nationale , exigent désormais également des SBOM pour les organisations travaillant avec des agences gouvernementales.
Les incidents Log4j et SolarWinds soulignent l’importance des SBOM :
Vulnérabilité Log4j (CVE-2021-44228): cette bibliothèque Java largement utilisée a créé un cauchemar de sécurité pour les organisations du monde entier. Sans SBOM, de nombreuses entreprises ont dû se démener pour déterminer quels composants étaient à risque. Et celles qui disposaient de SBOM ? Elles ont rapidement identifié les composants affectés, évitant ainsi des conséquences massives.
Attaque SolarWinds : En 2020, des attaquants ont compromis le logiciel SolarWinds Orion, affectant environ 18 000 clients, dont des entreprises de premier plan et des agences gouvernementales. Un SBOM aurait pu mettre un terme au chaos, en aidant les victimes à retracer rapidement le malware et à réagir efficacement.
Bonnes pratiques de sécurité CI/CD [Aide-mémoire]
Apprenez-en plus sur la sécurité de l'infrastructure, la sécurité du code, l'accès et la surveillance avec des éléments exploitables, des extraits de code et des captures d'écran.
Obtenez la feuille de triche
Pourquoi les SBOM sont-elles importantes ?
Les SBOM fournissent une liste détaillée de tous les composants d'une application logicielle, aidant ainsi les organisations à identifier et à gérer les risques de sécurité. Ils améliorent également la transparence, facilitent le suivi et la mise à jour des dépendances logicielles, et bien plus encore :
1. Transparence et visibilité
Considérez les SBOM comme le plan directeur de votre logiciel. Ils offrent aux développeurs une vue claire de tous les composants logiciels tiers, comme les bibliothèques open source, utilisés dans leurs applications. Cette transparence aide les équipes à évaluer les risques avant d'ajouter une bibliothèque et à rester au courant des vulnérabilités après le déploiement.
2. Conformité réglementaire
Les gouvernements et les normes industrielles ayant pris des mesures de sécurité strictes, les SBOM sont devenus un élément essentiel de la conformité. De la norme PCI DSS à la norme HIPAA, de nombreuses réglementations exigent désormais un enregistrement clair des composants logiciels. Un SBOM permet non seulement de répondre à ces exigences, mais également d'éviter à votre organisation des ennuis, qu'il s'agisse d'amendes ou d'atteintes à la réputation dues à des problèmes de licence.
3. Réponse aux incidents et analyses médico-légales
En cas de problème, un SBOM peut s'avérer une véritable bouée de sauvetage. Il identifie précisément le composant vulnérable, ce qui aide les équipes à se concentrer sur la zone problématique, à hiérarchiser leur réponse et à évaluer l'impact plus large.
Que doit inclure un SBOM ?
Un SBOM doit inclure des détails sur tous les composants logiciels open source et propriétaires utilisés dans un produit, y compris leurs noms, versions et licences. Il doit également spécifier les relations entre les composants et leurs dépendances.
Les éléments clés suivants doivent être présents dans un SBOM :
1. Identifiants des composants : cela inclut les métadonnées telles que les noms des fournisseurs et des composants, les origines des composants, la description et les responsables, l'ID de l'artefact, l'horodatage, le numéro de version et les références spécifiques, telles que les ID de validation Git ou les hachages SHA-1 pour chaque composant.
2. Dépendances : La relation entre chaque composant et ses dépendances doit être clairement documentée.
3. Informations sur la version : elles incluent le numéro de version du logiciel, le nom du fichier et le système d'exploitation pour faciliter l'installation et éviter les problèmes de compatibilité. Les informations sur la version vous permettent de suivre les mises à jour ou les correctifs nécessaires pour chaque composant.
4. Données de vulnérabilité : il est essentiel d'inclure des informations sur les vulnérabilités connues associées à chaque composant. Ces données peuvent être obtenues à partir de catalogues de vulnérabilités tels que la National Vulnerability Database (NVD) ou CVE (Common Vulnerabilities and Exposures).
5. Informations sur les licences : chaque composant est soumis à des conditions de licence (par exemple, licences MIT, Apache et BSD). Le SBOM doit contenir ces conditions pour garantir le respect des obligations de licence.
7. Références externes : il s'agit notamment des URL ou de la documentation relative à chaque composant. Elles fournissent un contexte supplémentaire sur les fonctions des composants.
Le SBOM sans agent de Wiz vous permet d'obtenir une visibilité complète des composants de vos applications, y compris les packages, les bibliothèques open source et les dépendances imbriquées, sans angles morts et sans déployer d'agent.
Apprendre encore plus
Formats SBOM courants
Les SBOM peuvent être générés manuellement ou automatiquement.
La méthode manuelle consiste à répertorier tous les composants logiciels ainsi que leurs versions, licences et dépendances respectives dans des feuilles de calcul. Elle ne convient qu'aux déploiements à petite échelle et est sujette aux erreurs humaines.
La méthode automatique implique l'intégration des outils SBOM dans le pipeline d'intégration continue/déploiement continu (CI/CD).
Après la génération, les SBOM sont structurés en deux formats principaux : CycloneDX et Software Package Data Exchange (SPDX). Vous trouverez ci-dessous une brève description de chacun d'eux.
| Format | Description |
|---|---|
| SPDX | SPDX prend en charge la représentation des informations SBOM, telles que l'identification des composants et les informations de licence, ainsi que la relation entre les composants et l'application. SPDX permet la collecte et le partage d'informations dans divers formats de fichiers, notamment des formats lisibles par l'homme et analysables par machine tels que JSON, XML et YAML. Il améliore la transparence et facilite la conformité des licences. |
| CycloneDX | CycloneDX permet de répertorier les composants/services internes et externes qui composent les applications, ainsi que leurs interrelations, l'état des correctifs et les variantes. Il structure les données sous forme de fichier XML ou JSON et vous permet d'ajouter des détails tels que les scores et descriptions du Common Vulnerability Scoring System (CVSS) au SBOM. CycloneDX est hautement extensible, ce qui permet aux développeurs d'ajouter de nouvelles fonctionnalités selon les besoins. |
Pour vous donner une meilleure compréhension des formats SBOM, considérez cet exemple de l'inventaire CycloneDX au format JSON :
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"version": 1,
"components": [
{
"type": "library",
"name": "nacl-library",
"version": "1.0.0"
}
]
}Outre les deux formats décrits ci-dessus, les organisations peuvent également utiliser des balises d'identification logicielle (SWID), qui sont généralement installées lors du déploiement. Les balises SWID fournissent des informations SBOM telles que les dates de sortie et les licences des composants logiciels. Les organismes de réglementation et le gouvernement américain considèrent les balises SWID, CycloneDX et SPDX comme des formats SBOM acceptables .
Mise en œuvre de SBOM : un guide étape par étape
Créer un SBOM peut sembler intimidant, mais le diviser en étapes gérables peut faciliter le processus. Voici comment commencer :
| Step | Process |
|---|---|
| 1. Choisissez les outils SBOM | Commencez avec des outils adaptés à votre flux de travail. Qu'il s'agisse d'options open source comme CycloneDX et SPDX ou d'outils commerciaux, assurez-vous qu'ils sont à la hauteur de la tâche. Recherchez ceux qui se synchronisent parfaitement avec vos pipelines CI/CD et qui peuvent gérer l'ampleur de vos opérations grâce à l'automatisation. |
| 2. Automatisez la génération SBOM | La génération manuelle de SBOM est source d'erreurs et de frustration. Automatisez-la plutôt. Configurez des scripts ou des plugins CI/CD qui mettent à jour votre SBOM à chaque fois qu'une nouvelle version est publiée. Cela permet de maintenir les choses à jour et de faire gagner du temps et des efforts à votre équipe. |
| 3. Suivre et mettre à jour les composants logiciels | Les logiciels ne sont pas statiques : ils évoluent. Surveillez les composants tiers pour détecter les nouvelles versions, les correctifs ou les vulnérabilités. Faites de la révision et de la mise à jour de votre SBOM une habitude régulière. Cette approche proactive vous permet d'être prêt à agir rapidement lorsque des risques de sécurité apparaissent. |
| 4. Examiner et surveiller la conformité | Les réglementations peuvent être une cible mouvante, alors intégrez des contrôles de conformité dans votre routine. Chaque composant est-il conforme aux normes de licence et de sécurité ? Réalisez des audits pour vérifier. Un SBOM transparent et à jour est votre filet de sécurité pour éviter les surprises lors d'un audit ou d'une violation. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
En savoir plus
L'approche de Wiz en matière de sécurité SBOM
Wiz Code améliore la sécurité SBOM (Software Bill of Materials) en offrant une visibilité complète sur les composants et les dépendances de votre logiciel. Grâce à l'analyse en temps réel et aux contrôles de sécurité automatisés, Wiz Code garantit que les vulnérabilités des bibliothèques tierces et des composants open source sont identifiées et atténuées en amont.
Certains avantages du déploiement SBOM sans agent incluent :
Flexibilité et simplicité : les agents dédiés sont des services complémentaires qui consomment des ressources et nécessitent une maintenance continue, ce qui augmente les frais de maintenance. Le déploiement SBOM sans agent réduit également les coûts et élimine les problèmes de compatibilité agent-système d'exploitation.
Visibilité instantanée et complète : les agents doivent être installés sur chaque sous-système de la pile logicielle. Un SBOM sans agent vous offre une vue complète des composants de vos applications, des bibliothèques open source utilisées au package et aux dépendances imbriquées, en quelques minutes, sans angles morts.
Recherche SBOM : recherchez et localisez rapidement des systèmes d'exploitation et des packages open source spécifiques dans des environnements cloud. Cette fonctionnalité est particulièrement opportune compte tenu des vulnérabilités critiques récemment découvertes dans des bibliothèques largement utilisées comme xz-utils .
Toujours à jour : les agents nécessitent une installation manuelle qui peut être sujette aux erreurs, tandis qu'une approche sans agent vous permet de générer des SBOM à jour sans intervention manuelle.
Génération SBOM sans agent
Obtenez une visibilité complète des composants de vos applications, y compris les packages, les bibliothèques open source et les dépendances imbriquées, sans angles morts. Obtenir une démo
