Rubrik Code Guardian étend Project Hourglass, mais ses promesses de sécurité doivent faire leurs preuves sur le terrain

Rubrik a présenté Rubrik Code Guardian le 9 octobre, étendant Project Hourglass au-delà des contrôles d’exécution afin d’inspecter les dépôts de code à la recherche de chaînes d’attaque exploitables. Selon l’entreprise, ce service en aperçu privé utilise un modèle d’Anthropic dans un environnement de test isolé. Il vise un conflit grandissant dans le développement logiciel : les outils de codage par IA augmentent la production, tandis que les équipes de sécurité peinent à l’examiner au même rythme.

Cette extension rapproche Rubrik de la sécurité des applications, un marché où les analyseurs signalent déjà le code vulnérable avant le déploiement. Rubrik avance une promesse différente. Au lieu de produire une nouvelle longue liste de défauts possibles, Code Guardian est conçu pour relier les faiblesses entre fichiers, services, identités et frontières cloud. Il priorise ensuite les chemins susceptibles d’entraîner des dommages significatifs pour l’entreprise.

Cette approche constitue aussi le test central de Project Hourglass. Un système d’IA peut raisonner à l’échelle d’un vaste dépôt, mais les entreprises ont toujours besoin de preuves que ses résultats sont exacts, reproductibles et plus sûrs que le code qu’il examine. Code Guardian n’est pas disponible de manière générale, et Rubrik précise explicitement que ses fonctionnalités et ses performances restent susceptibles d’évoluer.

Rubrik Code Guardian étend Project Hourglass à la base de code

Project Hourglass passe du contrôle des agents de codage à l’exécution à l’examen des logiciels que ces agents contribuent à produire.

Rubrik a initialement lancé Project Hourglass pour aider les intégrateurs mondiaux de systèmes à déployer Rubrik Agent Cloud autour de Claude Code d’Anthropic. Cette architecture initiale était centrée sur ce qu’un agent de codage IA fait pendant son fonctionnement.

Ses contrôles incluaient des garde-fous comportementaux, la protection du contexte des prompts et Agent Rewind. Rubrik décrit Agent Rewind comme un moyen d’annuler les actions non intentionnelles réalisées par un agent. Ces fonctions répondent au risque opérationnel lié à l’autorisation donnée à des agents logiciels de lire des fichiers, modifier des dépôts, appeler des outils et interagir avec les systèmes de l’entreprise.

Rubrik Code Guardian ajoute une deuxième couche. Il examine une copie clonée du dépôt de code source d’un client dans un environnement isolé physiquement, ce qui signifie que cette copie est séparée des systèmes de production et des réseaux externes. Rubrik affirme que cette conception permet aux équipes de mener des tests de sécurité offensifs sans exposer les applications actives ou le code source sensible à un risque opérationnel inutile.

Selon le communiqué sur Code Guardian de l’entreprise, le système utilise Claude Mythos 5 au moyen d’un harnais de sécurité spécialisé. Le modèle est destiné à raisonner sur des scénarios de menace en plusieurs étapes plutôt qu’à inspecter chaque fichier comme une unité indépendante.

Cette distinction est importante, car les vulnérabilités les plus dommageables émergent souvent de combinaisons de faiblesses par ailleurs modestes. Un service peut accepter des entrées non sûres, un rôle d’identité peut disposer de permissions excessives et une ressource cloud peut être accessible via un chemin négligé. Un outil conventionnel peut signaler chaque condition séparément sans montrer comment un attaquant les relierait.

Rubrik indique que Code Guardian examinera les fichiers source, les services, les rôles d’identité et les périmètres cloud afin d’identifier ces chaînes. Il testera ensuite si un chemin suspecté est réellement exploitable et évaluera le résultat selon son importance pour l’entreprise.

L’objectif n’est pas simplement de trouver davantage d’alertes. Il s’agit de réduire la fatigue liée aux alertes en aidant les équipes d’ingénierie à déterminer quels avertissements exigent une attention immédiate.

Cela marque un changement important dans le positionnement de Rubrik en matière de sécurité. L’entreprise a traditionnellement mis l’accent sur la résilience des données, les sauvegardes protégées et la récupération après les attaques. Code Guardian l’introduit plus tôt dans le cycle de vie logiciel, avant qu’une application vulnérable n’atteigne la production.

