La compétence d’audit de sécurité de Cloudflare transforme la revue de code par IA en workflow adversarial

Cloudflare a publié un workflow d’audit de code par IA en six phases, mais la compétence d’audit de sécurité de Cloudflare n’est pas une simple invite demandant à un modèle de trouver des bugs. Elle attribue à des agents distincts la cartographie du code, la recherche de vulnérabilités, la contestation des constats et la vérification des éléments probants qui subsistent.

Cette distinction compte, car les rapports de sécurité générés par IA contiennent souvent des affirmations plausibles sans chemin d’attaque valide. La conception de Cloudflare traite chaque vulnérabilité proposée comme une allégation qu’un autre agent doit tenter de réfuter. Elle consigne également ce que l’audit a couvert, ce qui rend les analyses manquantes plus visibles.

La publication open source regroupe des idées que Cloudflare a développées en construisant une infrastructure interne de détection de vulnérabilités bien plus vaste. La compétence publique cible un dépôt et une exécution d’audit. Le système interne de Cloudflare, en revanche, conserve les résultats entre les dépôts, suit les dépendances et gère des milliers de constats.

C’est là que réside la tension centrale de cette publication. Une compétence réutilisable abaisse le seuil d’accès à une revue de code structurée par IA, mais elle ne peut pas reproduire à elle seule l’infrastructure interne de Cloudflare. Les développeurs obtiennent un point de départ plus solide, pas un remplacement autonome des ingénieurs sécurité.

Ce que la compétence d’audit de sécurité de Cloudflare change réellement

Cloudflare transforme la revue de sécurité par IA d’une conversation en un processus produisant des preuves, avec une couverture explicite et des étapes de vérification.

Le dépôt de la compétence d’audit public décrit un workflow conçu pour les agents de programmation prenant en charge les outils et les sous-agents isolés. Il est distribué sous licence MIT et peut être installé via l’interface en ligne de commande Skills.

La compétence d’audit de sécurité de Cloudflare répartit un audit en six phases. La reconnaissance cartographie l’architecture logicielle, les frontières de confiance, les surfaces d’entrée et les éléments probants disponibles. Le processus consigne cette cartographie dans un document d’architecture et un registre de couverture lisible par machine.

La recherche guidée par la couverture vient ensuite. L’agent parent attribue à des chasseurs isolés des zones et des catégories d’attaques définies. Chaque chasseur enregistre ce qu’il a vérifié au lieu de ne renvoyer qu’une liste de problèmes supposés.

Ce registre est important, car un rapport succinct peut autrement créer une fausse impression de confiance. Un agent peut inspecter le code d’authentification, ne rien trouver et laisser entendre que l’ensemble de l’application paraît sûr. Un enregistrement de couverture peut montrer que l’analyse des données, la configuration de déploiement, la gestion des dépendances ou l’isolation des locataires ont reçu peu d’attention.

La validation des candidats confie chaque piste distincte à un nouveau vérificateur. Celui-ci tente de rejeter la vulnérabilité proposée en contrôlant ses hypothèses, le chemin source, le principal affecté et l’issue de sécurité. L’agent de recherche n’approuve pas son propre travail.

Les constats qui subsistent passent ensuite dans une sortie structurée. La compétence sépare les enregistrements entre constats confirmés, problèmes nécessitant une validation et candidats rejetés. Un schéma définit les champs requis, tandis que des validateurs JavaScript inclus vérifient mécaniquement les fichiers.

Les phases finales vérifient indépendamment les affirmations sur le code source et génèrent des rapports neutres vis-à-vis de la cible. Toute modification substantielle d’un constat déclenche une nouvelle passe de vérification. Cette conception vise à empêcher un rédacteur de rapport de renforcer discrètement une affirmation faible lors de la synthèse.

Le résultat diffère d’un audit de sécurité de code par IA classique sur un point essentiel. Le livrable comprend un compte rendu des surfaces examinées, des idées rejetées, des faits non résolus et des constats vérifiés indépendamment. Un rapport à l’apparence rassurante n’est plus le seul artefact.

