Comment Figma garde une longueur d'avance sur les vulnérabilités grâce à des agents

Orienter les agents de codage vers la base de code et leur demander d'identifier les vulnérabilités est simple. Obtenir la précision et le rappel dont une organisation a besoin reste une ingénierie difficile : combien de résultats sont légitimes et combien de bugs réels le système détecte-t-il ?

Cette publication explique comment nous abordons la précision, le rappel et la confiance lorsqu'il s'agit de gérer la sécurité agentique pour le code source de Figma. Nous utilisons des agents pour prévenir, détecter et corriger les vulnérabilités à trois étapes : la génération de code, l'examen des demandes d'extraction et l'audit du code historique.

Nous présenterons les enseignements tirés de ces différentes étapes, en consacrant l'essentiel de notre temps à l'examen des demandes d'extraction – la première fonctionnalité que nous avons développée, qui a rendu possibles la génération sécurisée de code et l'audit, en nous aidant à élaborer et à améliorer automatiquement la politique suivie par tous nos agents de sécurité.

Examen sécurisé du code

Nous avons commencé par la phase d'examen, car sa boucle d'amélioration est plus rapide que celles de la génération ou de l'audit. Trois propriétés permettent à cette boucle de fonctionner :

1. Elle est universelle : chaque demande d'extraction y passe.
2. Elle est en libre-service : le réviseur fait un commentaire sur la demande d'extraction et l'auteur y répond directement.
3. Elle est instrumentée dans les deux sens : la précision et le rappel ont chacun leur propre signal.

L'indicateur de précision correspond à la note de l'auteur : sur les quelques demandes d'extraction qui mettent en évidence une découverte, l'auteur valide ou rejette celle-ci, généralement en précisant la raison de son choix. Pour mesurer le taux de rappel, nous soumettons l'examinateur à des validations dont nous savons déjà qu'elles contenaient des bugs et nous comptons ceux qu'il a manqués.

Nous exécutons actuellement Claude Code avec Opus 4.8 selon le paramètre d'effort très élevé (xhigh) et Codex avec GPT-5.6 Sol à fort effort, car ils manquent des bugs différents. Si l'un ou l'autre des modèles met en évidence une anomalie, nous la faisons remonter.

Certaines des vulnérabilités que notre réviseur détecte impliquent des chaînes complexes multi-étapes. Dans une demande d'extraction récente, il a constaté qu'un objet sandbox injecté divulguait le constructeur Function du domaine hôte, ouvrant une voie à l'exécution de code sur le client de bureau.

La plupart des éléments qu'il détecte sont plus ordinaires, mais valent toujours la peine d'être corrigés. Par exemple, dans une autre demande d'extraction récente, le réviseur a signalé une extrémité qui retournait une facture à partir d'un identifiant fourni par l'appelant, sans vérifier si cette facture appartenait bien à l'organisation de ce dernier ; autrement dit, tout utilisateur authentifié pouvait consulter les factures d'une autre organisation simplement en connaissant l'identifiant. Voici une version très simplifiée de la découverte :

Comment nous avons commencé

En août 2025, Anthropic a publié l'examinateur de la sécurité Claude Code ; nous l'avons déployé le jour de l'expédition, mais en mode « shadow » : les résultats étaient donc envoyés vers Slack et Datadog, et non dans les commentaires de demande d'extraction. Il s'agissait d'un outil d'examen en deux passes assez classique, qui commençait par identifier des vulnérabilités potentielles avant d'éliminer les faux positifs par une approche contradictoire. Nous avons constaté qu'en le testant sur des incidents réels, il permettait d'identifier la cause première exacte avec un minimum de réglages et s'avérait efficace dans des domaines variés, allant de la sécurité des applications aux erreurs de configuration de l'infrastructure.

