Méthodologie du benchmark

Ce que nous mesurons, ce que nous ne mesurons pas, et pourquoi

Le benchmark existe pour être vérifié, pas pour être admiré. Cette page en énonce le périmètre exact : ce que les chiffres publiés couvrent, ce qu'ils laissent délibérément de côté, et lesquelles de nos capacités ne peuvent honnêtement pas se résumer à un pourcentage.

Ce que le benchmark mesure

Une seule question, posée sur un corpus versionné de projets jugés à la main : sur un fichier dont nous avons déjà décidé, le moteur signale-t-il la vulnérabilité qui s'y trouve, à la bonne ligne, sans en signaler d'autres qui n'y sont pas ?

Un corpus versionné
Chaque cas est un petit projet contenant le code minimal qui présente, ou évite correctement, une vulnérabilité. Chacun porte un commentaire disant ce qui est vulnérable, ce qui est attendu et pourquoi. Le corpus est versionné : le modifier, c'est modifier les chiffres publiés.
Une vérité terrain qui décrit le code
Le résultat attendu est un jugement sur le code, arrêté avant l'exécution du moteur, jamais une description de ce que le moteur a produit. Quand les deux divergent, nous examinons le moteur d'abord. Une étiquette écrite pour coller à la sortie du moteur ne mesure rien, et nous avons dû en corriger qui avaient dérivé ainsi.
Le pipeline réellement livré
Chaque cas est analysé comme l'est un scan client : l'orchestrateur complet à profondeur maximale, sans scanner externe, sans modèle dans la boucle. Les chiffres décrivent le moteur livré à l'identique partout, pas une configuration de laboratoire montée pour l'occasion.
Du code correct, délibérément
Un tiers du corpus est du code non vulnérable, le plus souvent la forme corrigée d'un cas qui l'est. Un corpus fait uniquement de vulnérabilités ne peut pas détecter un faux positif, et ce sont les faux positifs qui font qu'un outil de sécurité cesse d'être lu.

Ce que le benchmark ne mesure pas

Cybseco livre ces capacités. Aucun chiffre de la page benchmark ne les décrit, et chacune porte sa raison. Une capacité omise en silence est une capacité dont le lecteur suppose qu'elle était couverte par les chiffres.

  • Dependency vulnerabilities (SCA) — Produced by external scanners that read a live vulnerability database. Their output changes when the database changes, with no change to Cybseco, so a precision figure measured today would describe the database rather than the engine and would not reproduce tomorrow.
  • Standalone secret scanning — Gitleaks is an external binary and is not installed for this benchmark. Hardcoded credentials found by Cybseco's own analyzers are measured, inside the code and CI/CD layers, under CWE-798 and CWE-532.
  • Third-party SAST (Semgrep, Bandit) — An external ruleset Cybseco orchestrates but does not author. Measuring it would report Semgrep's accuracy, not Cybseco's.
  • Licence compliance policy — A policy decision about a project's licences, not a judgement about its code. The corpus labels vulnerabilities, so a licence finding has nothing to be right or wrong against here.
  • LLM-assisted analysis — Its output depends on a model and a prompt rather than on the engine, and it is not part of the deterministic result this benchmark measures.
  • Graph, attack paths, decision engine — A different kind of claim: these produce paths and plans, not findings, so precision and recall over labelled lines cannot express them. The methodology page explains what could be measured, and which of these cannot honestly be reduced to a percentage at all. Publishing a number before the method is settled is how a benchmark stops being evidence.

Pourquoi certaines capacités ne sont pas un pourcentage

La détection a une bonne réponse : la vulnérabilité est à cette ligne ou elle n'y est pas. Une partie de ce que fait Cybseco relève d'un autre type d'affirmation, que la précision et le rappel ne savent pas exprimer. Publier un chiffre malgré tout serait la chose la plus facile de cette page, et le moyen le plus rapide de perdre le débat face à quelqu'un qui lit attentivement.