Cloudflare définit également une limite d’exécution stricte. Les compilations, tests, fuzzers, navigateurs et fixtures contrôlées par la cible exigent un bac à sable du système d’exploitation sans accès réseau externe. Sans ces contrôles, le workflow doit conserver une piste comme non vérifiée au lieu d’exécuter du code non fiable.

Cette restriction rend la publication moins pratique qu’une invite d’audit en une ligne. Elle reflète aussi un véritable problème de sécurité. Le code examiné peut contenir des instructions ou des comportements de compilation qui attaquent l’environnement d’audit lui-même.

Pourquoi Cloudflare a créé une compétence avant une infrastructure à l’échelle de toute sa flotte

La compétence publique a de la valeur parce qu’elle formalise la méthode d’audit de Cloudflare, tout en révélant pourquoi une session d’agent unique atteint un plafond opérationnel.

Cloudflare indique que le projet a commencé comme une compétence de sécurité d’environ 450 lignes pour un seul dépôt. Les ingénieurs ont affiné ses invites jusqu’à ce qu’elle détecte des bugs utiles, puis ont intégré ses scénarios et règles de validation dans un système plus vaste.

L’entreprise a détaillé cette évolution dans son article d’ingénierie consacré à l’infrastructure de vulnérabilités. La première version utilisait trois agents de recherche pour la reconnaissance, des chasseurs distincts pour les catégories d’attaques, des validateurs adversariaux, des constats structurés et une vérification indépendante du code source.

Cloudflare a identifié trois limites pendant ces premières exécutions. Les longues sessions épuisaient le contexte du modèle, les exécutions interrompues perdaient leur progression et les revues d’un seul dépôt manquaient les relations avec les services consommateurs.

Ces échecs n’étaient pas simplement des problèmes de qualité des modèles. C’étaient des problèmes de gestion d’état.

Un modèle peut raisonner sur le code présent dans son contexte, mais un audit de grande ampleur produit de nombreuses hypothèses parallèles. Chaque hypothèse porte des fichiers, des frontières de confiance, des hypothèses, des expériences, des contre-arguments et des changements de statut. Compresser cet historique dans un résumé de conversation peut éliminer des détails décisifs.

Cloudflare a réagi en externalisant l’état. Son infrastructure ultérieure traite les modèles de langage comme des travailleurs remplaçables et conserve les informations d’audit durables en dehors de leurs fenêtres de contexte. Une base de données stocke l’exécution, le dépôt et l’étape de chaque tâche.

Cette distinction explique pourquoi Cloudflare a publié le point de départ plutôt que de le présenter comme son système interne achevé. Une compétence peut encoder une séquence rigoureuse dans un environnement de programmation. Elle ne peut pas fournir automatiquement un inventaire de flotte, des files d’attente durables, des graphes de dépendances ou de la télémétrie de production.

Cloudflare indique qu’il a fallu environ six semaines pour passer de sa première compétence à un système couvrant 128 dépôts. Ce système interne fonctionne sur Rust, Go, C, Lua, TypeScript, Python et des formats de configuration, sans orchestration propre à chaque langage.

Son workflow plus vaste sépare la découverte de la validation. Le Vulnerability Discovery Harness cartographie et recherche les faiblesses potentielles. Un autre Vulnerability Validation System déduplique les résultats, vérifie leur pertinence en production et gère la remédiation.

Cloudflare indique utiliser des modèles différents pour ces deux étapes. Ce choix réduit la dépendance aux schémas de raisonnement récurrents d’un seul modèle. Il permet aussi à l’entreprise de changer de fournisseur sans repenser le processus de sécurité autour d’un modèle particulier.

Cette position neutre vis-à-vis des modèles met sous pression les fournisseurs qui présentent les performances aux benchmarks comme la principale mesure d’un produit de sécurité par IA. L’argument de Cloudflare est que l’orchestration, les preuves et le rejet indépendant déterminent si la sortie d’un modèle devient un travail d’ingénierie utile.

