← Retour au classement

Comment nous effectuons nos tests

La qualité des tests de performance dépend entièrement de leur configuration. Voici comment nous évaluons la capacité d'un modèle à détecter de véritables vulnérabilités, ainsi que le coût de cette opération.

1. 1

   Choisissez de véritables vulnérabilités

   Nous extrayons les CVE répertoriés dans la base de données des avis de sécurité de GitHub, qui couvre de nombreux langages et types de projets.

2. 2

   Épingler le commit vulnérable

   Chaque dépôt est extrait à partir d'une validation effectuée juste avant sa correction.

3. 3

   Exécuter dans l'environnement de production

   Les modèles fonctionnent au sein du même environnement d'IA que celui fourni avec « Code Security Audit » et « Aikido Attack ».

4. 4

   Mettez en évidence le bout de code vulnérable

   Comme nous savons où se trouve chaque vulnérabilité, les agents d'investigation ciblent directement le code vulnérable. Un échec reflète un raisonnement erroné — et non un gaspillage budgétaire dû à une recherche dans la mauvaise partie du dépôt. Les invites restent courtes et indépendantes du modèle utilisé.

5. 5

   Exécutez trois fois, puis regroupez les résultats

   Les modèles sont non déterministes. Nous exécutons chacun d'entre eux trois fois et considérons qu'un CVE a été détecté s'il apparaît au cours de l'une de ces exécutions. Le regroupement permet de détecter des bogues qu'une seule exécution ne permettrait pas de repérer, et reflète de manière plus réaliste la façon dont ces agents seraient déployés.

6. 6

   Couverture des scores et coût combinés

   Nous recensons le nombre de vulnérabilités CVE redécouvertes par chaque modèle ainsi que le coût associé à cette découverte, car le modèle le plus performant n'est que rarement celui qui offre le meilleur rapport qualité-prix. Nous comparons également les niveaux de raisonnement lorsque le fournisseur les communique.

---

À propos de la configuration du harnais

C'est grâce à un « harnais » qu'un modèle linguistique se transforme en auditeur. Un assistant de programmation polyvalent est conçu pour une autre mission : celle de prendre une tâche en charge et de produire du code fonctionnel. Si vous lui indiquez un dépôt et lui demandez s’il est sécurisé, il se comporte comme un développeur qui passe le code au crible à la recherche d’une erreur manifeste, puis s’arrête dès qu’il a trouvé quelque chose de plausible. L’outil « Code Security Audit » de Aikido est conçu différemment. Il explore la base de code à la recherche de points d’entrée potentiels, examine en profondeur chaque flux suspect, puis trie les résultats afin que nous n’obtenions que les véritables vulnérabilités.

Parce que nous savions où se trouvait chaque vulnérabilité, nous avons dirigé chaque agent d'investigation directement vers l'extrait de code vulnérable. Ainsi, un échec reflète un problème de raisonnement plutôt qu'un budget gaspillé à explorer la mauvaise partie de la base de code. Le modèle doit toujours comprendre le flux, juger de l'exploitabilité et le signaler correctement. Les prompts ont été maintenus courts et agnostiques au modèle afin qu'aucun fournisseur ne soit avantagé par la formulation.

---