Benchmark-Methodik
Was wir messen, was wir nicht messen, und warum
Der Benchmark existiert, um geprüft zu werden, nicht um bewundert zu werden. Diese Seite nennt seinen genauen Geltungsbereich: was die veröffentlichten Zahlen abdecken, was sie bewusst auslassen, und welche unserer Fähigkeiten sich nicht redlich auf einen Prozentsatz reduzieren lassen.
Was der Benchmark misst
Eine Frage, gestellt über ein versioniertes Korpus von Hand beurteilter Projekte: Meldet die Engine bei einer Datei, über die wir bereits entschieden haben, die vorhandene Schwachstelle in der richtigen Zeile, ohne Dinge zu melden, die nicht vorhanden sind?
Ein versioniertes Korpus
Jeder Fall ist ein kleines Projekt mit dem kleinstmöglichen Code, der genau eine Schwachstelle aufweist oder sicher vermeidet. Jeder trägt einen Kommentar, der sagt, was falsch ist, was erwartet wird und warum. Das Korpus ist versioniert: Eine Änderung daran ist eine Änderung der veröffentlichten Zahlen.
Grundwahrheit, über den Code geschrieben
Das erwartete Ergebnis ist ein Urteil über den Code, gefällt bevor die Engine läuft, niemals eine Beschreibung dessen, was die Engine erzeugt hat. Wenn beide sich widersprechen, untersuchen wir zuerst die Engine. Ein Label, das geschrieben wurde, um zur Engine-Ausgabe zu passen, misst nichts, und wir mussten bereits Labels korrigieren, die in diese Richtung abgedriftet waren.
Die Pipeline, die ausgeliefert wird
Jeder Fall wird so analysiert, wie ein Kundenscan läuft: der vollständige Orchestrator bei maximaler Tiefe, keine externen Scanner, kein Modell in der Schleife. Die Zahlen beschreiben die Engine, die überall identisch ausgeliefert wird, nicht eine für den Anlass zusammengestellte Laborkonfiguration.
Korrekter Code, mit Absicht
Ein Drittel des Korpus ist nicht verwundbarer Code, größtenteils die korrigierte Form eines Falls, der es ist. Ein Korpus allein aus Schwachstellen kann keinen Fehlalarm erkennen, und Fehlalarme sind das, was dazu führt, dass ein Sicherheitswerkzeug nicht mehr gelesen wird.
Was der Benchmark nicht misst
Cybseco liefert diese aus. Keine Zahl auf der Benchmark-Seite beschreibt sie, und jede trägt ihre Begründung. Eine stillschweigend ausgelassene Fähigkeit ist eine Fähigkeit, von der ein Leser annimmt, die Zahlen hätten sie abgedeckt.
- 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.
Warum manche Fähigkeiten kein Prozentsatz sind
Erkennung hat eine richtige Antwort: Die Schwachstelle steht in dieser Zeile oder nicht. Manches, was Cybseco tut, erhebt einen anderen Anspruch, und Precision und Recall können ihn nicht ausdrücken. Trotzdem eine Zahl zu veröffentlichen wäre das Einfachste auf dieser Seite und der schnellste Weg, die Diskussion mit jemandem zu verlieren, der genau liest.
Der Architekturgraph
Eine Tatsachenbehauptung: Diese Assets existieren und diese Beziehungen bestehen zwischen ihnen. Messbar, und das Erste, was wir zu messen beabsichtigen. Es braucht ein Korpus vollständiger, von Hand annotierter Repositories, zwei unabhängige Prüfer und die neben dem Ergebnis veröffentlichte Übereinstimmung zwischen ihnen. Alles darunter misst den Annotationsprozess statt den Extraktor.
Angriffspfade
Tatsächlich, aber erst wenn jemand angibt, womit der Angreifer beginnt. „Ein Angreifer kann die Datenbank erreichen“ ist weder wahr noch falsch, solange nicht gesagt wird, ob er als anonymer Besucher, als authentifizierter Nutzer oder als kompromittierter Build-Runner startet. Dieselbe Engine liegt unter einer Annahme richtig und unter einer anderen falsch, also ist eine Zahl ohne daneben abgedruckte Annahme nicht reproduzierbar.
Kontextbezogene Priorisierung
Eine Aussage darüber, was mehr zählt, und dazu gibt es keinen Sachverhalt unabhängig von einem Ziel. Ein Start-up vor den ersten Umsätzen und eine regulierte Bank lesen dasselbe Repository und haben beide recht, es unterschiedlich zu ordnen. Jede von uns veröffentlichte „richtige“ Reihenfolge wäre unsere eigene Produktmeinung, validiert gegen eine Grundwahrheit, die wir ebenfalls geschrieben haben.
Die Entscheidungs-Engine
Jetzt handeln, planen, prüfen: eine Empfehlung gegen eine Richtlinie, und die Richtlinie ist eine Produktentscheidung. Wir können testen, dass sie ihrer eigenen Richtlinie folgt, dass kein Befund stillschweigend entfällt und dass jede Empfehlung auf existierende Belege verweist. Das ist ein Konformitätstest. Ihn Genauigkeit zu nennen, lüde genau zu dem Missverständnis ein, das diese Seite verhindern soll.
Wie die Zahlen zu lesen sind
Vier Dinge, die man wissen sollte, bevor man aus einer einzelnen Zahl auf der Benchmark-Seite eine Schlussfolgerung zieht.
Stichprobengröße vor Prozentsatz
Jede Schicht zeigt, aus wie vielen Befunden ihre Precision berechnet wurde. Die Schichten mit kleinen Stichproben sind die zuletzt hinzugefügten, und ihre Zahlen werden sich bewegen, während ihr Korpus wächst. Das gilt gegen die schmeichelhaften Zeilen genauso wie gegen die unangenehme: Ein perfektes Ergebnis über neun Befunde ist eine schwache Aussage, keine starke.
Jeder Fehlalarm wird veröffentlicht
Befunde, die die Engine auf nicht verwundbarem Code erzeugt, sind mit dem verantwortlichen Analyzer und dem Grund, warum der Befund falsch ist, aufgelistet. Sie werden gegen die Precision gerechnet, niemals aus ihr herausgenommen. Drei davon lösen auf der Gegenmaßnahme aus, die die Regel selbst empfiehlt — genau die Art Defekt, die ein Benchmark sichtbar machen und nicht absorbieren soll.
Die LLM-Schicht analysiert Ihren Code
Sie liest den eigenen Integrationscode einer Anwendung auf LLM- und Agentenfehler: Modellausgaben, die eine Shell erreichen, ein in einen Prompt gelegtes Zugangsgeheimnis, ein Agenten-Tool, das alles ausführen kann. Sie misst keine KI innerhalb von Cybseco. Dieser Benchmark führt die deterministische Engine ohne Modell in der Schleife aus.
Bekannte Lücken werden benannt
Eine Schwachstelle, die real ist und außerhalb der aktuellen Reichweite der Engine liegt, wird als akzeptierte Lücke erfasst, aus dem Recall ausgeschlossen und aufgelistet. Eine Grenze festzuhalten ist der Weg, auf dem eine künftige Verbesserung als gemessener Zugewinn sichtbar wird, statt heute behauptet zu werden.
Die Regeln, an die wir uns halten
Das sind Einschränkungen für uns, keine Aussagen über das Produkt. Sie sind es, die die Zahlen lesenswert machen.
- Alles, was Cybseco ankündigt, ist entweder gemessen oder auf dieser Seite als außerhalb des Geltungsbereichs benannt. Einen dritten Zustand gibt es nicht, und ein automatisches Gate lässt den Build fehlschlagen, wenn ein Analyzer ohne eines von beiden ausgeliefert wird.
- Die Grundwahrheit beschreibt den Code und wird festgelegt, bevor die Engine läuft. Ein Label, das zur Engine-Ausgabe passend geschrieben wurde, ist kein Beleg.
- Eine Zahl wird zusammen mit der Stichprobe veröffentlicht, aus der sie berechnet wurde.
- Ein Defekt, von dem wir wissen, wird veröffentlicht und nicht aus der Metrik ausgeschlossen. Ein Gate schlägt auch fehl, wenn ein veröffentlichter Defekt stillschweigend nicht mehr reproduzierbar ist, sodass die Liste nur ehrlich schrumpfen kann.
- Kein Vergleich mit einem anderen Produkt bei Fähigkeiten, bei denen wir dessen Konfiguration, dessen Korpus und das Szenario wählen würden. Einen solchen Vergleich sollte niemand glauben, wir eingeschlossen.
- Keine Zahl, bevor ihre Methodik öffentlich und ihre Grundwahrheit einsehbar ist.
Sehen Sie Cybseco über ein reales System nachdenken
Sehen Sie sich die interaktive Demo an und fordern Sie dann einen begleiteten Test für Ihr Team an.