L’entreprise ne prétend pas que la compétence recrée son pipeline de production. Ses propres recommandations indiquent que les équipes devraient commencer par la reconnaissance, la recherche et la validation. Le suivi inter-dépôts et la déduplication dédiée ne deviennent utiles qu’une fois que le volume d’audits crée ces problèmes.

Cette séquence offre aux petites équipes un point d’entrée pratique. Elles peuvent vérifier si les invites et les règles de preuve fonctionnent sur leur code avant de construire autour d’elles une infrastructure coûteuse.

Elle évite également que la publication publique ne devienne une démonstration produit trompeuse. Le dépôt propose la méthode qui a donné naissance au système de Cloudflare, et non le système complet qui opère désormais sur l’ensemble de sa flotte.

Le véritable adversaire est la revue de code par IA en une seule passe

L’infrastructure de vulnérabilités de Cloudflare remet en cause l’hypothèse selon laquelle un modèle performant peut inspecter un dépôt, identifier de véritables failles et évaluer de manière fiable ses propres conclusions.

Une revue en une seule passe suit généralement un schéma familier. Le développeur donne à un agent de programmation accès à un dépôt et lui demande de détecter des vulnérabilités de sécurité. L’agent lit certains fichiers, identifie des schémas suspects et rédige un rapport soigné.

Ce processus peut produire des pistes utiles. Il peut aussi dissimuler trois échecs distincts.

Premièrement, le modèle choisit ce qu’il inspecte sans conserver de registre durable de ce qu’il a ignoré. Deuxièmement, le même processus de raisonnement génère et évalue chaque affirmation. Troisièmement, un langage persuasif peut faire paraître définitives des preuves incomplètes.

Le workflow de Cloudflare attaque séparément chacun de ces échecs. Le registre de couverture consigne la surface d’audit prévue. Des chasseurs indépendants examinent des unités délimitées. De nouveaux validateurs tentent de réfuter les candidats plutôt que d’améliorer leur présentation.

Cette séparation adversariale est plus importante que le simple ajout d’agents. Dix agents partageant les mêmes hypothèses peuvent générer dix versions du même faux positif. Cloudflare attribue des rôles différents et donne aux validateurs l’autorité de rejeter la théorie d’un chasseur.

La compétence exige également une défaillance concrète de frontière. Un problème confirmé doit inclure un principal, une ressource ou un résultat de sécurité affecté. L’absence d’une bonne pratique ne devient pas automatiquement une vulnérabilité.

Cette distinction filtre les constats tels qu’un comportement non restreint disponible uniquement à un administrateur déjà digne de confiance. Elle rejette également les rapports qui décrivent une défense absente sans montrer comment un attaquant franchit une frontière réelle.

Le processus interne de Cloudflare applique des exigences de preuve plus strictes. Un constat confirmé doit inclure un test reproductible sur le codebase d’origine. Le test ne peut pas dépendre de modifications du code introduites par l’agent de recherche.

Cette règle répond à un mode de défaillance particulièrement dangereux. Un agent peut modifier le code pendant ses expérimentations, puis démontrer une exploitation contre la version modifiée. Sans contrôles de l’état source, le rapport qui en résulte peut attribuer à l’application une faille créée par l’agent.

La validation mécanique ajoute une autre couche. Des contrôles de code classiques vérifient que les fichiers, chemins, correctifs et tests cités existent ou s’analysent correctement. Le modèle de langage ne décide pas lui-même si sa sortie satisfait ces exigences structurelles de base.

Cloudflare indique qu’une seule exécution de la compétence a détecté environ la moitié des vulnérabilités finalement découvertes par des exécutions répétées. Il s’agit d’une observation rapportée par l’entreprise, et non d’un taux de rappel mesuré indépendamment.

Néanmoins, ce résultat soutient le choix de conception central de la publication. Une exécution achevée n’établit pas une couverture complète, même lorsque chaque constat signalé est valide.

