Les outils de sécurité IA lisent votre code. Encore faut-il enregistrer votre build.

Votre équipe ajoute probablement déjà l'IA à sa sécurité

La plupart des équipes d'ingénierie ont désormais au moins un outil d'IA dans leur boucle de sécurité. Un modèle relit les pull requests. Un autre propose des corrections pour les alertes d'analyse statique. Un troisième classe les résultats des scanners entre « à examiner » et « probablement du bruit ». Ces outils font gagner un temps réel, et rien sur cette page ne plaide contre eux.

La vraie question est de savoir quelles tâches leur confier et lesquelles exigent un enregistrement qui donne le même résultat à chaque fois. La question corollaire : que lisent vos outils d'IA lorsqu'ils se prononcent sur vos dépendances ?

Ce que les outils de sécurité IA font bien

• La revue de code par IA. GitHub Copilot code review laisse des commentaires en langage naturel et des suggestions de code sur les pull requests, et peut suivre des instructions propres au dépôt. Il excelle dans le travail de lecture qu'un relecteur pressé laisse de côté.
• Les corrections par IA. GitHub Copilot Autofix « génère automatiquement des suggestions de modification du code pour les alertes CodeQL détectées sur les pull requests et sur la branche par défaut ». Le développeur obtient un correctif proposé à côté de l'alerte, au lieu d'un lien vers une page CWE.
• Le tri par IA. Les fonctionnalités d'IA de Semgrep trient automatiquement les résultats de Semgrep Code et proposent des corrections. Semgrep indique que son filtrage du bruit est « précis à plus de 95 % pour classer les résultats de Semgrep Code comme faux positifs ».

Remarquez le point commun des deux derniers. Copilot Autofix travaille sur des alertes CodeQL. Le tri de Semgrep travaille sur les résultats du moteur à base de règles de Semgrep. L'IA ajoute du jugement par-dessus un résultat déterministe. Elle ne produit pas elle-même les résultats sous-jacents.

Ce que les éditeurs disent des limites

Les descriptions les plus claires des limites des outils d'IA viennent des éditeurs eux-mêmes, ce qui est à leur honneur.

• Sur la revue de code, GitHub écrit que « Copilot peut ne pas identifier tous les problèmes présents dans le code » et qu'il « présente un risque d'hallucination », c'est-à-dire qu'il peut signaler des problèmes qui n'existent pas.
• Sur Autofix, GitHub écrit qu'il « utilise un modèle génératif non déterministe. 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 ».
• Toujours sur Autofix : « Le système ne sait pas quelles versions de dépendances sont prises en charge ou sûres, et peut suggérer des dépendances inventées publiées sous des noms statistiquement probables. »

Rien de tout cela ne rend ces outils moins utiles. Cela définit leur rôle : produire des suggestions qu'une personne vérifie. C'est un autre rôle que de produire l'enregistrement qui sert de référence à cette vérification.

Deux couches, deux rôles

CRACI se place dans la couche d'enregistrement. Il remplace le runner GitHub Actions (vous remplacez runs-on par craci), et un proxy qui comprend les paquets observe le trafic du build vers les sources de paquets pendant l'exécution du job. Le résultat : une SBOM de ce que le job a réellement 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.

Là où une visibilité déterministe est nécessaire

« Sommes-nous concernés ? »

Lorsqu'un nouvel avis de sécurité paraît, la première question est de savoir si l'un de vos builds incluait la version concernée. Les éléments minimaux SBOM 2026 de la CISA posent l'exigence clairement : le destinataire d'une SBOM « devrait pouvoir conclure qu'une vulnérabilité nouvellement signalée ne le concerne pas si la SBOM ne liste pas le composant ». Cette conclusion ne tient que si la liste est complète. Un modèle peut vous aider à lire la réponse. Ce n'est pas à lui de décider ce que contenait le build.

CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts et réévalue les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées : la question trouve sa réponse dans ce qui a été enregistré.

Les dépendances ajoutées par une IA

Les assistants de codage IA ajoutent des dépendances, et la recherche montre qu'ils nomment parfois des paquets qui n'existent pas. Une étude présentée à USENIX Security 2025 a généré 576 000 échantillons de code avec 16 modèles et a constaté que la part moyenne de paquets hallucinés était d'au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source. Un nom qui n'existe pas aujourd'hui peut être enregistré demain. Quel que soit l'auteur d'une dépendance, humain ou non, CRACI enregistre le paquet que le build a réellement téléchargé, et les politiques de trafic sortant peuvent limiter un job aux sources de paquets que vous approuvez.

Audits et questions des clients

Un auditeur ou l'équipe sécurité d'un client vous demandera comment vous savez ce qui a été livré. « Le modèle l'a dit » est une réponse faible. « Voici la SBOM enregistrée pendant le build de release, son état de complétude et la trace réseau de ce job » est une réponse solide. Les SBOM s'exportent en CycloneDX ou SPDX, vulnérabilités comprises, et l'API renvoie les SBOM, les traces réseau et la provenance.

Des réponses reproductibles

Certaines questions appellent la même réponse, quels que soient la personne qui la pose et le moment. Quels paquets la release de mardi dernier a-t-elle récupérés ? Un modèle génératif sait bien formuler cette réponse, mais de l'aveu même de ses éditeurs, il peut la formuler différemment à chaque fois. Un build enregistré donne une seule réponse.

Comment les deux s'articulent

Le schéma qui fonctionne est celui qu'utilisent déjà Copilot Autofix et Semgrep : des données déterministes en dessous, le jugement de l'IA par-dessus.

1. Laissez la revue de code et les corrections par IA travailler sur les pull requests, avec un humain qui approuve chaque modification.
2. Laissez CRACI enregistrer ce que chaque build a récupéré et indiquer si cet enregistrement est complet.
3. Lorsque vous voulez l'aide de l'IA sur le risque lié aux dépendances, donnez au modèle la SBOM enregistrée. La REST API publique de CRACI renvoie la SBOM en CycloneDX, la trace réseau du job et la provenance de l'artefact.
4. Conservez comme preuve la SBOM enregistrée, et non le résumé qu'en fait le modèle.

Si votre équipe écrit une grande partie de son code avec des assistants IA, notre page sur la sécurité du développement assisté par IA traite de cette situation, et la génération de SBOM au build explique comment l'enregistrement est produit.