Le SBOM en un paragraphe
Un Software Bill of Materials (SBOM) est un inventaire de chaque composant tiers dont dépend un logiciel — nom, version, et un identifiant assez précis pour qu'une équipe procurement ou sécurité puisse le rechercher. CycloneDX est l'un des deux standards SBOM dominants (l'autre étant SPDX), maintenu par l'OWASP, actuellement en version de spécification 1.5. Contrairement à un rapport SARIF, un SBOM ne décrit pas des vulnérabilités — il décrit de quoi votre logiciel est fait. Les deux sont complémentaires : SARIF répond à « qu'avez-vous trouvé », un SBOM répond à « de quoi dépendez-vous ».
Générer le SBOM
Un seul flag, même CLI que le reste :
./staticcodeaudit-linux-x86_64 /path/to/project --sbomCela écrit SCA-SBOM-<timestamp>.json à côté du rapport HTML habituel. Le scanner détecte automatiquement les fichiers manifestes de dépendances dans la racine du projet et les chemins inclus — aucune configuration supplémentaire nécessaire.
Fichiers manifestes lus
Six formats de manifeste de dépendances sont parsés directement, couvrant les langages que ce scanner audite pour les vulnérabilités :
| Manifest | Ecosystem |
|---|---|
requirements.txt / pyproject.toml |
PyPI (Python) |
package.json |
npm (JavaScript/TypeScript) |
pom.xml |
Maven (Java) |
build.gradle |
Gradle (Java) |
*.csproj |
NuGet (C#) |
composer.json |
Packagist (PHP) |
Chaque manifeste est lu une seule fois par scan (racine du projet plus chemins inclus configurés, dédupliqué par chemin normalisé) — un projet avec à la fois requirements.txt et package.json obtient des composants des deux dans le même SBOM.
Ce que contient réellement le fichier
Un exemple réel — deux dépendances épinglées dans un requirements.txt :
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"metadata": {
"timestamp": "2026-08-07T18:30:12.104Z",
"tools": [{ "name": "StaticCodeAudit", "version": "1.0.0" }],
"component": {
"type": "application",
"name": "your-project",
"version": "1.0.0"
}
},
"components": [
{
"type": "library",
"name": "requests",
"version": "2.31.0",
"purl": "pkg:pypi/requests@2.31.0"
},
{
"type": "library",
"name": "flask",
"version": "3.0.0",
"purl": "pkg:pypi/flask@3.0.0"
}
]
}Chaque composant porte un Package URL (purl) — un identifiant standardisé (pkg:pypi/requests@2.31.0) que les outils procurement et bases de vulnérabilités peuvent faire correspondre sans ambiguïté. L'export liste nom, version et purl ; il ne calcule ni n'intègre de hash de fichier par dépendance.
SBOM ou SARIF — jamais les deux dans le même run
Les exports SBOM et SARIF sont mutuellement exclusifs par invocation — ils servent des consommateurs différents (procurement/inventaire vs. triage de vulnérabilités) et les combiner rendrait les deux plus difficiles à parser correctement en aval :
$ ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --sbom
❌ --sarif and --sbom are mutually exclusive. Use one or the other.Lancez le scan deux fois en CI si un pipeline a besoin des deux artefacts sur le même commit — chaque run prend nettement moins d'une seconde sur une base de code petite à moyenne. Voir le guide export SARIF pour le volet vulnérabilités.
Où cela se situe pour les entités réglementées
Pour les organisations dans le périmètre de la directive européenne NIS2, l'article 21(2)(d) exige des « mesures » couvrant la sécurité de la chaîne d'approvisionnement. Un SBOM CycloneDX — combiné aux findings de vulnérabilités SARIF sur le même code — est le type de preuve concrète et exploitable par machine qu'un auditeur ou un relecteur procurement peut utiliser : exactement quelles dépendances sont dans une release donnée, à quelle version, recoupées avec les vulnérabilités connues. Plus de détail sur la page secteurs réglementés.
Questions fréquentes
Générer un SBOM envoie-t-il ma liste de dépendances quelque part ?
Non. Le SBOM est construit entièrement à partir de fichiers locaux (votre requirements.txt, package.json, etc.) et écrit sur disque local. StaticCodeAudit n'effectue aucun appel réseau sortant pendant un scan — générer un SBOM ne change rien à cela, aucune recherche dans une base externe n'étant impliquée.
Le SBOM inclut-il les vulnérabilités connues de chaque dépendance ?
Non — c'est le rôle du flag --with-deps et de l'export SARIF. Le SBOM en lui-même est un inventaire pur (tableau components de CycloneDX) : nom, version, purl. Recouper les composants avec des bases de vulnérabilités est une étape séparée, généralement effectuée par le système qui consomme le SBOM en aval.
Que se passe-t-il si mon projet n'a aucun manifeste de dépendances reconnu ?
Le SBOM est quand même généré, avec un tableau components vide — un CycloneDX 1.5 valide, décrivant simplement une application sans dépendances tierces déclarées. Attendu par exemple pour un projet pur HTML ou infra-as-code sans équivalent requirements.txt/package.json.
Puis-je obtenir un SBOM pour un monorepo avec plusieurs manifestes ?
Oui — le scanner parcourt la racine du projet plus chaque chemin listé sous include dans audit.config.json, et fusionne les composants de chaque manifeste trouvé (par exemple un package.json racine et un backend/requirements.txt imbriqué dans le même repo contribuent tous deux à un seul SBOM).
Voir un SBOM complet sur du vrai code
Ouvrez le rapport de démonstration en ligne — sans installation, sans inscription — ou lancez le binaire sur votre propre projet et inspectez directement le SBOM généré.
Ouvrir le rapport en ligne Télécharger le binaire de démo