Un audit rigoureux de sécurité du code par IA nécessite donc deux affirmations distinctes sur le niveau de confiance. L’une concerne la validité de chaque constat. L’autre concerne l’exhaustivité de la recherche de constats par l’audit.

La compétence d’audit de sécurité de Cloudflare expose ces deux questions. Ses verdicts confirmés, non résolus et rejetés décrivent le niveau de confiance des preuves. Son registre de couverture décrit le processus de recherche.

L’analyse statique traditionnelle reste pertinente dans ce modèle. Les scanners déterministes excellent sur les schémas connus, les règles de flux de données et les contrôles reproductibles. Un agent peut explorer des hypothèses de confiance propres à l’application ou combiner des faiblesses au sein d’une logique peu familière.

L’expérience interne de Cloudflare offre également un avertissement sur les préférences d’outils supposées. L’entreprise indique que ses chasseurs n’ont pas invoqué un parcours Semgrep intégré pendant un mois d’exécutions. Ils ont préféré lire et exécuter le code, tout en demandant fréquemment des environnements ou des fixtures manquants.

Cette observation ne montre pas que l’analyse statique manque de valeur. Elle montre qu’installer un outil ne garantit pas qu’un agent l’utilisera efficacement. Les équipes doivent mesurer le comportement réel des outils au sein de leur workflow.

La concurrence ne se joue donc pas entre l’IA et les scanners conventionnels. Elle oppose des sorties de modèles non structurées à un processus d’audit combinant contrôles déterministes, exploration spécialisée et vérification adversariale.

Des résultats structurés réduisent le bruit, mais ne prouvent pas la sécurité

Le point fort de cette publication est son refus de considérer une sortie de modèle plausible comme une preuve confirmée, même si cette rigueur ne peut pas mesurer les vulnérabilités non découvertes.

Cloudflare indique que son dispositif interne de découverte a généré 20 799 candidats bruts. Environ 12 057 ont passé l’étape initiale de validation avant d’intégrer un plus vaste pool de validation.

Après l’intégration des résultats d’un autre dispositif dans ce système, le pool central comptait 13 841 enregistrements. La déduplication en a supprimé 5 442, tandis que 1 154 ont été réorientés comme cas relevant du mauvais dépôt ou à faible risque. Cloudflare indique que 7 245 résultats exploitables restaient à la disposition des équipes d’ingénierie.

Ces chiffres sont utiles, car ils montrent l’ampleur du filtrage entre la génération et la correction. Ils ne doivent pas être interprétés comme un étalon indépendant de la précision de détection.

Cloudflare sélectionne ses propres dépôts, modèles, prompts, classes d’attaque et définitions. Les chiffres publiés décrivent son pipeline opérationnel. Ils n’établissent pas les performances de la skill publique sur une base de code sans rapport.

L’entreprise évite explicitement d’affirmer un taux de faux négatifs. Un véritable dépôt ne dispose pas d’un jeu d’étiquettes exhaustif contenant chaque vulnérabilité ; le rappel ne peut donc pas être calculé directement. Des exécutions répétées qui continuent à trouver des bugs démontrent une couverture incomplète, mais pas l’ampleur du manque restant.

Cette incertitude doit être au cœur de toute évaluation. Un rapport vérifié peut établir que plusieurs résultats sont réels. Il ne peut pas établir que le code audité est sûr.

La skill publique tente de communiquer cette distinction au moyen de trois verdicts.

Un résultat confirmé dispose d’une trace source complète et d’un résultat observé délimité. Un enregistrement needs-validation préserve une question non résolue exacte sans attribuer une gravité non étayée. Un enregistrement rejeté documente la raison pour laquelle un candidat a échoué.

Conserver les candidats rejetés présente une valeur pratique. Les exécutions futures peuvent distinguer un chemin réellement nouveau d’une idée précédemment réfutée. Les réviseurs peuvent aussi vérifier si le rejet dépendait de faits ayant ensuite changé.