Le graphe d'architecture
Une affirmation factuelle : ces actifs existent et ces relations les lient. Mesurable, et c'est la première chose que nous comptons mesurer. Il y faut un corpus de dépôts complets annotés à la main, deux relecteurs indépendants, et l'accord entre eux publié à côté du score. En deçà, on mesure le processus d'annotation plutôt que l'extracteur.
Les chemins d'attaque
Factuel, mais seulement une fois précisé ce dont dispose l'attaquant au départ. « Un attaquant peut atteindre la base de données » n'est ni vrai ni faux tant qu'on n'a pas dit s'il part en visiteur anonyme, en utilisateur authentifié ou depuis un runner de build compromis. Le même moteur a raison sous une hypothèse et tort sous une autre : un chiffre sans cette hypothèse imprimée à côté n'est pas reproductible.
La priorisation contextuelle
Une affirmation sur ce qui compte le plus, et il n'existe pas de fait indépendant d'un objectif. Une startup avant revenus et une banque régulée lisent le même dépôt et ont toutes deux raison de le classer différemment. Tout ordre « correct » que nous publierions serait notre propre opinion produit, validée contre une vérité terrain que nous aurions également écrite.
Le moteur décisionnel
Agir maintenant, planifier, vérifier : une recommandation au regard d'une politique, et cette politique est une décision produit. Nous pouvons tester qu'il respecte sa propre politique, qu'aucune découverte n'est silencieusement écartée et que chaque recommandation cite des éléments qui existent. C'est un test de conformité. L'appeler exactitude inviterait précisément à la mauvaise lecture que cette page cherche à éviter.

Comment lire les chiffres

Quatre points à connaître avant de tirer une conclusion d'un chiffre isolé de la page benchmark.

La taille d'échantillon avant le pourcentage
Chaque couche indique sur combien de découvertes sa précision a été calculée. Les couches à petit échantillon sont les plus récentes, et leurs chiffres bougeront à mesure que leur corpus grandira. Cela joue autant contre les lignes flatteuses que contre la ligne gênante : un score parfait sur neuf découvertes est une affirmation faible, pas une affirmation forte.
Chaque faux positif est publié
Les découvertes que le moteur produit sur du code non vulnérable sont listées avec l'analyseur fautif et la raison pour laquelle la découverte est erronée. Elles sont comptées dans la précision, jamais retirées de son calcul. Trois d'entre elles se déclenchent sur la mitigation que la règle recommande elle-même, ce qui est exactement le type de défaut qu'un benchmark doit faire apparaître plutôt qu'absorber.
La couche LLM analyse votre code
Elle lit le code d'intégration de votre application à la recherche d'erreurs d'usage des LLM et des agents : une sortie de modèle qui atteint un shell, un identifiant placé dans un prompt, un outil d'agent capable de tout exécuter. Elle ne mesure aucune IA interne à Cybseco. Ce benchmark exécute le moteur déterministe, sans modèle dans la boucle.
Les limites connues sont nommées
Une vulnérabilité réelle mais hors de portée actuelle du moteur est enregistrée comme limite assumée, exclue du rappel, et listée. Enregistrer une limite est ce qui permet à une amélioration future d'apparaître comme un gain mesuré au lieu d'être revendiquée aujourd'hui.

Les règles que nous nous imposons

Ce sont des contraintes sur nous, pas des affirmations sur le produit. Ce sont elles qui rendent les chiffres dignes d'être lus.

  • Tout ce que Cybseco annonce est soit mesuré, soit nommé sur cette page comme hors périmètre. Il n'existe pas de troisième état, et un contrôle automatisé fait échouer la construction si un analyseur est livré sans l'un ou l'autre.
  • La vérité terrain décrit le code, arrêtée avant l'exécution du moteur. Une étiquette écrite pour coller à la sortie du moteur n'est pas une preuve.
  • Un chiffre est publié avec l'échantillon sur lequel il a été calculé.
  • Un défaut que nous connaissons est publié, pas exclu de la métrique. Un contrôle échoue également si un défaut publié cesse discrètement de se reproduire : la liste ne peut donc décroître qu'honnêtement.
  • Aucune comparaison avec un autre produit sur des capacités où nous choisirions sa configuration, son corpus et le scénario. Personne ne devrait croire une telle comparaison, nous y compris.
  • Aucun chiffre avant que sa méthodologie soit publique et sa vérité terrain inspectable.

Voyez Cybseco raisonner sur un système réel

Regardez la démo interactive, puis demandez un essai guidé pour votre équipe.