Qu’est-ce qu’un SBOM ?
Une nomenclature logicielle (SBOM) répertorie tous les composants de votre logiciel, garantissant ainsi la clarté et le contrôle des chaînes d’approvisionnement.
Les SBOM permettent de réagir rapidement aux vulnérabilités, comme on l’a vu avec Log4j et SolarWinds, renforçant ainsi 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 de 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 fait de l’évolution des environnements logiciels.
Qu’est-ce qu’un SBOM ?
Une nomenclature logicielle (SBOM) Il s’agit d’un inventaire complet qui détaille chaque composant logiciel qui compose une application. Il comprend open-source et les bibliothèques tierces commerciales, les appels d’API, les versions et les 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. Facilité des SBOM Gestion des vulnérabilités en fournissant des informations sur ces éléments.
Gartner prévoit que d’ici 2025,
SBOM'dans la sécurité de la chaîne d’approvisionnement logicielle
Avec l’augmentation des attaques de la chaîne d’approvisionnement, les SBOM sont devenus des outils essentiels pour suivre et sécuriser les composants logiciels. Gartner estime que d’ici 2025, 60 % des organisations auront besoin de SBOM dans le cadre de leurs pratiques de cybersécurité, une augmentation significative par rapport aux 20 % de 2022. mandats gouvernementaux, tels que ceux de la Maison-Blanche Décret présidentiel sur l’amélioration de la nation's Cybersécurité, exige également des SBOM pour les organisations travaillant avec des organismes gouvernementaux.
Les incidents de Log4j et de 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 se sont retrouvées à se débrouiller, à reconstituer les composants à risque. Ceux qui ont des SBOM, cependant ? Ils ont rapidement localisé les composants touchés, évitant ainsi des retombées 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 semer dans le chaos, en aidant les victimes à retrouver rapidement le logiciel malveillant et à réagir efficacement.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet
Pourquoi les SBOM sont importants
Les SBOM fournissent une liste détaillée de tous les composants d’une application logicielle, ce qui aide 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 plus encore :
1. Transparence et visibilité
Considérez les SBOM comme le modèle de votre logiciel. Ils donnent aux développeurs une vue claire de tous les composants logiciels tiers, tels que les bibliothèques open source, utilisés dans leurs applications. Cette transparence permet aux équipes d’évaluer les risques avant d’ajouter une bibliothèque et de rester à l’affût des vulnérabilités après le déploiement.
2. Conformité réglementaire
Avec les gouvernements et les normes de l’industrie qui répriment la sécurité logicielle, 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 aussi 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 criminalistique
En cas de problème, un SBOM peut vous sauver la vie. Il identifie exactement quel composant est vulnérable, aidant les équipes à se concentrer sur la zone problématique. prioriser leur réponse, et d’évaluer l’impact plus large.
Qu’est-ce qu’un SBOM doit inclure ?
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.
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.
1. Identificateurs de composants : Cela inclut des métadonnées telles que les noms des fournisseurs et des composants, les origines des composants, la description et les mainteneurs, l’ID d’artefact, l’horodatage, le numéro de version et des 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 : Cela inclut le numéro de version du logiciel, le nom de fichier et le système d’exploitation pour faciliter l’installation et éviter les problèmes de compatibilité. Les informations de 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 a des conditions de licence (par exemple, les licences MIT, Apache et BSD). Le SBOM doit contenir ces conditions pour assurer le respect des obligations de licence.
7. Références externes : Il s’agit notamment d’URL ou de documentation relatives à chaque composant. Ils fournissent un contexte supplémentaire sur les fonctions des composants.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Formats SBOM courants
Les SBOM peuvent être générés manuellement ou automatiquement.
Le Méthode manuelle Il s’agit de répertorier tous les composants logiciels et leurs versions, licences et dépendances respectives dans des feuilles de calcul. Il n’est adapté qu’aux déploiements à petite échelle et est sujet à l’erreur humaine.
Le Méthode automatique implique l’intégration d’outils SBOM dans le pipeline d’intégration continue/déploiement continu (CI/CD).
Après 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’entre eux.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
Pour vous donner une meilleure compréhension des formats SBOM, considérez cet exemple de l’inventaire CycloneDX au format JSON :
{
"bomFormat (format de nomen)": "CycloneDX",
"specVersion (en anglais)": "1.4",
"numéro de série": "urn :uuid :3e673487-395b-41h8-a30f-a58468a69b79",
"Version": 1,
"Composants": [
{
"type": "bibliothèque",
"nom": "Bibliothèque NACL",
"Version": "1.0.0"
}
]
}En plus des deux formats décrits ci-dessus, les organisations peuvent également utiliser des balises d’identification logicielle (SWID), qui sont généralement installées pendant le déploiement. Les balises SWID fournissent des informations SBOM telles que les dates de publication des composants logiciels et les licences. Les organismes de réglementation et le gouvernement américain considèrent que les balises SWID, CycloneDX et SPDX sont acceptables Formats SBOM.
Mise en œuvre du SBOM : un guide étape par étape
La création d’un SBOM peut sembler intimidante, mais le diviser en étapes gérables peut faciliter le processus. Voici comment commencer :
| Step | Process |
|---|---|
| 1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
| 2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
| 3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
| 4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
En savoir plus
Wiz'à l’égard de la sécurité des 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 s’assure que les vulnérabilités au sein des bibliothèques tierces et des composants open source sont identifiées et atténuées rapidement.
Voici quelques-uns des avantages du déploiement SBOM sans agent :
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 s’ajoute à une surcharge de maintenance exorbitante. SBOM sans agent Le déploiement réduit également les coûts et élimine les problèmes de compatibilité agent-système d’exploitation.
Visibilité instantanée et complète : Des agents doivent être installés sur chaque sous-système de la pile logicielle. Un SBOM sans agent vous offre une vue complète 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 spécifiques et des packages open source dans les environnements cloud. Cette capacité est particulièrement opportune compte tenu des récentes vulnérabilités critiques trouvées dans des bibliothèques largement utilisées telles que xz-utils.
Toujours à jour : Les agents nécessitent une installation manuelle, ce qui peut être sujet aux erreurs, tandis qu’un Approche sans agent vous permet de générer des SBOM à jour sans intervention manuelle.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