Cependant, lors de la première semaine, environ 15 % des résultats (4 sur 27) étaient valides. C'est le problème de confiance sous-jacent à l'argument d'OpenAI selon lequel la précision compte plus que le rappel : les développeurs cessent de faire confiance à un outil qui les submerge de résultats de piètre qualité. La précision devait passer en premier, ce qui n'est pas l'ordre auquel vous pourriez vous attendre. Vous pourriez penser que les bugs déjà identifiés nous donnaient une longueur d'avance considérable, mais une fois réutilisés comme tests d'évaluation, ils ne mesuraient que le rappel, et n'ont donc en rien contribué à la précision dont nous avions besoin en priorité.

Nous avons retenu les commentaires sur les demandes d'extraction destinés aux développeurs jusqu'à ce que la précision se maintienne au-dessus de 70 % sur une période d'observation de deux semaines, sans aucun faux positif particulièrement gênant. Pour atteindre ce niveau d'exigence, nous avons réévalué les résultats de l'examinateur sur les demandes d'extraction des huit semaines précédentes et avons nous-mêmes étiqueté manuellement les faux positifs en tant qu'équipe de sécurité. De là, nous avons rédigé la politique que l'agent devait suivre.

Selon les bonnes pratiques en matière de rédaction de prompts, la politique se compose de précédents plutôt que de règles. Par exemple, au lieu de « ne pas signaler d'injection SQL dans dbops », nous écrivons quelque chose comme « dbops n'est exécuté que par des opérateurs hautement privilégiés disposant déjà d'un accès direct à la base de données ».

99 lignes, 2 560 mots et 68 précédents plus tard, ce travail eut un effet secondaire que nous n'avions pas prévu : nous avions rédigé un modèle de menace complet, sous une forme sensiblement identique à celle que nous voudrions voir lue par une nouvelle recrue dès son premier jour. La politique est le modèle de menace. Les agents ont besoin d'un contexte de sécurité sous un format explicite et structuré et à une résolution exceptionnellement élevée. Au cours de la première décennie de Figma, ce contexte s'est accumulé à travers la documentation, les enseignements retirés des incidents et une connaissance institutionnelle approfondie. Il n'avait pas encore été consolidé à la résolution qu'un agent nécessite. Cet artefact est la véritable récompense. La génération de code sécurisé et l'audit à l'échelle du référentiel fonctionnant sur le même modèle de menace, nous n'avons jamais eu besoin de le concevoir deux fois.

Du prototype à l'infrastructure de production

Dans le mois suivant le lancement, l'ajustement de la politique a porté la précision à 80 % sur une fenêtre d'observation de deux semaines, dépassant largement notre seuil de 70 %. À ce stade, nous avons activé les commentaires destinés aux développeurs. Le taux de précision a continué à s'améliorer globalement, ce qui nous a permis d'imposer une règle selon laquelle aucune demande d'extraction ne peut être validée sans avoir fait l'objet d'une revue complète.

Puis vint la partie peu reluisante. Faire de la relecture une condition préalable à la fusion a transformé cette pratique : d'un simple « plus » appréciable, elle est devenue un élément d'infrastructure – et pour qu'une infrastructure inspire confiance, elle doit être ennuyeuse. Nous avons ajouté des mécanismes de basculement entre fournisseurs ainsi que des politiques de nouvelle tentative, afin qu'une panne chez un fournisseur de modèles ne permette pas à une demande d'extraction de passer sans avoir été examinée. Nous avons ajouté la télémétrie à Datadog et Slack car nous devions savoir à quel moment la précision ou le rappel se dégradaient. Nous avons également ajouté le suivi du taux de correction, car notre objectif ultime est de corriger les vulnérabilités, pas de veiller à ce qu'elles soient relevées.

En décembre 2025, nous avions dépassé les limites de l'action GitHub d'Anthropic et reconçu notre système autour d'elle de trois manières différentes :