Project Hourglass devient également une alliance de déploiement plus large. AHEAD, Trace3 et World Wide Technology ont rejoint les participants existants Cognizant, Deloitte, LTM, HCLTech, NTT DATA et Wipro. Ces partenaires peuvent aider les entreprises à évaluer l’architecture, mener des tests contrôlés et intégrer la technologie aux processus existants de développement et de sécurité.

Rubrik a annoncé cette extension lors de son GSI Summit à Goa, en Inde. Le contexte géographique est moins important que le modèle de déploiement. Les grandes entreprises achètent souvent des programmes de sécurité par l’intermédiaire d’intégrateurs de systèmes, et non au travers d’essais isolés de produits gérés par une seule équipe de développement.

Les partenaires pourraient donc déterminer si Rubrik Code Guardian devient un contrôle opérationnel ou reste une démonstration intéressante en aperçu privé. Ils devront relier ses résultats aux systèmes de ticketing, aux chaînes logicielles, aux contrôles d’identité et aux outils existants de sécurité des applications.

Le statut d’aperçu privé impose une limite claire à cette annonce. Rubrik indique que le service est proposé à des partenaires de conception sélectionnés selon le principe du « tel quel ». Il n’est pas disponible de manière générale, et l’entreprise ne garantit pas que toutes les capacités décrites seront intégrées à une version commerciale.

Cette précision est au cœur du sujet. Rubrik a décrit une architecture ambitieuse, mais les clients ne peuvent pas encore l’évaluer au moyen de données de déploiement à grande échelle, de benchmarks indépendants ou d’une version de production stable.

Pourquoi la sécurité du code IA devient un goulot d’étranglement pour les entreprises

La pression provient d’un écart de vitesse grandissant entre la création automatisée de code et son examen humain du point de vue de la sécurité.

Les assistants de codage IA peuvent générer des fonctionnalités, des tests, des fichiers de configuration et du code d’infrastructure en quelques minutes. Cette vitesse change l’économie du développement, mais elle n’élimine pas le besoin de revue. Elle peut au contraire augmenter le volume de code que les équipes de sécurité doivent évaluer avant une version.

Le risque n’est pas que chaque fonction générée par IA comporte une vulnérabilité. Le problème est qu’un code plausible peut passer une revue visuelle rapide tout en conservant des hypothèses dangereuses sur les permissions, les entrées, les dépendances ou les frontières du système.

Une évaluation Veracode de 2025 a rapporté que les modèles testés avaient introduit une vulnérabilité détectable de l’OWASP Top 10 dans 45 % de ses résultats de tâches. L’étude sur la sécurité du code de l’entreprise s’appuyait sur des tâches de programmation contrôlées, dans lesquelles les implémentations pouvaient suivre des modèles sûrs ou non sûrs.

Ce chiffre ne doit pas être considéré comme le taux de vulnérabilité de l’ensemble des logiciels de production. Les tâches contrôlées diffèrent des dépôts d’entreprise maintenus, et les résultats dépendent du langage, du prompt, du modèle et de la méthode de test. L’étude illustre néanmoins pourquoi la justesse fonctionnelle ne peut pas remplacer la validation de sécurité.

Le risque s’étend également au-delà du code source généré. Les agents de codage peuvent accéder à des dépôts, des terminaux, des systèmes de suivi des problèmes, des gestionnaires de paquets et des outils de déploiement. Une instruction nuisible intégrée à un contenu récupéré peut rediriger un agent disposant de privilèges excessifs, tandis qu’une erreur ordinaire peut se propager à travers de nombreux fichiers.

OWASP décrit l’autonomie excessive comme une situation dans laquelle un modèle reçoit des fonctionnalités, des permissions ou une autonomie inutiles. Ses recommandations sur l’autonomie excessive préconisent de limiter l’accès aux outils, de minimiser les permissions, d’exiger une approbation pour les actions importantes et de valider les sorties avant leur exécution.

Ces contrôles portent sur ce qu’un agent est autorisé à faire. Code Guardian répond à une question liée mais distincte : quelles faiblesses de sécurité existent dans la base de code après les contributions humaines et celles des agents ?

