Les SBOM comme preuves de conformité : ISO 27001, SOC 2 et NIS2

Une preuve n'est pas la conformité

Une mesure est satisfaite par un processus qui fonctionne. La preuve montre qu'il fonctionne. Une SBOM montre une chose précise : ce que contenait une release donnée. Elle ne dit rien du contrôle d'accès, de la réponse aux incidents, ni de la question de savoir si quelqu'un a donné suite à un résultat.

Elle peut aussi être fausse sans que personne ne s'en aperçoive. Un générateur qui a lu les mauvais fichiers produit une SBOM valide qui manque la moitié du produit. Le scan de vulnérabilités de cette SBOM est propre, la plateforme de conformité voit qu'un scan a eu lieu, et tous les contrôles sont au vert. Ce que vérifie un contrôle SBOM SOC 2 au vert détaille cet échec.

Une preuve issue d'une SBOM compte lorsqu'elle est :

1. Rattachée à une release. Une SBOM par version livrée, pas une pour le dépôt.
2. Complète, ou explicite sur ce qu'elle a manqué. Une SBOM qui déclare ses lacunes est fiable pour ce qu'elle liste.
3. Conservée pendant la période couverte par l'audit. Un auditeur qui échantillonne le mois de mars dernier a besoin de la SBOM de mars dernier.
4. Réévaluée lorsque de nouvelles vulnérabilités apparaissent. Une liste que personne ne compare aux nouveaux avis de sécurité prouve peu de chose sur la gestion des vulnérabilités.

Pour savoir ce que contient une SBOM, voir qu'est-ce qu'une SBOM. Pour les référentiels de développement sécurisé des produits industriels et des logiciels fédéraux américains, voir IEC 62443-4-1 et NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 est la norme selon laquelle un système de management de la sécurité de l'information est certifié (glossaire). L'annexe A liste 93 mesures ; une organisation retient celles que son appréciation des risques impose et les consigne dans sa déclaration d'applicabilité (Statement of Applicability). ISO/IEC 27002:2022 donne les recommandations de mise en œuvre. Aucune des deux ne cite les SBOM. Le tableau ne cite que les titres des mesures, dans leur version anglaise, et résume l'objet de chacune.

Mesure	Son objet	En quoi une SBOM ou un enregistrement de build sert de preuve	Ce qu'elle ne couvre pas
5.9 "Inventory of information and other associated assets"	Savoir quels actifs vous possédez et qui en est propriétaire	Le logiciel que vous livrez et exploitez est un actif. Une liste de composants par release est l'inventaire de son contenu.	Le matériel, les données, les personnes et les services
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Gérer le risque lié aux fournisseurs et à la chaîne d'approvisionnement TIC	Dans les deux sens. En tant qu'acheteur, vous pouvez exiger des SBOM de vos fournisseurs et les surveiller. En tant que fournisseur, votre SBOM est ce que vous demande le processus chaîne d'approvisionnement de votre client certifié. Les composants open source font partie de la chaîne d'approvisionnement TIC mais ne s'accompagnent d'aucun accord fournisseur : c'est précisément pour cela que leur inventaire compte.	Les contrats, les évaluations et les revues de fournisseurs
8.8 "Management of technical vulnerabilities"	Obtenir des informations sur les vulnérabilités, évaluer votre exposition et agir	Une liste de composants à jour, rapprochée des avis de sécurité et réévaluée lorsque de nouveaux avis paraissent, ainsi qu'un enregistrement des releases qui contenaient une version vulnérable, et depuis quand	Le patch de votre infrastructure, le scan des hôtes, et les décisions elles-mêmes
8.25 "Secure development life cycle"	Les règles de développement sécurisé des logiciels et des systèmes	Un processus de release enregistré et reproductible : chaque release construite dans le même pipeline, avec sa SBOM	L'essentiel de la mesure : formation, environnements, conception et revue
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Exigences, conception et code	Pas directement. Ces mesures portent sur ce que vous écrivez, pas sur ce que vous intégrez.	Tout : la revue de code, le SAST et les dossiers de conception sont ici les preuves
8.29 "Security testing in development and acceptance"	Tester la sécurité avant la release	Une policy gate qui bloque un build sur un résultat de vulnérabilité est un test enregistré, avec son résultat	Les tests de sécurité fonctionnels, les tests d'intrusion
8.30 "Outsourced development"	Encadrer et surveiller le développement que vous externalisez	Le code externalisé construit dans votre pipeline reçoit la même SBOM et les mêmes contrôles que le vôtre	Le contrat, les pratiques propres au prestataire