• Nous avons déplacé l'examinateur dans un service TypeScript. Notre fork de l'action convenait pour un prototype, mais il s'est rapidement transformé en un workflow GitHub gigantesque et difficile à gérer. Nous l'avons intégré à un petit service TypeScript, ce qui a rendu le système d'examen plus facile à observer et à faire évoluer. Cela nous permet également d'exécuter Claude Code et Codex de manière indépendante et de réessayer en cas d'échec.
• Nous avons retiré la majeure partie du prompt. Les agents et les modèles se sont beaucoup améliorés dans la gestion du contexte et l'extraction de contextes longs. Nous avons conclu que l'examinateur n'avait pas du tout besoin d'une étape contradictoire distincte et avons intégré le filtrage dans un seul et même prompt. Il n'est pas non plus nécessaire d'apprendre aux modèles de pointe les plus récents comment détecter une vulnérabilité, ni de leur rappeler le classement OWASP Top 10.
• Ajout d'un arbitre. L'examinateur passait systématiquement à côté de bugs réels ; l'analyse des données d'évaluation révélait un schéma récurrent : dans sa quête de précision, l'agent finissait par écarter des résultats valides en les attribuant à un « modèle préexistant », à une « faible confiance » ou à de la « plomberie préparatoire » La première passe produisant déjà, sous forme de sortie structurée, les candidats qu'elle a écartés, nous avons ajouté une seconde passe qui réexamine ces rejets à la limite. Lors de nos évaluations utilisant des validations connues comme défectueuses, l'arbitrage a augmenté le rappel du taux de réussite d'environ 30 % en valeur relative.

Indicateurs

Nous étions convaincus de la précision de l'examinateur, et les tests rétrospectifs laissaient également entrevoir un bon taux de rappel. L'étape suivante a consisté à consolider la manière dont nous mesurions et améliorions le rappel, la précision et le taux de correction.

Mesurer le rappel avec des évaluations

Nous mesurons le rappel à l'aide d'un cadre d'évaluation polyvalent. Comme cette mesure porte sur des failles de sécurité connues, et non sur des menaces émergentes ou inconnues, nous la considérons comme un seuil minimal que l'agent doit atteindre, plutôt que comme une preuve de couverture.

Ce cadre s'appuie sur un corpus croissant de 66 tâches, chacune correspondant à une vulnérabilité réelle ayant échappé à la vérification humaine pour s'introduire dans la base de code, avant d'être finalement révélée par un programme de prime aux bugs, un incident ou un audit. 46 de ces 66 signalements proviennent de notre programme de prime aux bugs sur HackerOne (dont 24 issus d'un seul chercheur de premier plan), tandis que les 20 autres sont issus d'incidents et d'audits internes.

Chaque tâche est représentée par un petit fichier YAML contenant la validation à l'origine du problème, une description de la vulnérabilité, un score de pondération ainsi que des étiquettes (source de détection, canal d'incident ou chercheur).

# evals/pr-review/doc-export-idor.yaml
name: "doc-export-idor"
tags: ["authz", "bug-bounty"]
score: 10000

commit: "<root-cause-commit-sha>"

description: >
  A document export endpoint trusts a document id from the request and returns
  the file without checking whether the caller may access it. Any authenticated user
  can export another user's private document.

Le cadre vérifie chaque validation dans son propre arbre de travail Git isolé pour une analyse en environnement contrôlé, exécute l'examinateur et évalue les résultats obtenus. L'évaluateur de tâches est un système simple de type « LLM-juge » qui se concentre sur la description, vérifiant si le résultat de l'examinateur porte sur le même problème (même s'il est décrit différemment).

Nous utilisons deux types de systèmes de notation :

• Le calcul du taux de réussite indique le pourcentage de tâches réussies, fournissant ainsi une base de référence pour la prise en compte des bugs connus.
• Le score basé sur le taux de réussite indique le pourcentage de tâches réussies, fournissant ainsi une référence de couverture pour les bugs connus. Cela nous indique où nous en sommes concernant les bugs les plus critiques, qui ont tendance à se concentrer au sein de quelques classes à forte valeur.