Cependant, une sortie structurée peut créer sa propre illusion de certitude. Un enregistrement JSON valide n’est pas nécessairement une conclusion de sécurité valide. La validation du schéma peut confirmer la présence des champs requis et de valeurs acceptées, mais elle ne peut pas prouver qu’un exploit franchit une frontière réelle.

Cloudflare répond à cette limite par une vérification fraîche des sources. Le vérificateur examine indépendamment l’affirmation concernant le code, et un remplacement significatif fait l’objet d’un nouveau contrôle. La qualité dépend néanmoins du comportement du modèle, du contexte disponible et de la justesse du modèle de menace.

Le sandboxing pose un autre défi d’adoption. La skill exige des contrôles du système d’exploitation autour des builds et expériences contrôlés par la cible. De nombreux environnements d’agents de codage du quotidien n’offrent pas cette isolation avec des limites claires de ressources et de réseau.

Les équipes qui ignorent cette exigence risquent d’exécuter des dépendances, scripts de build ou fixtures de test malveillants. Celles qui la respectent doivent conserver certaines pistes prometteuses comme non résolues jusqu’à ce qu’un environnement sûr soit disponible.

L’injection de prompts soulève une préoccupation connexe. Les fichiers source, la documentation, le texte des tickets et les artefacts générés peuvent contenir des instructions destinées à l’agent. Le workflow commercial ultérieur de Cloudflare indique qu’il traite le code, les journaux et les métadonnées comme des preuves plutôt que comme des instructions.

Cette même frontière doit exister en usage local. Un agent de sécurité ne devrait jamais interpréter le contenu d’un dépôt comme une autorité lui permettant d’exposer des identifiants, d’élargir l’accès réseau ou de modifier des systèmes sans rapport.

Le secure software framework du NIST offre un point de référence utile. Il présente le développement sécurisé comme un ensemble de pratiques organisationnelles couvrant la préparation, la protection, la production et la réponse aux vulnérabilités.

Une skill d’audit par IA ne couvre qu’une partie de ce cycle de vie. Elle peut aider à examiner le code source et à documenter des faiblesses candidates. Elle n’établit pas la sûreté de la conception, la gouvernance des accès, la provenance des dépendances, les contrôles de déploiement ou la préparation aux incidents.

La revue humaine reste essentielle pour la même raison. Les ingénieurs comprennent le comportement attendu, l’architecture de production, l’impact métier et les contrôles compensatoires qui peuvent ne pas apparaître dans un dépôt.

La publication devrait donc modifier la forme de la revue, et non éliminer les réviseurs. Les équipes de sécurité peuvent consacrer moins de temps au tri des affirmations non étayées et davantage à la vérification des preuves, à la priorisation de l’exposition et à l’approbation des correctifs.

Cloudflare relie les résultats du code au contexte de production

La stratégie plus large de Cloudflare consiste à combiner les résultats du code source avec les données de trafic et de défense, ce que la skill autonome ne peut pas accomplir seule.

Un scanner de code source peut identifier un gestionnaire non sûr sans savoir s’il s’exécute en production. Il peut ignorer quelle route atteint le code, à quelle fréquence les clients l’utilisent ou si des contrôles actifs bloquent les requêtes concernées.

Le service sur invitation Vulnerability Discovery and Remediation de Cloudflare tente de combler cette lacune. L’entreprise a annoncé ce service le 3 septembre 2026, dans le cadre de Cloudflare Managed Defense.

Selon son annonce sur la remédiation contextualisée, le service relie l’analyse de code autorisée aux Web Assets, aux données du Web Application Firewall et à l’observabilité de Workers.

Le service utilise des modèles OpenAI Daybreak, dont GPT-5.6 Cyber, pour la reconnaissance, la recherche et la validation. Cloudflare indique que les prompts transitent par AI Gateway vers les serveurs d’OpenAI. L’inférence des modèles ne s’exécute pas à l’edge de Cloudflare.