Rubrik cite ses propres recherches Zero Labs pour expliquer l’urgence. L’entreprise affirme que 86 % des dirigeants interrogés en cybersécurité et informatique s’attendent à ce que l’adoption des agents IA dépasse les garde-fous de sécurité de leurs organisations dans l’année à venir. Comme ce chiffre provient des recherches de Rubrik, les lecteurs devraient le considérer comme un indicateur de préoccupation des clients plutôt que comme une preuve indépendante de l’efficacité de Code Guardian.

La préoccupation plus large est bien établie. Les agents autonomes peuvent fonctionner avec des identités machine, des identifiants et des permissions d’outils. Ils peuvent également effectuer des séquences d’actions plus rapidement qu’une personne ne peut examiner chaque étape.

Le dépôt logiciel ne constitue donc qu’une partie de la surface d’attaque. Les équipes de sécurité doivent protéger le contexte du modèle, les permissions de l’agent, le code généré, la chaîne de déploiement et les données affectées par une action défaillante.

Project Hourglass tente désormais de couvrir plusieurs de ces couches. Rubrik Agent Cloud se concentre sur le comportement et la récupération des agents. Code Guardian se concentre sur l’analyse des dépôts et la découverte des chaînes d’attaque. Les produits existants de résilience de Rubrik fournissent la couche de récupération si la prévention et les contrôles d’exécution échouent.

Ce positionnement de bout en bout est commercialement attrayant, mais il soulève également des questions d’intégration. Les entreprises utilisent déjà des tests statiques de sécurité des applications, l’analyse de la composition logicielle, la détection de secrets, des outils de posture de sécurité cloud et des tests d’intrusion manuels.

Code Guardian doit démontrer qu’il apporte quelque chose que ces produits ne peuvent pas fournir efficacement. Trouver une faiblesse hypothétique ne suffit pas. Le service doit expliquer comment un attaquant y accède, quels actifs deviennent exposés et pourquoi ce résultat devrait être prioritaire par rapport à d’autres travaux de remédiation.

C’est là que la sécurité du code IA devient un problème de priorisation. Un analyseur qui double le nombre d’alertes sans améliorer les décisions peut ralentir un programme de sécurité. Un système de raisonnement efficace doit réduire l’incertitude, et non simplement produire des rapports plus longs.

Pour les responsables de l’ingénierie, la leçon immédiate est pratique. Une génération de code plus rapide exige des contrôles plus solides aux niveaux du dépôt, de l’identité et de l’exécution. Les équipes ont également besoin de traces durables des décisions architecturales, des hypothèses de menace et des travaux de remédiation.

Une base de connaissances d’ingénierie consultable peut préserver ce contexte entre les équipes de sécurité, de développement et d’exploitation. Elle ne remplace pas les tests de code, mais elle aide les réviseurs à comprendre pourquoi des composants sensibles ont été conçus d’une manière particulière.

Project Hourglass oppose le raisonnement sur les chaînes d’attaque au volume d’alertes

Le principal pari de Rubrik est que l’IA peut prioriser les chemins d’attaque réalistes mieux que les outils qui examinent les faiblesses de manière isolée.

L’analyse statique traditionnelle évalue le code source sans exécuter l’application. Elle peut identifier des schémas non sûrs connus, tels que des entrées non assainies, des appels de fonctions dangereux ou de mauvais choix cryptographiques. L’analyse de la composition logicielle examine les paquets externes et les vulnérabilités connues dans les dépendances.

Ces méthodes restent essentielles, car elles sont reproductibles, familières et adaptées aux chaînes de développement automatisées. Elles peuvent toutefois générer des faux positifs ou des résultats isolés dépourvus de contexte métier.

Un avertissement dans un composant de test inaccessible ne présente pas le même risque qu’une faille exploitable dans un service d’authentification exposé sur Internet. Pourtant, les deux peuvent apparaître dans la même file d’attente à moins qu’une personne ou un autre système ne reconstitue l’architecture environnante.

Rubrik Code Guardian est conçu pour effectuer une plus grande part de cette reconstitution. L’entreprise affirme que son modèle peut raisonner à travers les fichiers et les services, inclure les relations d’identité et prendre en compte les frontières cloud. Le résultat attendu est censé décrire une chaîne d’attaque plutôt qu’un défaut isolé.

Considérons une application d’entreprise hypothétique présentant trois faiblesses. Une API accepte un paramètre insuffisamment validé. Une identité de service peut lire un compartiment de stockage sensible. Un worker d’arrière-plan fait confiance aux messages provenant de l’API.