Gardez à l'esprit que chaque tâche du corpus correspond à un bug qui a échappé à notre processus d'examen historique, lequel combine intervention humaine et analyse statique (SAST). Ainsi, un taux de capture syndiqué de 75,8 % correspond à 75,8 % des bugs qui ont réussi à passer outre nos contrôles existants. Voici à quoi ressemblent ces indicateurs avec les modèles de pointe les plus récents :

Chaque changement de politique est examiné par un ingénieur en sécurité et testé de nouveau sur l'ensemble du corpus avant d'être déployé. Cette approche permet de détecter les régressions liées aux bugs déjà connus, mais ne nous apprend rien sur ceux que nous n'avons pas encore découverts.

La valeur de la politique

Pour évaluer la valeur de l'ingénierie par rapport au modèle brut, nous avons exécuté le même examinateur Claude Code en supprimant entièrement notre politique Figma : nous n'avons conservé que la consigne « trouver des vulnérabilités », le modèle et les outils. Cela a tout de même permis de valider 44,4 % du corpus en termes de pondération des paiements.

Bien qu'un modèle de pointe parvienne à identifier de nombreuses vulnérabilités sans aucune aide, notre politique constitue tout de même un avantage considérable. Si nous réappliquons notre politique, le taux de ce même examinateur unique passe de 44,4 % à 64,2 %. C'est au niveau de la précision que l'écart est le plus marqué : en l'absence d'exclusions sur lesquelles s'appuyer, le prompt vide signale tout schéma suspect. Il est impossible de chiffrer cela à partir de cette exécution, car le corpus ne contient que de vrais positifs et ne mesure que le rappel ; toutefois, quiconque a lancé un agent de codage sur son propre référentiel a pu constater exactement ce phénomène.

Mesurer la précision grâce au feedback humain

Le signal de précision ne peut pas provenir du corpus d'évaluation, qui ne contient que des vrais positifs ; il n'apparaît que sur les demandes d'extraction en conditions réelles. Nous avons effectué un étiquetage manuel pour amorcer le processus, mais nous ne pouvons pas continuer à le refaire. Les résultats concrets étant rares, disposer d'une mesure de précision hors ligne permanente impliquerait d'examiner un nombre de demandes d'extraction bien supérieur à ce que nous pourrions vérifier manuellement simplement pour recueillir suffisamment de données exploitables, puis de réitérer cette opération après chaque modification de politique, puisque toute mesure visant à accroître le rappel est susceptible d'affecter également la précision. Nous mesurons donc la précision en production.

L'examinateur s'exécute déjà sur chaque demande d'extraction et l'auteur connaît mieux ses modifications qu'un ingénieur en sécurité qui les découvre ; c'est donc à lui qu'il revient de se prononcer en premier sur chaque résultat, bien que cette décision ne soit pas définitive. Un agent distinct réexamine périodiquement le code à l'origine des résultats récents ; tout cas contesté ou non traité, dont le modèle signalé est toujours présent, est transmis à l'équipe de garde chargée de la sécurité pour décision. Parce que les résultats concrets sont rares, les auteurs de demande d'extraction ne les rencontrent qu'occasionnellement.

Avec Opus 4.7, nous avons maintenu une période prolongée sans aucun résultat contesté, de fin avril à fin mai 2026. La précision a légèrement baissé lors du passage à Opus 4.8, mais nous estimons qu'il s'agit d'un compromis acceptable au regard de l'amélioration du taux de rappel, obtenue en traquant des chaînes d'exploitation plus complexes et en plusieurs étapes.

Mesurer les taux de correction

Rien de tout cela n'ayant d'importance si les bugs ne sont jamais corrigés, nous suivons les taux de correction avant la fusion, un second agent étiquetant chaque anomalie comme corrigée, contestée, reconnue, non traitée ou encore en attente. Améliorer cet indicateur nécessite une certaine dose d'ingénierie sociale, car un résultat concret et bien rédigé reste en concurrence avec toutes les autres tâches qui incombent au développeur. Nous avons envisagé de bloquer systématiquement les fusions en présence d'une anomalie non résolue, mais nous avons finalement décidé de ne pas le faire, car les changements légers suivants ont considérablement amélioré notre taux de correction sans nous imposer cette lourde contrainte opérationnelle.

