SBOM pour les achats de défense : transparence de la chaîne d'approvisionnement logicielle

La nomenclature logicielle (SBOM, Software Bill of Materials) — un document d'inventaire formel répertoriant chaque composant, bibliothèque et dépendance dans un produit logiciel — s'est rapidement transformée d'une pratique DevOps technique en une exigence réglementaire pour les achats de défense. L'Executive Order américain 14028 "Improving the Nation's Cybersecurity" (2021) exige des fournisseurs de logiciels vendant aux agences fédérales de fournir des SBOM. Le Cyber Resilience Act (CRA) de l'UE, entré en vigueur en 2024, introduit des exigences obligatoires de sécurité et de SBOM pour les produits avec des éléments numériques vendus sur le marché de l'UE.

Pour les contractants de défense, les deux exigences réglementaires convergent : les programmes de défense sont des systèmes critiques soumis aux régimes de conformité les plus stricts, et le SBOM devient un artefact contractuel standard aux côtés de la documentation de sécurité du système et des rapports de test. Dans le contexte de la DGA (Direction Générale de l'Armement), la sécurité de la chaîne d'approvisionnement logicielle est de plus en plus intégrée dans les exigences de marchés informatiques de défense.

Formats SBOM : SPDX et CycloneDX

SPDX (Software Package Data Exchange) est un standard ISO (ISO/IEC 5962:2021) pour les SBOM, développé par la communauté Linux Foundation. SPDX définit un schéma pour décrire les paquets logiciels, leurs dépendances et les informations de licence. Les documents SPDX peuvent être exprimés dans plusieurs formats : tag-value (format texte lisible par l'homme), JSON, RDF et YAML.

CycloneDX est un standard OWASP pour les spécifications BOM (Bill of Materials), développé avec un focus direct sur les applications de sécurité. CycloneDX prend en charge non seulement les SBOM, mais aussi les HBOM (matériel), MBOM (apprentissage machine) et CBOM (cryptographie) — ce qui le rend particulièrement pertinent pour les systèmes de défense où la transparence du matériel et de la cryptographie est importante. CycloneDX inclut l'extension VEX (Vulnerability Exploitability eXchange) qui permet aux fournisseurs de communiquer si des vulnérabilités connues spécifiques sont réellement exploitables dans leur produit.

Génération de SBOM : Syft et cdxgen

Syft d'Anchore est l'outil open source de référence pour la génération de SBOM. Il prend en charge un large éventail d'écosystèmes de paquets (Alpine, DEB, RPM, Maven, npm, PyPI, modules Go, NuGet et autres) et peut analyser des répertoires de système de fichiers, des images de conteneurs et des artefacts OCI. Syft génère des SBOM aux formats SPDX et CycloneDX, offrant une flexibilité pour satisfaire les diverses exigences des auditeurs et clients.

Pour les pipelines CI/CD, Syft peut être intégré comme étape post-build : après la construction réussie d'une image de conteneur, Syft génère un SBOM pour cette image, qui est ensuite signé (avec Cosign) et publié aux côtés de l'image dans le registre de conteneurs.

cdxgen (CycloneDX Generator) est un générateur alternatif optimisé pour CycloneDX, avec un support particulièrement fort pour les projets Java/Kotlin (Maven/Gradle), JavaScript/TypeScript (npm/yarn) et Python (pip/poetry). cdxgen analyse les fichiers manifestes de paquets et les fichiers lock pour déterminer les dépendances transitives — pas seulement les dépendances directes, mais les dépendances de leurs dépendances sur toute la profondeur de l'arbre de dépendances.

VEX : communication sur l'exploitabilité des vulnérabilités

Le SBOM identifie les composants ; le SBOM combiné avec NVD ou d'autres bases de données de vulnérabilités identifie quels CVE connus affectent ces composants. Mais la présence d'un CVE dans un composant ne signifie pas automatiquement que le logiciel déployé est vulnérable : le chemin de code vulnérable peut être inaccessible ; la configuration d'atténuation peut rendre la vulnérabilité inexploitable ; le fournisseur peut avoir déjà intégré un correctif sans mettre à jour la version du paquet.

VEX (Vulnerability Exploitability eXchange) résout ce problème en fournissant aux fournisseurs un mécanisme pour communiquer le statut d'exploitabilité des vulnérabilités dans leurs produits spécifiques. Un document VEX peut affirmer qu'un CVE spécifique est : "Non affecté" — la fonction vulnérable n'est pas présente ou utilisée ; "Affecté" — la vulnérabilité est réellement exploitable avec des actions recommandées ; "En cours de correction" — le fournisseur a reconnu la vulnérabilité et planifie un correctif ; "Corrigé" — la vulnérabilité a été corrigée avec des détails sur la version spécifique.

Exigences SBOM dans les achats de défense

Pour les contractants de défense vendant ou prévoyant de vendre des logiciels à des clients de défense de l'UE et des États-Unis, la conformité SBOM devient une exigence contractuelle. Les exigences pratiques comprennent : la présence d'un document SBOM dans un format standard lisible par machine (SPDX ou CycloneDX) couvrant toutes les dépendances y compris transitives ; le SBOM doit être signé pour la vérification de l'intégrité ; le SBOM doit être mis à jour à chaque version ; les vulnérabilités doivent être divulguées avec des affirmations VEX appropriées et des calendriers de remédiation.

Intégration du SBOM dans la gestion des vulnérabilités

Le SBOM est le plus précieux en combinaison avec une gestion continue des vulnérabilités. Le processus automatisé ressemble à ceci : lorsqu'un nouveau CVE est publié, le SBOM est automatiquement interrogé pour déterminer si le paquet affecté impacte un produit déployé ; si oui, un incident de gestion des vulnérabilités est ouvert automatiquement avec des preuves du produit, de la version et des déploiements affectés ; les affirmations VEX sont mises à jour au fur et à mesure que l'investigation progresse ; les enregistrements de correctifs sont documentés par rapport au CVE dans l'état VEX final.