Soyez honnête sur 8.25 à 8.30 : l'essentiel de ce que demandent ces mesures sort du champ d'une SBOM. En revendiquer davantage est le moyen le plus rapide de perdre la confiance d'un auditeur sur tout le reste.

Exemple concret : un auditeur pose une question sur 8.8

« Comment savez-vous qu'une nouvelle vulnérabilité touche un produit que vous avez déjà livré ? » Voici la chaîne de preuves pour un avis de sécurité, et qui fournit chaque maillon.

Étape	Preuve	Provenance
1. Le contenu de la release	La SBOM de la version 4.2, enregistrée par le build qui l'a produite	Votre outillage de build
2. La correspondance avec l'avis	Une nouvelle CVE publiée pour une bibliothèque de cette SBOM, rapprochée par sa package URL	Votre surveillance des vulnérabilités
3. La fenêtre d'exposition	Chaque build qui contenait la version vulnérable, et la date du premier	Votre historique de builds
4. La décision	Qui l'a évaluée, quand, et avec quelle issue : corriger, atténuer ou non concerné, avec la raison	Votre processus et ses enregistrements
5. La correction	La version 4.2.1, dont la SBOM ne contient plus la version vulnérable	Votre outillage de build

Des outils peuvent fournir les étapes 1, 2, 3 et 5. L'étape 4 relève de votre processus, et c'est celle que les auditeurs examinent de plus près.

SOC 2

Un rapport SOC 2 indique si des contrôles satisfont aux Trust Services Criteria de l'AICPA (2017, avec des points d'attention révisés en 2022). Les critères décrivent des résultats attendus. Ils ne citent pas les SBOM, et deux d'entre eux sont ceux où les SBOM aident.

• CC7.1 demande que l'entité utilise des procédures de détection et de surveillance pour identifier (1) les modifications de configuration qui introduisent de nouvelles vulnérabilités et (2) l'exposition à des vulnérabilités nouvellement découvertes. Preuves : une SBOM par release, réévaluée par rapport aux nouveaux avis de sécurité, et un enregistrement de la façon dont chaque résultat a été traité.
• CC8.1 couvre la gestion des changements : comment les modifications de l'infrastructure, des données, des logiciels et des procédures sont autorisées, développées ou acquises, testées, approuvées et mises en œuvre. Preuves : chaque release construite dans un pipeline enregistré, l'évolution de ses dépendances visible d'un build à l'autre, et des policy gates comme contrôle de ce qui peut être livré.

Les critères sont en cours de révision. En octobre 2026, l'AICPA a publié un projet (exposure draft) des Trust Services Criteria 2027, avec une restructuration ciblée des critères, des commentaires attendus d'ici le 15 janvier 2027 et une date d'entrée en vigueur proposée pour les missions commençant le 31 décembre 2027 ou après. Il s'agit d'un projet, et les numéros des critères peuvent changer : vérifiez le texte définitif avant de relier vos preuves aux nouveaux numéros.

Si vous utilisez déjà une plateforme SOC 2, gardez-la. La question est ce que montre la SBOM derrière ses contrôles : les contrôles SBOM SOC 2 comparés.

NIS2

La directive (UE) 2022/2555 (directive SRI 2) s'applique aux entités essentielles et importantes des secteurs qu'elle liste. Si vous lisez ceci en tant que fournisseur de logiciels ou d'appareils, vous n'êtes généralement pas vous-même dans son champ. Votre client l'est, et ses obligations vous parviennent sous forme de questions. L'article 21 fixe les mesures de gestion des risques en matière de cybersécurité, et trois passages sont à l'origine de la plupart de ces questions :

• Article 21, paragraphe 2, point d) : « la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs ».
• Article 21, paragraphe 2, point e) : « la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités ».
• Article 21, paragraphe 3 : les entités tiennent compte « des vulnérabilités propres à chaque fournisseur et prestataire de services direct et de la qualité globale des produits et des pratiques de cybersécurité de leurs fournisseurs et prestataires de services, y compris de leurs procédures de développement sécurisé ». C'est la phrase qui se transforme en questionnaire sur votre bureau.