Tout d'abord, nous avons remplacé le pied de page des commentaires, qui affichait timidement « Des questions ? Posez-les sur #security. Faux positif ? Cliquez sur 👎 et fermez. Désolés pour le dérangement. » par un message (littéralement) plus audacieux 🎯« Nous les ajustons pour garantir une haute pertinence des signaux grâce à des évaluations et au feedback humain. Merci de traiter ce résultat. Cliquez 👎 sur les faux positifs pour nous aider à maintenir cette qualité. Des questions ? #sécurité. »

Deuxièmement, nous avons limité le format de sortie à un résultat en une seule phrase, aux étapes numérotées de l'exploitation, à une brève recommandation et aux liens vers le code pertinent. Cela met fin à la tendance des modèles Opus 4.5+ à produire des blocs de texte interminables.

Comment nous améliorons l'agent

Nous disposons de deux types de boucles d'auto-amélioration pour l'agent, l'une pour le rappel et l'autre pour la précision. Les deux renforcent notre politique afin que nous évitions de répéter les mêmes erreurs à l'avenir.

Rappel : remédier aux angles morts du système

Imaginons que l'un de nos chercheurs de prime aux bugs sur HackerOne découvre une vulnérabilité dans Figma et la signale. Voici la boucle :

1. Un agent cloud récupère le rapport et le trie.
2. L'agent écarte les rapports de faible qualité (environ 75 % des soumissions) et identifie celui-ci comme étant différent : une rare chaîne d'exploitation. Notez que le monorepo rend la validation gérable pour l'agent, car toute la logique de notre application y est centralisée. Nous estimons que la lecture du code suffit amplement pour valider une vulnérabilité signalée de l'extérieur – la génération d'un exploit est inutile.
3. L'agent écrit un correctif et ouvre une demande d'extraction. L'équipe de garde chargée de la sécurité examine le correctif et l'intègre.
4. L'agent remonte la vulnérabilité jusqu'à la validation qui l'a introduite et ajoute cette validation à notre corpus d'évaluation.
5. Un second agent exécute notre examinateur de demande d'extraction sur cette validation à l'origine du problème.
6. Si l'examinateur ne repère pas le bug, le deuxième agent lit les transcriptions des échanges avec l'évaluateur, détermine pourquoi il a manqué le bug (Le fichier a-t-il même été lu ? Lu mais non signalé ? Signalé mais exclu ?), met à jour la politique jusqu'à ce que l'examinateur détecte le bug, et ouvre une demande d'extraction avec le changement.
7. L'équipe de garde chargée de la sécurité examine la modification de la politique et procède à des ajustements, si nécessaire.

Le correctif résout ce bug. La mise à jour de la politique est plus importante, car elle permet à l'examinateur de détecter tout futur bug de ce type lors de l'examen de la demande d'extraction. C'est ainsi que nous améliorons automatiquement le rappel.

Nous faisons appel à des humains à plusieurs étapes de ce processus, car nous souhaitons toujours conserver un jugement humain sur les données que nous fusionnons, en particulier si le bug a été signalé par un chercheur externe. Par ailleurs, l'affinement automatisé des politiques peut encore sur-apprendre (« Goodhart ») à partir de l'unique bug auquel il est confronté, ou produire un amendement verbeux qu'aucun humain ne souhaite lire.

Précision : réduire l'apparition de faux positifs

Si l'auteur d'une demande d'extraction rejette un commentaire en le qualifiant de faux positif – que ce soit par une réaction « pouce vers le bas », un commentaire expliquant pourquoi ou les deux, nous exécutons une version simplifiée de la boucle précédente :

1. Une compétence d'agent s'exécute et met à jour la politique afin que ce type de faux positif ne se reproduise plus. Il prend en compte le feedback des développeurs et examine les transcriptions des échanges pour comprendre pourquoi le modèle a commis l'erreur.
2. L'équipe de garde chargée de la sécurité examine la modification de la politique et procède à des ajustements, si nécessaire.
3. Nous exécutons l'examinateur sur le corpus de référence avec la politique mise à jour.