Un scanner au niveau des fichiers pourrait générer trois tickets. L’analyse des chaînes d’attaque se demanderait si un attaquant peut exploiter la faille de paramètre pour contrôler un message, déclencher le worker, hériter de l’identité de service et atteindre le compartiment de stockage. Si cette séquence fonctionne dans la copie isolée, l’équipe de sécurité obtient une priorité de remédiation plus claire.

C’est le mécanisme qui sous-tend l’affirmation de Rubrik concernant l’impact métier. Le modèle n’est pas utile simplement parce qu’il peut lire davantage de code. Il le devient s’il peut distinguer une chaîne plausible d’une combinaison théorique et expliquer sa conclusion aux examinateurs humains.

Anthropic a déjà présenté la découverte de vulnérabilités assistée par modèle comme un usage défensif de modèles avancés de programmation. En février 2026, l’entreprise a déclaré que Claude Code Security avait identifié plus de 500 vulnérabilités dans des projets open source en production. Son annonce sur la recherche en sécurité décrivait un processus combinant l’analyse par modèle, l’examen humain et une divulgation coordonnée.

Anthropic a également publié un tableau de bord des vulnérabilités qui recense les résultats après triage externe et examen par les mainteneurs. Ce flux de travail est important, car la suspicion initiale d’un modèle n’équivaut pas à une vulnérabilité confirmée.

Rubrik transpose cette capacité générale dans un environnement d’entreprise contrôlé. Au lieu d’analyser des dépôts open source publics, Code Guardian est conçu pour examiner le code privé des clients via des partenaires participants.

Le clone isolé du réseau offre deux avantages potentiels. Premièrement, il peut réduire le risque que du code propriétaire fuite vers un service externe ou atteigne un système de production en direct. Deuxièmement, il permet au processus de test d’explorer agressivement sans affecter les clients ni les opérations.

L’isolation ne résout pas toutes les questions de sécurité. Les entreprises auront toujours besoin de précisions sur la façon dont les copies de dépôts sont créées, le lieu où l’inférence du modèle s’exécute, la manière dont les résultats sont conservés et les membres du personnel des partenaires qui peuvent accéder aux conclusions.

Le terme « air-gapped » peut aussi recouvrir différents agencements techniques. Un environnement physiquement séparé, un cloud privé fortement restreint et un réseau logiquement isolé n’offrent pas les mêmes garanties. L’annonce publique de Rubrik ne fournit pas assez de détails architecturaux pour comparer ces modèles.

Le test concurrentiel portera sur la qualité des preuves. Les fournisseurs établis de sécurité applicative peuvent ajouter des explications par IA et une hiérarchisation contextuelle à leurs scanners existants. Les fournisseurs de sécurité cloud peuvent corréler identités, services et actifs accessibles à l’aide de télémétrie de production.

Rubrik apporte des atouts différents. L’entreprise entretient des relations autour des données d’entreprise protégées, des flux de travail de récupération et de la cyberrésilience. Project Hourglass lui apporte également des partenaires intégrateurs capables de relier l’analyse de code à des décisions d’infrastructure plus larges.

La version la plus forte de la stratégie de Rubrik combine ces atouts. Code Guardian identifierait la chaîne, Agent Cloud encadrerait le comportement des agents, et les contrôles de récupération de Rubrik restaureraient le code ou les données affectés après un incident.

La version plus faible crée une console de plus avec des alertes qui se chevauchent. Les clients de l’aperçu privé devront déterminer quel scénario ils observent.

La partie difficile consiste à valider l’examinateur IA

Un système d’IA qui examine du code assisté par IA crée une boucle de vérification qui ne peut pas être résolue par la seule confiance du modèle.

Rubrik affirme que Code Guardian vérifiera si les résultats sont réellement exploitables. C’est une affirmation plus exigeante que l’identification de schémas suspects. L’exploitabilité dépend de la configuration, de l’état du déploiement, des entrées accessibles, des autorisations d’identité et des contrôles environnementaux.

Un dépôt cloné peut ne pas contenir tous les éléments nécessaires pour reproduire l’environnement de production. Les paramètres d’infrastructure peuvent résider dans des systèmes distincts. Les identités d’exécution peuvent différer des rôles déclarés. Les politiques réseau peuvent changer après la création du clone.