Règlement d'exécution (UE) 2024/2690

Le règlement d'exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 établit les exigences techniques et méthodologiques des mesures de l'article 21, paragraphe 2, pour les fournisseurs de services DNS, les registres des noms de domaine de premier niveau, les fournisseurs de services d'informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de réseaux de diffusion de contenu, les fournisseurs de services gérés, les fournisseurs de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche en ligne, les plateformes de services de réseaux sociaux et les prestataires de services de confiance. Il ne lie pas les autres secteurs de NIS2, mais c'est la définition publique la plus détaillée de ce que signifie « sécurité de la chaîne d'approvisionnement », et d'autres acheteurs s'en inspirent. Les points qui concernent les fournisseurs :

Point de l'annexe	Ce qu'il dit	Ce qu'on demande au fournisseur
5.1.2, point a)	Les critères de sélection des fournisseurs incluent « les pratiques des fournisseurs et des prestataires de services en matière de cybersécurité, y compris leurs procédures de développement sécurisé »	Comment développez-vous de façon sécurisée, et comment savez-vous ce qui entre dans votre produit ?
5.1.4, points e) et f)	Les contrats précisent, s'il est besoin, le droit d'effectuer des audits ou de recevoir des rapports d'audit, et « l'obligation pour les fournisseurs et les prestataires de services de gérer les vulnérabilités qui présentent un risque » pour l'entité	Allez-vous gérer les vulnérabilités de ce que vous livrez, et pouvons-nous en voir les preuves ?
5.2	Un registre des fournisseurs directs, avec « une liste des produits TIC, services TIC et processus TIC » que chacun fournit	Quels produits et quelles versions nous fournissez-vous ?
6.1.2, point c)	Pour l'acquisition de services TIC ou de produits TIC : « les informations décrivant les composants matériels et logiciels utilisés dans les services TIC ou les produits TIC »	Quels composants matériels et logiciels votre produit contient-il ? Le texte de cette page qui se rapproche le plus d'une SBOM, sans pour autant en nommer une.
6.10	Traitement des vulnérabilités : surveiller les informations sur les vulnérabilités par des canaux tels que les annonces des CSIRT ou « les informations fournies par les fournisseurs ou les prestataires de services » (6.10.2, point a)), et lorsqu'une vulnérabilité ne nécessite pas de remédiation, documenter et justifier « la raison pour laquelle il n'est pas nécessaire de remédier à la vulnérabilité » (6.10.3)	Comment allez-vous nous informer des vulnérabilités, et pourquoi celle-ci n'est-elle pas un problème ?

Le dernier point décrit une déclaration de non-impact avec sa justification. C'est ce que porte un document VEX, même si le règlement ne nomme aucun format.

Exemple concret : le questionnaire d'un client soumis à NIS2

Cinq questions du type de celles qu'un client tire de ces points, avec les preuves qu'un fournisseur peut joindre. Certaines réponses proviennent d'enregistrements que conserve votre outillage ; d'autres sont des politiques que vous rédigez.

Question	Preuve à joindre	Enregistrement ou politique
« Listez les composants logiciels de la version du produit que vous nous livrez. » (6.1.2, point c))	La SBOM de cette version, en CycloneDX ou SPDX, avec sa complétude indiquée	Enregistrement
« Décrivez votre traitement des vulnérabilités et ses délais. » (5.1.4, point f))	Votre procédure de traitement des vulnérabilités, avec niveaux de sévérité et délais cibles	Politique
« Lesquelles des versions que nous utilisons contenaient la bibliothèque vulnérable, et depuis quand ? » (6.10)	L'historique des builds, montrant chaque build qui contenait le composant, avec les dates	Enregistrement
« Pourquoi cette CVE ne nous concerne-t-elle pas ? » (6.10)	Une déclaration de non-impact avec sa justification, par exemple « le code vulnérable n'est pas présent »	Enregistrement, fondé sur votre évaluation
« Comment les chercheurs peuvent-ils signaler des vulnérabilités dans vos produits ? » (5.1.2, point a))	Votre politique de divulgation coordonnée des vulnérabilités	Politique