Audit de code sécurisé

Les audits reposent exactement sur la même politique que celle que nous avons élaborée pour l'examen des demandes d'extraction. Le modèle de menace que nous avons dû formaliser pour rendre l'examen précis – et qui est continuellement amélioré grâce aux boucles de feedback décrites précédemment – est ce qui rend l'audit possible. La principale différence ici est que nous orientons l'agent et la politique vers l'ensemble du monorepo, plutôt que vers une seule demande d'extraction.

C'est important non seulement pour le code existant (notre monorepo a plus de dix ans), mais aussi pour l'état stable ou futur. Les modèles sont stochastiques et pourraient ne pas faire ressortir tous les éléments lors d'un seul passage d'examen. De plus, notre modèle de menace évolue constamment, et chaque nouvelle génération de modèle peut détecter des vulnérabilités que la précédente ne pouvait pas déceler.

L'audit est une tâche plus difficile que l'examen, tant pour les agents que pour les humains. Demandez à un ingénieur de trouver un bug dans une demande d'extraction, et il fera du bon travail. Donnez une base de code vieille de dix ans à un ingénieur et demandez-lui d'en trouver tous les bugs, et il ne saura pas par où commencer. Cela vaut également pour les agents.

Nous avons rendu la tâche réalisable en abordant le problème par la force brute à l'aide de nombreux agents. Nous avons fixé un budget de coût et, connaissant approximativement le coût d'un agent pour analyser une tranche, nous l'avons converti en un nombre de fragments d'agent, puis nous avons procédé à l'analyse. Nous effectuons principalement le partitionnement par fichier ou par routes d'application. Deux autres ajustements ont été bénéfiques : l'élimination des catégories de bugs de faible gravité afin de concentrer le budget sur l'essentiel, et la réintroduction d'une phase d'examen contradictoire légère visant à contester les résultats obtenus.

Lors de notre première exécution, nous avons découvert plus d'une centaine de vulnérabilités latentes, dont deux critiques qui avaient échappé aux outils SAST traditionnels, et nous les avons corrigées immédiatement. Nous les avons ajoutées à notre corpus d'évaluation, où elles constituent désormais les deux tâches ayant obtenu les meilleurs scores.

Plus récemment, nous avons testé des workflows dynamiques pour des audits à l'échelle du référentiel, avec des résultats initiaux prometteurs, mais une consommation de tokens imprévisible. Nous pourrions remplacer notre système multi-harnais d'audit à l'échelle du référentiel par des systèmes dynamiques s'apparentant à des workflows, à mesure qu'ils arrivent à maturité. Grâce à ces systèmes, il suffit d'exécuter un prompt tel que « trouver des vulnérabilités » en pointant vers le modèle de menaces, et ils parallélisent alors les analyses et effectuent des passes contradictoires ainsi que des phases d'arbitrage si nécessaire.

Génération de code sécurisé

Pour aider les agents à générer du code sécurisé, nous utilisons des hooks. Nous avons constaté que ceux-ci orientent les agents de manière plus fiable que la même directive placée dans AGENTS.md. Pour certaines catégories de bugs, comme les problèmes de sécurité liés à la journalisation (écriture de données dans les mauvais journaux), la baisse observée après l'ajout d'un mécanisme de guidage a été d'environ 50 %. Nous maintenons une version intégrée, indépendante de l'agent, du plugin de recommandations de sécurité d’Anthropic. Il existe deux ensembles de hooks d’agents :

• On intègre des conseils juste à temps au moment précis où un agent effectue une opération risquée, comme l'ajout d'une route, la modification d'une politique d'autorisations ou l'enregistrement de données de télémétrie.
• L'autre ensemble transmet périodiquement le diff à un LLM ou, lors de la validation, le confie à un second agent de codage pour examen. Ceux-ci fonctionnent selon la même politique que notre examinateur et notre auditeur.