Cela signifie que le chemin d’attaque du système peut être logiquement cohérent tout en restant impossible en production. Le problème inverse existe également. Un test centré sur le dépôt peut manquer un chemin dangereux créé par une dérive d’exécution, une intégration non documentée ou un identifiant compromis.

Les essais en aperçu privé devraient donc mesurer davantage que le nombre de problèmes détectés. Ils devraient suivre les chaînes exploitables confirmées, les résultats rejetés, les alertes en double, le délai de validation, le délai de remédiation et les défauts manqués par le système.

Une comparaison indépendante sera particulièrement importante. Un partenaire de conception devrait exécuter Code Guardian aux côtés de ses scanners existants et de son processus de tests d’intrusion. Cela crée une référence permettant de déterminer si le service découvre des risques uniques ou reconditionne des résultats connus.

Les équipes de sécurité ont également besoin de preuves reproductibles. Un rapport utile devrait identifier les chemins de code concernés, les autorisations requises, les conditions préalables, les actifs affectés et les étapes utilisées pour valider la chaîne. Les examinateurs doivent pouvoir contester le raisonnement du modèle sans accepter un score de risque opaque.

Rubrik n’a pas publié de résultats de référence concernant les taux de faux positifs, les taux de faux négatifs, la couverture des dépôts, le temps d’analyse ou les classes de vulnérabilités. Son annonce ne précise pas non plus comment les performances évoluent avec de grands monodépôts ou des langages de programmation peu courants.

Ces omissions sont raisonnables pour un aperçu précoce, mais elles limitent les conclusions que les entreprises peuvent tirer. Code Guardian est un contrôle de sécurité proposé, et non un remplacement des tests de sécurité applicative existants validé de manière indépendante.

Le modèle sous-jacent crée un autre risque de concentration. Rubrik s’appuie sur la technologie d’Anthropic pour inspecter du code pouvant avoir été créé avec Claude Code ou d’autres assistants IA. Un modèle compétent peut néanmoins partager des angles morts avec les systèmes qui ont généré le code.

La diversité des modèles ne résout pas automatiquement ce problème, mais des méthodes de test indépendantes peuvent aider. Les scanners déterministes, les testeurs d’intrusion humains, les observations à l’exécution et des modèles distincts peuvent chacun remettre en question différentes hypothèses.

Le cadre de sécurité des agents plus large d’OWASP considère les systèmes agentiques comme des combinaisons de modèles, d’outils, d’identités, de mémoire et de services externes. Cette perspective plaide contre le recours à un seul examinateur automatisé.

Il existe aussi un enjeu de gouvernance. Un modèle ne peut signaler un chemin comme critique pour l’activité que s’il reçoit des informations exactes sur son importance métier. Le dépôt seul peut ne pas révéler quel service traite des données réglementées, soutient un client majeur ou contrôle un flux opérationnel essentiel.

Les partenaires devront fournir ce contexte. Cela exige une coopération entre les responsables applicatifs, les équipes de sécurité, les administrateurs cloud, les équipes d’identité et les dirigeants métier.

Les intégrateurs de systèmes peuvent coordonner ces groupes, ce qui aide à expliquer la stratégie de Rubrik privilégiant les alliances. Toutefois, une prestation pilotée par des partenaires peut produire des résultats inégaux si les pratiques de mise en œuvre diffèrent. La certification et le soutien direct de l’ingénierie peuvent réduire cette variation, mais Rubrik n’a pas encore publié de données sur les résultats opérationnels.

Le positionnement de l’entreprise en matière de récupération mérite également un examen attentif. La récupération instantanée d’une base de code peut restaurer des fichiers connus comme sains après une modification involontaire, mais restaurer le code n’inverse pas automatiquement toutes les conséquences.

Un agent compromis pourrait exposer un secret, déclencher une transaction externe, modifier un système tiers ou altérer des données de production. Ces effets nécessitent une réponse à incident allant au-delà d’un retour en arrière du dépôt.

Project Hourglass devrait donc être évalué comme un contrôle par couches, et non comme une garantie. Les garde-fous peuvent réduire les actions dangereuses. Les tests de code peuvent détecter des chemins vulnérables. La récupération peut limiter les dégâts. Aucun de ces éléments n’élimine le besoin d’un accès au moindre privilège, d’une approbation humaine, de pratiques de développement sécurisées et d’une planification des incidents.

