Votre plateforme SOC 2 montre que le contrôle fonctionne. CRACI enregistre ce que contenait le build.

Le dispositif dont parle cette page

De nombreuses équipes SaaS aboutissent au même dispositif. Un générateur tel que Syft ou Trivy produit une SBOM dans la CI, un scanner de vulnérabilités surveille les dépôts, et une plateforme d'automatisation de la conformité se connecte à GitHub et au compte cloud pour collecter les preuves SOC 2. Cela fonctionne. Les auditeurs l'acceptent, et personne ne passe la semaine précédant un audit à faire des captures d'écran.

Ces plateformes y excellent. Vanta indique qu'il « connects read-only to your cloud, identity, code, and device tools » et « automatically pulls evidence, maps it to controls », avec plus de 1 200 tests automatisés exécutés chaque heure. Drata se connecte à « cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more » pour collecter les preuves et les associer aux contrôles SOC 2. Si l'objectif est un rapport SOC 2 sans réserve, c'est le bon outil.

Cette page porte sur une question plus étroite : ce que ces preuves disent de la SBOM elle-même.

Ce que demande réellement un contrôle SOC 2

Les examens SOC 2 rendent compte par rapport aux Trust Services Criteria de l'AICPA. Le critère le plus proche des SBOM est CC7.1 :

"To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities."

AICPA, 2017 Trust Services Criteria, CC7.1

Le critère décrit un résultat. Il vous laisse, à vous et à votre auditeur, le choix de la méthode et de la profondeur de l'inventaire de composants qui la sous-tend. Un test automatisé demande donc généralement si le contrôle est en place et fonctionne : un scanner est-il connecté, a-t-il tourné, les résultats ont-ils été traités conformément à votre politique ? C'est une question légitime, et c'est la case à cocher.

Le contrôle ne demande pas si la SBOM derrière le scan listait tout ce que contenait la release. Une vulnérabilité située dans un composant que la SBOM n'a jamais listé ne peut être rapprochée de rien : le scan revient donc sans résultat et le contrôle reste au vert.

Là où un contrôle au vert et une SBOM complète divergent

Les générateurs de SBOM travaillent à partir des fichiers qu'ils ont sous les yeux, et leur propre documentation montre où cela laisse des lacunes :

• Sur expressjs/express 5.2.1, qui ne commite aucun lockfile, un générateur qui résout les dépendances à partir des lockfiles n'a rien à résoudre. Il peut tout de même renvoyer un document listant ce qu'il reconnaît par ailleurs, comme des GitHub Actions et des fichiers de workflow, et aucune des dépendances npm déclarées dans package.json.
• Des générateurs différents renvoient des listes différentes à partir du même checkout, car chacun décide seul de ce qui compte comme composant. L'export du graphe de dépendances de GitHub s'en éloigne encore : il est construit à partir de ce que GitHub sait du dépôt et lit la branche par défaut plutôt que le commit épinglé.
• Le champ fournisseur de la NTIA reste vide dans la plupart des documents, car la plupart des générateurs n'ont aucune source pour le renseigner.

Aucun de ces outils n'est défaillant. Chacun a lu les fichiers vers lesquels on l'a pointé, et chacun a produit un document valide dans un format standard, dans les temps. Pour un test de conformité, le contrôle a fonctionné. La SBOM ne décrivait pourtant pas le logiciel.

Ce que CRACI ajoute aux preuves

CRACI remplace le runner GitHub Actions. Vous remplacez runs-on par craci, et les exécutions apparaissent toujours dans l'interface GitHub. La SBOM est générée dans ce runner pendant le build : un proxy qui comprend les paquets observe le trafic vers les sources de paquets, de sorte que l'enregistrement reflète ce que le job a récupéré et non ce qu'un fichier dit qu'il devrait récupérer.

La complétude est indiquée, pas supposée

Chaque job et chaque cache reçoivent l'un des cinq états de complétude : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Les preuves de dépendances suivent les caches : les paquets restaurés depuis un cache existant sont reportés au lieu de disparaître silencieusement. Lorsqu'un enregistrement est incomplet, il le dit.

Cela rejoint l'évolution des normes. Les éléments minimaux de SBOM 2026 de la CISA et de ses partenaires demandent aux auteurs de SBOM d'« explicitly state whether the information is unknown to the SBOM author » au lieu de laisser discrètement des champs vides.

Des preuves dans des formats acceptés par les auditeurs

Les SBOM s'exportent en CycloneDX ou SPDX, y compris les vulnérabilités détectées dans leurs composants. L'API REST publique renvoie la SBOM, la trace réseau du job et les données de provenance : les mêmes enregistrements peuvent donc rejoindre l'endroit où se trouvent vos preuves d'audit.

Un inventaire de ce qui est déployé et où

La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée, au lieu de reconstituer l'information à partir de notes de version et de tableurs.

Gardez la plateforme SOC 2

CRACI n'est pas une plateforme d'automatisation de la conformité et n'en remplace pas une. Il ne gère ni les politiques, ni les revues d'accès, ni les vérifications d'appareils, ni les questionnaires fournisseurs. Les deux répondent à des questions différentes. Votre plateforme de conformité montre qu'un contrôle existe et fonctionne. CRACI enregistre ce que le build a récupéré et indique si cet enregistrement est complet.

La différence s'accroît dès que vous vendez des logiciels dans l'UE. Le Cyber Resilience Act exige des fabricants qu'ils recensent et documentent les composants « en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au minimum les dépendances de niveau supérieur des produits » (annexe I, partie II). L'annexe VII place la SBOM dans la documentation technique et permet à une autorité de surveillance du marché de la demander. Un rapport SOC 2 atteste de la façon dont votre organisation applique ses contrôles. Une SBOM CRA décrit un produit précis. Notre présentation du CRA couvre le calendrier, et la page sur la conformité au CRA couvre ce que CRACI automatise. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont a besoin une démarche plus large de conformité au CRA ; il ne vous rend pas conforme à lui seul.

Comment l'essayer sans toucher à votre audit

1. Choisissez un dépôt dont la SBOM alimente déjà vos preuves SOC 2.
2. Faites pointer son workflow de release vers CRACI en remplaçant runs-on par craci.
3. Comparez la SBOM enregistrée à celle que vous générez aujourd'hui, composant par composant, et vérifiez l'état de complétude du job.
4. Décidez si la différence a sa place dans vos preuves.

Vous pouvez en savoir plus sur la génération de SBOM au build et les preuves pour le CRA, ou voir comment nous documentons nos propres contrôles sur notre page sécurité.