Cette implémentation illustre pourquoi la skill open source et le service commercial remplissent des rôles différents. La skill organise une enquête au niveau du dépôt. Le service ajoute des informations sur les routes déployées, le volume de requêtes, les événements de sécurité et les contrôles existants.

Le contexte de production peut modifier la priorité sans changer la validité technique. Une vulnérabilité réelle sur un chemin de développement inaccessible mérite un traitement différent de la même faille sur un endpoint public très utilisé.

Cloudflare indique que son processus peut proposer un correctif de code et une règle WAF étroitement ciblée lorsque les preuves étayent les deux. La règle à l’edge peut réduire l’exposition pendant que les ingénieurs examinent le changement de code permanent.

Le service ne permet pas au modèle de déployer sa propre proposition. Les appels d’outils sont journalisés et évalués au regard d’une politique d’accès. Des contrôles externes testent les correctifs et les règles, tandis que les clients décident si les changements sont mis en œuvre.

Cette approche fait du dispositif de vulnérabilités de Cloudflare davantage qu’un moteur de découverte. Il devient une composante d’un système de gestion de l’exposition reliant les preuves issues du code source, le contexte d’exécution, l’atténuation et la remédiation.

Cette stratégie explique aussi l’accent mis par l’entreprise sur des rapports indépendants de la cible. La même méthode d’audit peut examiner différents langages et types d’applications, tandis que les systèmes spécifiques à la production fournissent le contexte nécessaire à la priorisation.

La plupart des équipes utilisant la skill publique ne disposeront pas d’une visibilité réseau équivalente. Elles peuvent néanmoins améliorer leurs décisions en fournissant des manifestes de déploiement, des cartes de routes, des registres de responsables et des journaux assainis comme preuves contrôlées.

Elles doivent maintenir une provenance claire. Un résultat issu du code source, une affirmation de déploiement et une observation de trafic sont des affirmations différentes. Les réunir dans un même paragraphe ne doit pas effacer l’origine de chaque fait.

C’est là qu’une gestion rigoureuse des connaissances devient importante. Les équipes d’ingénierie ont besoin d’un registre consultable reliant les décisions d’architecture, les preuves d’audit, les hypothèses rejetées et les corrections ultérieures. Une base de connaissances technique maintenue peut conserver ces enregistrements au-delà d’une seule session d’agent.

La skill publique s’oriente déjà dans cette direction au moyen d’artefacts persistants. Les notes d’architecture, les enregistrements de couverture, les résultats lisibles par machine et les rapports humains donnent aux futurs réviseurs quelque chose de plus durable qu’une transcription de chat.

Néanmoins, un dépôt reste une image incomplète. Les politiques d’infrastructure, la gestion des secrets, la configuration des autorisations, les dépendances de services et le comportement des utilisateurs peuvent déterminer si une faiblesse au niveau du code source devient exploitable.

Les équipes les plus susceptibles d’en bénéficier traiteront la skill comme un générateur de preuves parmi d’autres dans un programme de sécurité plus large. Celles qui risquent le plus de rencontrer des difficultés s’attendront à ce qu’une analyse de dépôt réponde à des questions de risque de production auxquelles le dépôt ne contient pas les éléments nécessaires.

Trois signaux indiqueront si cette publication compte

Le prochain test consiste à déterminer si les développeurs peuvent reproduire la rigueur de Cloudflare sans l’infrastructure privée, les données et les équipes de sécurité de Cloudflare.

Le premier signal sera la qualité des artefacts d’audit publics. Une adoption utile produira des rapports comportant des frontières de confiance précises, des preuves reproductibles, des candidats rejetés pertinents et des questions non résolues formulées honnêtement.

Une hausse du nombre d’installations montrerait un intérêt, mais pas une efficacité. Le meilleur indicateur est de savoir si des équipes indépendantes publient des audits dont les résultats confirmés résistent à la revue des mainteneurs.

La conception actuelle de la publication soutient cette évaluation. Ses schémas de couverture et de résultats créent des artefacts comparables, tandis que les validateurs peuvent détecter les enregistrements mal formés avant le début de la revue humaine.