Les hooks possèdent également une caractéristique que l'examen de la demande d'extraction n'a pas : ils ne sont pas soumis à une exigence de précision aussi élevée, car ils restent pour la plupart invisibles pour l'auteur humain. Cela nous permet de les utiliser pour encourager l'adoption de bonnes pratiques, et pas seulement pour éloigner les vulnérabilités. Lorsqu'un agent ajoute une nouvelle route API, un hook peut intervenir pour y associer le décorateur d'autorisation approprié sécurisé par défaut et les tests correspondants, au-delà de la simple détection de bugs liés à l'autorisation.

Ce que nous avons appris

Nous ne pouvons pas vous dire exactement quoi faire : les détails dépendent de la taille de votre entreprise, des risques auxquels vous êtes confronté et des boucles de feedback que vous avez déjà mises en place. Mais une leçon principale est d'améliorer la précision avant le rappel. Cet ordre est contre-intuitif, car les bugs historiques dont vous disposez déjà ne permettent de mesurer que le rappel ; ils aident à peine à traiter la précision, qu'il faut pourtant corriger en priorité.

Une autre leçon clé est que la précision et le rappel proviennent de sources différentes ; c'est l'aspect que nous avons dû déterminer par nous-mêmes. Le taux de rappel s'obtient en faisant repasser l'examinateur sur des bugs déjà identifiés et en comptant les omissions. La précision ne reposant pas sur une cible fixe à reproduire et évoluant à chaque changement de politique, il n'existe pas d'évaluation hors ligne permanente à exécuter. Évaluer un nombre suffisant de ces rares résultats en conditions réelles impliquerait de passer au crible des demandes d'extraction pour la plupart anodines, à une échelle qu'aucune équipe ne pourrait soutenir. En production, l'examinateur s'exécute systématiquement sur chaque demande d'extraction. L'auteur de la modification procède donc à une première évaluation, tandis qu'un autre agent réexamine le code concerné pour chaque anomalie détectée et transmet aux experts internes en sécurité tout cas contesté ou non traité dont le modèle problématique persiste.

Voici quelques autres choses que nous avons apprises :

• Affectez un agent de tri disposant d'un accès au code source à chaque rapport de prime aux bugs entrant. Une nouvelle génération de chercheurs en primes aux bugs enchaîne des vulnérabilités de faible gravité pour créer des exploits à fort impact. Effectuez un tri rapide, instaurez la confiance et considérez ces chercheurs comme certaines de vos ressources de sécurité les plus précieuses. Nous ne pouvons pas compter sur l'examinateur pour détecter une nouvelle catégorie de vulnérabilité située en dehors du modèle de menace. Ces tâches continuent de relever des experts en sécurité interne et de sources externes, telles que le programme de prime aux bugs. Le tri manuel est trop lent pour soutenir l'ensemble de la boucle de feedback, tandis qu'un agent permet un tri rapide qui renforce la confiance des chercheurs, alimente de meilleures évaluations et, à terme, améliore le rappel.
• Demandez aux agents d'effectuer des vérifications axées sur les bonnes pratiques, et pas seulement sur les bugs. Demandez aux agents de vérifier que le code utilise les frameworks appropriés, sécurisés par défaut, et bénéficie d'une réelle couverture de tests. Si vous faites l'impasse là-dessus, la base de code dérive vers quelque chose sur lequel ni un humain ni un modèle ne peuvent raisonner. Pour chacune des trois étapes évoquées, nous déployons des agents distincts afin de prévenir les anti-modèles et les problèmes de qualité bien au-delà de la simple détection de bugs, dépassant le cadre de ce qui peut être abordé ici.

Grâce à la mise en place de systèmes adaptés, nos ingénieurs sécurité sont passés du tri des bugs un par un à la rédaction de politiques capables de détecter des centaines de bugs et d'en prévenir tout autant. Cela ressemble beaucoup au travail que nous avons toujours fait, mais avec plus de levier.