Générer un SBOM pour votre propre code est un problème réglé : un outil dans le pipeline et c'est fait. Le vrai défi, c'est le logiciel que vous achetez. L'essentiel de votre surface d'attaque provient de vos fournisseurs, et quand la prochaine Log4Shell tombera, « nous avons écrit à nos fournisseurs et attendons leur réponse » ne constitue pas un plan de réponse à incident. Un programme SBOM couvrant la chaîne d'approvisionnement logicielle doit inclure le code que vous ne contrôlez pas : il faut donc obtenir des SBOM de vos fournisseurs logiciels tiers, systématiquement, dans un format exploitable. Voici comment.
Pourquoi exiger des SBOM de vos fournisseurs, maintenant
Deux forces rendent la démarche urgente. La première : le mode d'attaque lui-même. SolarWinds, 3CX et XZ Utils ont démontré qu'un seul composant compromis dans un produit de confiance peut atteindre des milliers d'organisations en aval. Quand la compromission se loge chez le fournisseur, vos scanneurs ne voient rien : seul le SBOM vous dit ce qui tourne réellement dans le logiciel acheté.
La seconde force, c'est la réglementation, et elle converge rapidement :
- Le Cyber Resilience Act européen oblige les fabricants de produits numériques à maintenir un SBOM : vos fournisseurs vendant en Europe devront en produire un de toute façon ; autant le recevoir.
- NIS2 fait de la sécurité de la chaîne d'approvisionnement une obligation explicite pour les entités essentielles et importantes, incluant l'évaluation des pratiques de leurs fournisseurs directs.
- DORA impose aux entités financières de gérer le risque lié aux tiers TIC avec des preuves concrètes, pas seulement des promesses contractuelles.
- Les approvisionnements fédéraux américains, dans la foulée de l'Executive Order 14028, ont intégré le SBOM aux exigences d'achat : vos fournisseurs sérieux ont donc déjà des clients qui le demandent.
En résumé : vos fournisseurs se font demander des SBOM par les régulateurs et par leurs plus gros clients. La demande n'a plus rien d'exotique. C'est de ne pas demander qui détonne.
Quoi demander exactement
Un vague « merci de nous fournir un SBOM » vous vaudra une réponse tout aussi vague. Soyez précis :
- Un format lisible par machine : SPDX ou CycloneDX, en JSON. Pas un PDF, pas un chiffrier, pas un export propriétaire. Ce que vous ne pouvez pas analyser automatiquement ne sert à rien à l'échelle.
- Un SBOM par version, livré avec chaque version déployée, et non un instantané unique : un SBOM périmé donne une fausse impression de couverture.
- Un SBOM de déploiement, pas seulement un SBOM de code source. Le SBOM source décrit ce que les développeurs ont déclaré ; celui de déploiement reflète ce qui vous est réellement livré : l'image de base du conteneur, le runtime embarqué, les dépendances empaquetées. L'écart entre les deux est exactement là où se cachent les mauvaises surprises.
- La profondeur des dépendances : les dépendances transitives incluses, pas seulement les paquets de premier niveau. Log4j était rarement une dépendance directe ; elle était enfouie trois niveaux plus bas.
- Des déclarations VEX (Vulnerability Exploitability eXchange) accompagnant le SBOM. Le SBOM vous dit qu'un composant vulnérable est présent ; le VEX vous dit si le fournisseur considère la CVE réellement exploitable dans son produit. Sans VEX, vous allez noyer votre fournisseur (et vous-même) sous les faux positifs.
Comment le demander
Le canal compte autant que le contenu.
Inscrivez-le au contrat. Les nouvelles ententes et les renouvellements sont votre levier. Une clause efficace exige la livraison d'un SBOM lisible par machine (SPDX ou CycloneDX) à chaque version, couvrant les dépendances transitives, accompagné de déclarations VEX pour les vulnérabilités divulguées, dans un délai défini. Une exigence qui ne vit que dans un fil de courriels est une faveur, pas une obligation.
Inscrivez-le au questionnaire de sécurité. Ajoutez des questions directes : produisez-vous des SBOM, dans quel format, à chaque version ou sur demande, fournissez-vous des VEX, et pouvez-vous partager un exemple. La question de l'exemple est la plus utile : elle distingue les fournisseurs qui le font de ceux qui prévoient le faire.
Inscrivez-le à la liste de contrôle d'intégration. La livraison d'un SBOM devrait être un critère d'intégration pour tout logiciel touchant la production ou des données sensibles, au même titre que les certifications. Cela relève de la gestion des risques liés aux tiers, pas d'un projet parallèle de l'équipe de sécurité.
Ajustez pour les petits fournisseurs. Une PME logicielle n'a peut-être pas de processus mature, mais générer un SBOM coûte peu : des outils open source comme Syft ou Trivy produisent un fichier CycloneDX en quelques minutes. Demande raisonnable : un SBOM par version généré dans le CI, même sans VEX au départ, avec une date d'engagement pour le reste. Acceptez l'imparfait mais honnête ; n'acceptez pas le vide.
Quoi faire quand vous en recevez un
Un SBOM classé dans SharePoint, c'est de la décoration. Pour en tirer de la valeur :
- Ingérez-le dans un inventaire central, versionné par fournisseur et par version, pour répondre en quelques secondes à « quels fournisseurs livrent le composant X ».
- Croisez les composants avec les vulnérabilités activement exploitées, en commençant par le catalogue KEV de la CISA. Une CVE, c'est un constat ; une CVE inscrite au KEV, c'est une conversation prioritaire avec le fournisseur cette semaine.
- Suivez la dérive entre les versions. Comparer deux SBOM consécutifs révèle les nouvelles dépendances, celles abandonnées qui traînent encore et les composants jamais mis à jour. Un SBOM qui ne change jamais d'une version à l'autre en dit long sur la discipline de correctifs du fournisseur.
Si vous bâtissez aussi ce pipeline pour vos propres logiciels, notre guide sur la gestion de votre chaîne d'approvisionnement logicielle couvre le volet interne : formats, génération et connexion des SBOM à votre veille CVE.
Les signaux d'alarme
- Des SBOM en PDF seulement : produits pour les auditeurs, pas pour les machines, et probablement à la main.
- Des instantanés uniques. Un SBOM daté d'il y a dix-huit mois décrit un produit que vous n'exécutez plus.
- Un refus au nom de la « propriété intellectuelle ». Un SBOM liste surtout des composants open source ; il révèle peu de choses qu'un attaquant déterminé ne pourrait découvrir. Traitez un refus catégorique comme un signal sur la posture du fournisseur.
- Aucun responsable désigné. Si personne chez le fournisseur ne sait qui produit le SBOM, personne ne le produit.
Gérer les objections réalistes
Attendez-vous à trois objections. « Cela expose notre propriété intellectuelle » : proposez de le recevoir sous entente de confidentialité et rappelez que la liste est très majoritairement open source. « Nous n'avons pas l'outillage » : l'outillage est gratuit et l'intégration au CI se fait en une journée ; demandez une date d'engagement plutôt qu'un haussement d'épaules. « Le partager est un risque de sécurité » : les attaquants n'ont pas besoin de votre SBOM pour vous exploiter, mais vous en avez besoin pour vous défendre ; cet argument trahit surtout un fournisseur qui craint ce que vous trouverez dans sa propre liste de composants.
Quand un fournisseur stratégique résiste encore, utilisez le cycle de renouvellement. Les exigences attachées à l'argent avancent plus vite que celles attachées à la bonne volonté.
Intégrez-le à une surveillance continue de vos fournisseurs
La demande de SBOM est un contrôle parmi d'autres dans le cycle de vie fournisseur : inventaire, priorisation, évaluation fondée sur des preuves et surveillance continue. Le module TPRM de FortaRisks garde ce cycle vivant en observant vos fournisseurs en continu plutôt qu'une fois par année. Pour commencer dès aujourd'hui, notre questionnaire de sécurité fournisseur gratuit inclut déjà des questions sur le SBOM et la chaîne d'approvisionnement, prêtes à envoyer telles quelles. Le premier SBOM fournisseur est le plus difficile à obtenir ; ensuite, ce n'est plus qu'un processus.