Le deuxième signal sera l’évolution du dépôt après un usage réel. Le dispositif interne de Cloudflare a appris grâce à des exécutions répétées, des environnements manquants, une couverture superficielle et des résultats rejetés. La skill publique sera confrontée à un éventail plus large de langages, de systèmes de build et de plateformes d’agents.

Surveillez les changements apportés aux recommandations relatives aux classes d’attaque, aux exigences de sandboxing, à la modélisation de la couverture et au traitement des faux positifs. Ces mises à jour révéleront quelles parties du processus de Cloudflare se transfèrent aisément et lesquelles dépendent de systèmes internes.

La distinction entre les résultats confirmés et ceux needs-validation mérite une attention particulière. Si les utilisateurs externes transforment régulièrement des pistes non résolues en rapports affirmatifs, les garde-fous du workflow n’existeront que sur le papier.

Le troisième signal sera de voir si d’autres plateformes de sécurité adoptent une vérification tout aussi indépendante. Les outils de code IA sont déjà en concurrence sur la rapidité, le nombre de problèmes détectés et l’aide à la remédiation. Cloudflare déplace l’attention vers la traçabilité des preuves, les taux de rejet et la comptabilisation de la couverture.

Ce changement renforcerait l’impact plus large de la skill d’audit de sécurité Cloudflare, même si les développeurs n’installent jamais ce package précis. Un marché qui demande qui a vérifié un résultat est plus sain qu’un marché qui récompense le plus grand nombre d’alertes.

Les résultats internes de Cloudflare suggèrent pourquoi cela importe. Des milliers de candidats bruts ont disparu au cours de la validation, de la déduplication et de l’évaluation contextuelle. Générer davantage de candidats n’était pas la capacité rare. Les transformer en travail digne de confiance l’était.

Il existe aussi des signaux pratiques au sein de chaque organisation. Les responsables de la sécurité devraient suivre le nombre de résultats qui survivent à une revue indépendante, l’augmentation de la couverture lors d’exécutions répétées et le nombre de correctifs qui réussissent les tests de régression.

Ils devraient également consigner le coût des audits et le temps écoulé. Cloudflare indique que ses analyses internes complètes peuvent prendre des heures, sa plus longue exécution dépassant 14 heures. La skill publique peut consommer un temps de modèle important lorsque les chasseurs et les vérificateurs examinent des zones distinctes.

Cette dépense peut se justifier pour des dépôts sensibles ou des revues approfondies périodiques. Elle ne convient pas nécessairement à chaque pull request. Des contrôles plus légers, des règles déterministes et des revues de menaces ciblées restent mieux adaptés à un retour rapide.

La décision importante n’est pas de savoir s’il faut remplacer les scanners existants par une compétence d’agent. Il s’agit de déterminer où un audit d’agent fondé sur des preuves apporte des informations que les contrôles actuels ne détectent pas.

Les développeurs peuvent commencer par un dépôt aux limites clairement définies et une frontière de confiance explicitement établie. Ils devraient examiner le registre de couverture avant de lire le rapport final, puis confronter chaque problème confirmé au code source inchangé.

Ils devraient conserver les enregistrements non résolus plutôt que de forcer un verdict. Ils devraient exécuter les tests uniquement dans un environnement sandbox approprié et maintenir les décisions de remédiation sous contrôle humain.

Si ce processus produit des constats reproductibles que les mainteneurs acceptent, Cloudflare aura publié une méthode de sécurité significative. Si les utilisateurs le réduisent à un simple prompt généraliste, ses six phases ajouteront de la complexité sans inspirer davantage confiance.

La compétence d’audit de sécurité de Cloudflare lance donc un défi concret aux fournisseurs de sécurité IA et aux équipes d’ingénierie : cessez de mesurer la réussite au nombre de faiblesses qu’un modèle peut décrire. Mesurez plutôt quelles affirmations résistent à un examen contradictoire, quelles zones ont réellement été examinées et quels faits restent inconnus.