Une distinction à garder en tête : pour les produits comportant des éléments numériques vendus dans l'UE, le Cyber Resilience Act (règlement sur la cyberrésilience) exige bien une SBOM. NIS2, non.

DORA, si vous vendez à des entités financières

Le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique (DORA) s'applique aux entités financières, pas directement à leurs fournisseurs. Les entités financières doivent identifier et documenter leurs actifs TIC et leurs interdépendances et en tenir des inventaires (article 8, paragraphes 1, 4 et 6), gérer le risque lié aux prestataires tiers de services TIC dans le cadre de leur risque lié aux TIC (article 28, paragraphe 1), tenir un registre d'informations sur tous leurs contrats de services TIC (article 28, paragraphe 3) et inclure des dispositions minimales dans ces contrats (article 30). DORA ne cite pas les SBOM. Pour un fournisseur de logiciels d'une banque, une liste de composants par release aide le client à satisfaire à l'article 8.

Une seule carte des preuves pour tous

Les lignes sont des preuves ; chaque cellule indique la mesure, le critère ou le point qu'elle étaye, ou « pas directement ».

Preuve	ISO/IEC 27001:2022	SOC 2	NIS2 et 2024/2690	DORA
1. Une SBOM par release, avec sa complétude indiquée	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d) ; 6.1.2(c)	Art. 8 (l'inventaire du client)
2. Réévaluation continue par rapport aux nouveaux avis de sécurité	8.8	CC7.1	Art. 21(2)(e) ; 6.10	Pas directement
3. Historique des builds : quelles releases contenaient un composant, et depuis quand	8.8	CC7.1, CC8.1	6.10	Pas directement
4. Enregistrements de tri et d'affectation	8.8	CC7.1	Art. 21(2)(e) ; 6.10	Pas directement
5. Déclarations de non-impact avec justification	8.8	CC7.1	6.10	Pas directement
6. Policy gates qui bloquent un build	8.25, 8.29	CC8.1	Art. 21(2)(e)	Pas directement
7. SBOM des fournisseurs surveillées avec les vôtres	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3) ; 5.2, 6.10	Art. 28(1)
8. Politique egress et enregistrements réseau du build	8.25	CC8.1	Art. 21(2)(d)	Pas directement

Ce qu'une SBOM ne prouvera pas

• Votre contrôle d'accès, votre réponse aux incidents, votre continuité d'activité, la sécurité liée aux ressources humaines, la cryptographie ou la sécurité physique.
• Que quelqu'un a corrigé quoi que ce soit. Cela relève de votre processus et de ses enregistrements.
• Que votre propre code est exempt de failles. La revue de code, le SAST et les tests en sont les preuves.
• Ce que contiennent les binaires reçus sans SBOM.
• Que vous êtes certifié. Une SBOM n'est pas un certificat, et un certificat détenu par votre fournisseur d'outils certifie le système de management de ce fournisseur, pas vous.

La place de CRACI

CRACI remplace vos runners hébergés par GitHub et enregistre ce que chaque build a récupéré : la SBOM provient donc du build de release lui-même, avec un état de complétude pour chaque job.

• Les SBOM surveillées sont réévaluées en continu à mesure que de nouvelles vulnérabilités sont publiées (suivi des vulnérabilités).
• L'historique des builds montre quels builds contenaient une dépendance vulnérable, et donc la période pendant laquelle vous étiez exposé, dans la limite de votre durée de conservation. Si votre audit couvre une période plus longue, exportez la SBOM de chaque release et conservez-la avec la release.
• Les équipes sécurité trient les vulnérabilités trouvées et les transmettent aux équipes responsables du correctif, et CRACI prend en charge VEX pour consigner les produits qu'une vulnérabilité n'affecte pas.
• Les policy gates peuvent bloquer un build sur des résultats, y compris un build qui contient une CVE précise.
• Des SBOM tierces peuvent être ajoutées : les composants achetés sont ainsi surveillés aux côtés de vos propres builds.
• Les SBOM s'exportent en CycloneDX ou SPDX, et l'API renvoie les SBOM, les traces réseau et les données de provenance. La politique egress enregistre et limite les destinations auxquelles chaque build peut se connecter.

