D’ou sa vient ?

Comme son nom le sous-entend, SBOM vient de BOM ou Bill of Materials. C’est une liste de tout ce qui compose un produit et comment le produit a été construit. En gros, un SBOM c’est la liste de tous les composants d’un logiciel qui lui permettent de fonctionner (libraries, packages, drivers). Pour rentrer plus dans le détail, c’est en réalité un format d’échange de données, ce n’est pas destiné à être lu par un humain. Il existe plusieurs formats de SBOM, les plus utilisés sont SPDX (Linux Foundation) et CycloneDX (OWASP).

Pourquoi faire ?

Tout d’abord cela peut permettre de visualiser les dépendances de son logiciel et possiblement faire le tri. Cela permet aussi de tracker les potentiels vulnérabilités d’un système. En Europe, cela va devenir une obligation en décembre 2027 d’être en mesure de fournir un SBOM pour tout logiciel vendu dans l’Union européenne. Plus d’info ici SBOM-europe, Cyber Resilience Act

Comment ?

Je vais utiliser Trivy pour générer un SBOM et scanner une image PostgreSQL 17.4.

Générer un SBOM.

Ici, nous générons un SBOM au format CycloneDX et nous générons également un Vulnerability Exploitability eXchange (VEX) grâce au paramètre --scanners.

trivy image --scanners vuln --format cyclonedx --output result.json postgres:17.4

Nous nous retrouvons donc avec un JSON de 29 000 lignes, ce qui n’est pas très pratique.

Pour rendre notre SBOM lisible par un humain, nous pouvons utiliser Sunshine, un outil qui permet de visualiser les SBOM au format CycloneDX. Sunshine va générer un fichier HTML contenant un diagramme de dépendance ainsi qu’un tableau listant tous les composants de notre logiciel.

Comme nous avons également créé un VEX, Sunshine nous affiche également les vulnérabilités de chaque composant.

python3 sunshine.py -i result.json -o sbom.html

Exemple du diagrame générer.

Exemple du tableau générer.