Sécurité IA et preuves déterministes comparées

Chaque comparatif indique ce que l'autre produit fait bien, en quoi CRACI diffère et quand utiliser les deux. Pour toutes les catégories, consultez tous les comparatifs.

Deux couches, deux rôles

La plupart des équipes de sécurité ajoutent déjà de l'IA : pour relire le code, trier les résultats et rédiger des correctifs. C'est un bon usage. La question est de savoir à partir de quoi l'IA travaille. Un programme de sécurité a besoin de deux couches :

Une couche d'IA qui lit, explique et agit : revue de code, tri et pull requests de correction.
Une couche d'enregistrement qui dit ce qui s'est réellement passé : quelles dépendances chaque build a récupérées, enregistrées de la même façon à chaque fois, et en indiquant où l'enregistrement est incomplet.

L'IA fonctionne mieux à partir de l'enregistrement. La suite de cette page et les guides ci-dessous montrent les points forts de chaque couche.

Trois tests pour les données de sécurité

Les données de sécurité qui quittent l'équipe d'ingénierie, dans un audit, un questionnaire client ou un rapport CRA, doivent passer trois tests.

Reproductibilité. Posez deux fois la même question et obtenez la même réponse. La sortie d'un modèle peut varier d'une exécution à l'autre ; un enregistrement du build, non.
Auditabilité. Montrez comment vous le savez. Un enregistrement renvoie au build dont il provient ; une réponse déduite ne peut pas justifier son raisonnement de la même façon.
Complétude. Vous ne pouvez pas signaler ce que vous n'avez jamais vu. Ni un outil d'IA ni un scanner ne peuvent lister une dépendance qu'ils n'ont jamais eue sous les yeux.

Le déterminisme est nécessaire, mais pas suffisant. Les générateurs de SBOM sont déterministes, et pourtant ils se contredisent : ce qui comble l'écart, c'est l'observation, c'est-à-dire enregistrer ce que le build a récupéré et dire quand l'enregistrement est incomplet. CRACI marque chaque job et chaque cache comme Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. IA et sécurité déterministe, avec un exemple concret

Là où l'IA excelle

La revue de code : le travail de lecture qu'un relecteur débordé saute, sous forme de commentaires et de suggestions sur les pull requests.
Le tri : expliquer un avis de sécurité en langage clair et classer ce qu'il faut regarder en premier.
Les correctifs : écrire la modification, adapter le code à une mise à niveau incompatible et ouvrir la pull request. L'utilité de ces correctifs dépend de ce qu'on demande à l'IA de corriger. Remédiation des vulnérabilités par l'IA
Le travail à partir d'une SBOM enregistrée : résumer quels composants présentent un risque et rédiger la documentation associée, pour relecture humaine.

Là où il vous faut un enregistrement

« Sommes-nous concernés ? » Lorsqu'un nouvel avis de sécurité paraît, la réponse doit couvrir chaque build qui a récupéré le paquet, pas seulement ceux qu'un modèle ou un scan a eu l'occasion d'examiner.
Les dépendances ajoutées par une IA. Les assistants de codage IA ajoutent des dépendances et citent parfois des paquets qui n'existent pas. Un enregistrement du build montre ce qui a réellement été téléchargé.
Les audits et les questions des clients. Un auditeur ou un client veut des preuves qu'il peut vérifier, pas une description.
Les SBOM au titre du CRA. Une SBOM générée par IA est une supposition sur votre build ; le Cyber Resilience Act et les éléments minimaux de la CISA de 2026 attendent un enregistrement. Pourquoi une SBOM générée par IA n'est pas une preuve

La règle est simple : laissez le build produire l'enregistrement, et laissez l'IA le lire. Comment les outils de sécurité IA et CRACI s'articulent

CRACI comparé à chaque outil

L'IA et la sécurité : les réponses

Un outil d'IA peut-il rédiger ma SBOM ?

Il peut rédiger rapidement quelque chose qui y ressemble. Mais un modèle travaille à partir du code et des fichiers qu'on lui montre, pas de ce que le build a récupéré, et l'hallucination est un mode de défaillance documenté. Les régulateurs et les clients demandent un enregistrement de ce que contient le produit. Laissez le build produire la SBOM, et laissez le modèle la lire.

Les outils de sécurité IA remplacent-ils le SCA ou les preuves de build ?

Non. La revue de code par IA, le tri et les pull requests de correction sont des ajouts utiles à un programme de sécurité, mais ils fonctionnent mieux à partir de données complètes et reproductibles. Les deux couches jouent des rôles différents, et la plupart des équipes ont besoin des deux.

Un scanner déterministe suffit-il ?

Le déterminisme est nécessaire, mais pas suffisant. Les générateurs de SBOM sont déterministes, et pourtant ils se contredisent, car chacun décide à sa manière de ce qui compte comme composant. Un scanner déterministe peut reproduire la même réponse incomplète à chaque fois. Ce qui comble l'écart, c'est d'enregistrer ce que le build a réellement récupéré, et de dire quand l'enregistrement est incomplet.

Où se situe CRACI ?

Dans la couche d'enregistrement. CRACI remplace le runner GitHub Actions, et un proxy qui comprend les paquets enregistre ce que chaque job récupère pendant son exécution. Il en résulte une SBOM de ce que le job a récupéré, un état de complétude pour chaque job et chaque cache, et une trace réseau. L'API renvoie les SBOM, les traces réseau et la provenance. Les outils d'IA peuvent travailler à partir de cet enregistrement.

IA et sécurité