Les limites des outils de sécurité IA, et ce que couvrent les preuves de build déterministes

L'argument, formulé au plus juste

Il ne s'agit pas d'un réquisitoire contre l'IA en sécurité. Les modèles savent lire du code, expliquer un résultat et proposer une correction, et les équipes qui les utilisent bien vont plus vite. L'argument est plus étroit : pour des enregistrements qui doivent tenir dans la durée, un modèle probabiliste n'est pas la bonne source principale. Cela concerne la SBOM que vous remettez à un régulateur, la provenance de l'artefact que vous avez livré et la réponse à la question « étions-nous concernés ? »

Trois propriétés déterminent si un enregistrement tient. Chaque section ci-dessous en traite une, avec exemples et sources.

1. Reproductibilité : demander deux fois, obtenir la même réponse

Un enregistrement de sécurité n'est utile que si quelqu'un d'autre peut obtenir la même réponse à partir de la même entrée. Les modèles de langage ne le promettent pas, et les éditeurs le disent.

• La documentation d'Anthropic : « Même avec une température fixée à 0, les résultats ne seront pas entièrement déterministes et des entrées identiques peuvent produire des résultats différents d'un appel d'API à l'autre. »
• GitHub, à propos de Copilot Autofix : « Même avec la même alerte et le même code, il peut échouer à produire une suggestion viable, ou la suggestion peut varier d'une tentative à l'autre. »
• Les chercheurs à l'origine du framework SecLLMHolmes ont testé huit LLM sur 228 scénarios de code pour IEEE S&P 2024. Ils rapportent que les modèles « fournissent des réponses non déterministes » et que, « en changeant simplement des noms de fonctions ou de variables, ou en ajoutant des fonctions de bibliothèque dans le code source », PaLM2 et GPT-4 ont donné des réponses incorrectes dans 26 % et 17 % des cas.

Exemple. Deux ingénieurs demandent au même assistant si un service est exposé à un nouvel avis de sécurité. L'un obtient « non », l'autre « peut-être, vérifiez l'arbre transitif ». Aucune de ces réponses n'est un enregistrement, et aucune ne peut être reproduite pour un auditeur six mois plus tard.

Un build enregistré n'a pas ce problème, car rien n'est déduit. CRACI observe les paquets qu'un job récupère depuis les sources de paquets pendant son exécution, et la SBOM est l'enregistrement de cette observation.

2. Auditabilité : montrer comment vous savez

Les audits reposent sur la question « comment le savez-vous ? ». Un modèle peut donner une réponse fluide, mais son explication n'est pas une preuve. L'évaluation SecLLMHolmes a constaté que les LLM produisent un « raisonnement incorrect et infidèle » sur les vulnérabilités qu'ils évaluent : un verdict correct peut donc s'accompagner d'une explication qui ne tient pas.

Les normes évoluent vers des enregistrements qui expliquent leur propre origine. Les éléments minimaux SBOM 2026, publiés par la CISA avec la NSA, le FBI et des partenaires internationaux, ajoutent un SBOM Tool Name, une SBOM Tool Version et un SBOM Generation Context qui indique si la SBOM a été produite « before build », pendant le « build » ou « after build ». Le même document avertit que « les organisations peuvent prendre en compte les erreurs, qu'elles proviennent des pratiques de l'auteur de la SBOM ou du choix d'outils inadaptés, dans leurs décisions de gestion des risques ».

Exemple. Le questionnaire d'un client demande comment votre SBOM a été produite. « Un assistant a lu le dépôt et l'a rédigée » fournit bien un contexte de génération, mais pas un contexte qu'un relecteur puisse vérifier. « Elle a été enregistrée dans le runner CI pendant le build de release, et l'état de complétude du job est Complete » est une affirmation que le relecteur peut vérifier par rapport au build.

3. Complétude : impossible de signaler ce que l'on n'a jamais vu