CRACI fournit des preuves pour ces mesures. Il ne vous rend pas conforme à ISO 27001 ou SOC 2, ni prêt pour NIS2, et ce n'est pas une plateforme d'automatisation de la conformité. Le certificat de CRACI est un fait distinct : le système de management de la sécurité de l'information de CRACI Corporation Oy pour le développement et l'exploitation de la plateforme CRACI est certifié ISO/IEC 27001, délivré par Into Certification. Il couvre la façon dont CRACI exploite son service, pas votre organisation ni vos produits. Voir la sécurité chez CRACI, et comment fonctionne CRACI pour l'ensemble de la plateforme.

Quand CRACI n'est pas la réponse

• Vos builds ne tournent pas sur GitHub Actions. C'est la seule CI que CRACI prend en charge aujourd'hui ; d'autres systèmes de CI sont sur la roadmap.
• Il vous faut une plateforme d'automatisation de la conformité pour les politiques, les revues d'accès et le workflow des auditeurs. Gardez-en une ou achetez-en une ; voir les contrôles SBOM SOC 2 comparés.
• Vos lacunes de preuves sont surtout organisationnelles : politiques, formation, réponse aux incidents.
• Votre principal risque fournisseur, ce sont des binaires reçus sans SBOM. L'analyse binaire répond à ce cas.

Vous répondez à la demande d'un client ? Voir comment répondre à une demande de SBOM d'un client, le guide pour les fournisseurs de composants et la checklist que votre client appliquera.

Les SBOM comme preuves de conformité : questions fréquentes

ISO 27001 exige-t-elle une SBOM ?

Non. ISO/IEC 27001:2022 ne cite pas les SBOM. Les mesures 5.9 (inventaire), 5.21 (chaîne d'approvisionnement TIC) et 8.8 (vulnérabilités techniques) de l'annexe A demandent des résultats qu'une SBOM étaye, et c'est l'organisation et son auditeur qui décident des preuves suffisantes.

SOC 2 exige-t-il une SBOM ?

Non. Les Trust Services Criteria décrivent des résultats attendus et ne citent pas les SBOM. Une SBOM par release, réévaluée par rapport aux nouveaux avis de sécurité, est une preuve pour CC7.1, et un pipeline de build enregistré étaye CC8.1 sur la gestion des changements.

NIS2 exige-t-elle une SBOM ?

Non. L'article 21, paragraphe 2, point d), demande la sécurité de la chaîne d'approvisionnement et le point e) le traitement des vulnérabilités, sans citer les SBOM. Le règlement d'exécution (UE) 2024/2690, qui couvre certains fournisseurs de services numériques, demande au point 6.1.2, point c), des informations sur les composants matériels et logiciels des produits TIC, toujours sans le mot SBOM.

Quelles mesures de l'annexe A d'ISO 27001 une SBOM étaye-t-elle ?

Principalement 5.9 (inventaire des informations et autres actifs associés), 5.19 à 5.22 (fournisseurs et chaîne d'approvisionnement TIC) et 8.8 (gestion des vulnérabilités techniques). Un enregistrement de build touche en partie 8.25, 8.29 et 8.30. Les mesures 8.26 à 8.28 portent sur les exigences, la conception et le code, hors du champ d'une SBOM.

Que demandent les clients soumis à NIS2 à leurs fournisseurs de logiciels ?

En général une description du développement sécurisé, les composants de la version livrée, un engagement à traiter les vulnérabilités, un moyen de recevoir les informations sur les vulnérabilités, et une justification lorsqu'une vulnérabilité ne s'applique pas. Ces questions découlent de l'article 21, paragraphe 3, et, pour certains secteurs, des points fournisseurs du règlement d'exécution 2024/2690.

Une SBOM suffit-elle comme preuve pour la mesure 8.8 d'ISO 27001 ?

Non. Elle montre ce que contient chaque release. La mesure 8.8 demande aussi de prouver que vous obtenez les informations sur les vulnérabilités, évaluez votre exposition et agissez. Associez la SBOM à une réévaluation continue, à un enregistrement des releases concernées et aux décisions prises.

Quelle est la différence entre être conforme et disposer de preuves ?

La conformité signifie que vos processus satisfont aux exigences du référentiel, selon l'appréciation d'un auditeur ou d'un client. Les preuves montrent que ces processus fonctionnent. Une SBOM est une preuve pour quelques mesures. Elle ne vous rend conforme à aucun référentiel.