C’est le compromis central. Le raisonnement par IA peut examiner des relations que les outils fondés sur des règles peinent à relier, mais ce raisonnement exige lui-même une validation. Les entreprises ne gagnent en vitesse que lorsque la charge de vérification devient inférieure au problème automatisé.

Rubrik Code Guardian doit désormais réussir trois tests

Les prochaines preuves devront venir des résultats de déploiement, de comparaisons indépendantes et d’une architecture de production clairement définie.

Le premier signal sera la qualité des résultats obtenus par les partenaires de conception. AHEAD, Trace3, WWT et les participants existants de Project Hourglass ont accès à des entreprises disposant de dépôts complexes et de programmes de sécurité matures.

Les résultats les plus utiles ne seront pas des déclarations promotionnelles sur la détection de « davantage » de risques. Les acheteurs ont besoin d’exemples anonymisés montrant quelles chaînes d’attaque les outils existants ont manquées, comment Code Guardian les a validées et à quelle vitesse les équipes ont achevé la remédiation.

Des résultats confirmés renforceraient l’argument de Rubrik selon lequel le raisonnement fondé sur les modèles améliore la priorisation. Des taux de rejet élevés ou de lourdes charges d’examen l’affaibliraient.

Le deuxième signal est le passage de l’aperçu privé à la disponibilité générale. La version actuelle de Rubrik inclut un avertissement explicite selon lequel Code Guardian peut évoluer, arriver tardivement ou ne jamais devenir généralement disponible.

Une version de production devrait clarifier les langages pris en charge, les limites de taille des dépôts, les modèles de déploiement, le traitement des données, les politiques de mise à jour des modèles, les contrôles de conservation et l’intégration aux pipelines de développement. Elle devrait également expliquer comment les clients auditent les actions effectuées pendant les tests.

La disponibilité générale ne prouverait pas à elle seule l’efficacité. Toutefois, une documentation stable et des engagements contractuels de sécurité montreraient que Rubrik est prêt à dépasser le stade de l’expérience contrôlée.

Le troisième signal est la réponse concurrentielle. Les fournisseurs de sécurité applicative et de sécurité cloud possèdent déjà des scanners de code, des bases de données de vulnérabilités, des renseignements sur les dépendances et un contexte de production. Ils ont des incitations évidentes à ajouter une analyse agentique des chaînes d’attaque.

Si ces fournisseurs produisent un raisonnement comparable via des outils que les clients utilisent déjà, Rubrik devra se différencier par la récupération, l’isolation ou la prestation par les partenaires. Si les concurrents peinent à corréler le code avec l’identité et l’impact métier, Project Hourglass bénéficie d’une ouverture plus forte.

Les propres produits de sécurité d’Anthropic constituent un autre point de référence. Claude Code Security démontre que le fournisseur de modèles considère la découverte de vulnérabilités comme une catégorie de produit à part entière. Rubrik doit expliquer comment son environnement de sécurité, son contexte d’entreprise et son architecture de récupération apportent une valeur au-delà de l’accès au modèle sous-jacent.

Les développeurs et les acheteurs d’entreprise devraient surveiller ces signaux avant de considérer Rubrik Code Guardian comme un contrôle établi. L’annonce identifie un problème réel et propose un mécanisme crédible, mais les preuves restent préliminaires.

Pour les équipes de développement, la réponse pratique ne devrait pas attendre la sortie d’un fournisseur. Inventoriez les endroits où opèrent les agents de programmation, restreignez leurs identifiants, consignez les changements importants et conservez une approbation humaine pour les actions sensibles. Continuez à utiliser des scanners déterministes et des tests indépendants, même lorsqu’un examinateur IA est disponible.

Les responsables de la sécurité devraient également poser une question plus difficile : un nouvel outil raccourcit-il le chemin entre la détection et une remédiation vérifiée ? Un système qui découvre des chaînes sophistiquées mais submerge les examinateurs ne résout pas le goulot d’étranglement opérationnel.

Rubrik Code Guardian sera important si Project Hourglass transforme le raisonnement par modèle en preuves reproductibles sur lesquelles les ingénieurs peuvent agir. Son aperçu privé marque le début de ce test, pas son résultat. Au cours des prochains mois, les acheteurs devraient rechercher des chaînes d’attaque validées, des taux d’erreur transparents et une architecture de production qui protège le code inspecté.