Qu'est-ce qu'un SBOM et pourquoi est-il important ?

Un Software Bill of Materials (SBOM) est au logiciel ce qu'une liste d'ingrédients est à l'alimentation : une liste complète et lisible par machine de ce qu'il contient.

Ce qu'il contient

Un SBOM énumère chaque composant qui constitue une application — dépendances directes et transitives, leurs versions, fournisseurs, et idéalement les empreintes cryptographiques et données de licence. Il capture aussi les relations, vous pouvez donc voir quel composant dépend de quel autre. Comme il s'agit de données structurées, les outils peuvent le consommer automatiquement plutôt qu'un humain lisant une liste.

Pourquoi c'est important

Le cas d'usage phare est la rapidité de réponse aux incidents. Lorsque Log4Shell a été divulgué, les organisations ont passé des jours ou des semaines juste à déterminer si elles utilisaient Log4j vulnérable et où. Avec des SBOM archivés pour chaque build, cela devient une requête : « montre-moi chaque artefact contenant log4j-core < 2.17 ». Au-delà des incidents, les SBOM soutiennent la conformité des licences, l'évaluation des risques fournisseurs et — de plus en plus — les exigences réglementaires et d'achat (par ex. le décret américain Executive Order 14028 a imposé les SBOM dans les chaînes d'approvisionnement logicielles fédérales).

Les deux standards

• SPDX — un standard ISO/IEC initialement axé sur la conformité des licences, désormais large.
• CycloneDX — un projet OWASP conçu avec la sécurité d'abord, avec un fort support des vulnérabilités (VEX) et des relations de dépendances.

La plupart des outils peuvent émettre les deux. Générez le SBOM pendant le build, pas après, pour qu'il reflète exactement ce qui a été livré, et stockez-le comme un artefact versionné aux côtés du binaire.

Ce que recherchent les recruteurs

Ils veulent le cadrage réponse aux incidents, la connaissance de SPDX vs CycloneDX, et la compréhension qu'un SBOM n'est utile que s'il est généré au moment du build et réellement stocké et interrogeable.