Un modèle raisonne sur ce qu'on lui montre. Si les fichiers qu'il lit ne décrivent pas le logiciel, sa réponse ne le décrira pas non plus, et rien dans le résultat ne le signale. Les recommandations 2026 de la CISA placent la barre au niveau de la décision du destinataire : il « devrait pouvoir conclure qu'une vulnérabilité nouvellement signalée ne le concerne pas si la SBOM ne liste pas le composant ». Cela ne fonctionne que si l'absence dans la liste signifie l'absence dans le build.

Exemple. Le dépôt anthropics/claude-code en v2.1.259 ne contient aucun manifeste de dépendances ni aucun lockfile. Le paquet npm publié déclare zéro dépendance d'exécution et encapsule un binaire natif précompilé. Tout outil qui lit le dépôt, IA ou non, n'a presque rien à lister, alors que le programme exécuté est un binaire compilé.

Exemple. Les outils de codage IA peuvent aussi créer eux-mêmes l'écart. GitHub avertit que Copilot Autofix « peut suggérer des dépendances inventées publiées sous des noms statistiquement probables ». Une étude USENIX Security 2025 portant sur 576 000 échantillons de code générés par 16 modèles a relevé un taux moyen de paquets hallucinés d'au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source, avec 205 474 noms de paquets hallucinés uniques.

Déterministe : nécessaire, mais pas suffisant

Une version honnête de cet argument doit inclure le point suivant. Les générateurs de SBOM sont déterministes, et pourtant ils se contredisent. Appliqués au même commit de expressjs/express, ils peuvent renvoyer des listes différentes, car chacun décide à sa manière de ce qui compte comme composant et des fichiers auxquels se fier. Le dépôt ne versionne aucun lockfile : un outil qui résout les dépendances à partir d'un lockfile n'a donc aucune des dépendances de package.json à signaler.

Un scanner déterministe reproduit la même réponse incomplète à chaque fois. La répétabilité est nécessaire, mais ce qui comble l'écart, c'est l'observation : enregistrer ce que le build a réellement 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.

Un exemple concret : cadrer un nouvel avis de sécurité

Un cas hypothétique : un avis est publié pour une version d'un paquet npm très utilisé. En vertu du Cyber Resilience Act, les fabricants disposent de 24 heures pour signaler une vulnérabilité activement exploitée à l'ENISA : le cadrage doit donc être rapide et juste.

L'approche « IA d'abord »

Vous demandez à un assistant de vérifier vos dépôts. Il lit les manifestes et les lockfiles, voire un Dockerfile. Il ne voit pas les paquets restaurés depuis un cache CI, les outils téléchargés par une étape de build, ni les versions résolues à l'installation dans un dépôt sans lockfile. Interrogé deux fois, il peut répondre différemment. Son résumé est utile, mais vous ne pouvez pas signer votre rapport sur cette base.

L'approche « enregistrement d'abord »

CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, sur la branche par défaut au niveau de l'organisation, et réévalue les SBOM surveillées à mesure que de nouvelles vulnérabilités apparaissent. L'API renvoie la SBOM CycloneDX de chaque build, sa trace réseau et sa provenance. Si l'enregistrement d'un job est incomplet, son état de complétude vous indique où chercher à la main. Vous pouvez toujours demander à un modèle de résumer le résultat. Il résume alors un enregistrement, il ne le génère pas.

Avec l'enregistrement, la question « quelles releases ont livré ce paquet ? » relève de la simple consultation, pas de l'enquête.

Côte à côte

Placez chaque outil là où il excelle

Utilisez l'IA là où le jugement aide et où un humain vérifie le résultat : revue de code, explication d'un résultat, ébauche d'une correction. Utilisez des enregistrements de build déterministes là où le résultat doit être reproduit, audité ou considéré comme complet : SBOM, provenance et cadrage d'incident. CRACI automatise une part importante de ces preuves sur la chaîne d'approvisionnement, au service d'une démarche CRA plus large. Il ne vous rend pas conforme à lui seul.

Découvrez comment l'enregistrement est produit avec la génération de SBOM au build, ou commencez par ce qu'exige le CRA.