Metodologia del benchmark
Che cosa misuriamo, che cosa non misuriamo e perché
Il benchmark esiste per essere verificato, non ammirato. Questa pagina ne enuncia il perimetro esatto: che cosa coprono le cifre pubblicate, che cosa lasciano deliberatamente fuori e quali delle nostre capacità non possono essere ridotte onestamente a una percentuale.
Che cosa misura il benchmark
Una domanda, posta su un corpus versionato di progetti giudicati a mano: dato un file su cui abbiamo già deciso, il motore segnala la vulnerabilità presente, sulla riga giusta, senza segnalare cose che non ci sono?
Un corpus versionato
Ogni caso è un piccolo progetto che contiene il minimo codice che presenta, o evita in modo sicuro, una vulnerabilità. Ciascuno porta un commento che dice che cosa non va, che cosa ci si aspetta e perché. Il corpus è versionato: modificarlo significa modificare le cifre pubblicate.
Verità di riferimento scritta sul codice
Il risultato atteso è un giudizio sul codice, deciso prima che il motore venga eseguito, mai una descrizione di ciò che il motore ha prodotto. Quando i due divergono, indaghiamo prima sul motore. Un'etichetta scritta per coincidere con l'output del motore non misura nulla, e abbiamo già dovuto correggere etichette che avevano deviato in quella direzione.
La pipeline distribuita
Ogni caso è analizzato come viene eseguita una scansione cliente: l'orchestratore completo alla massima profondità, nessuno scanner esterno, nessun modello nel ciclo. Le cifre descrivono il motore distribuito in modo identico ovunque, non una configurazione di laboratorio assemblata per l'occasione.
Codice corretto, deliberatamente
Un terzo del corpus è codice non vulnerabile, per lo più la forma corretta di un caso che lo è. Un corpus fatto solo di vulnerabilità non può rilevare un falso positivo, e i falsi positivi sono ciò che fa smettere di leggere uno strumento di sicurezza.
Che cosa il benchmark non misura
Cybseco li distribuisce. Nessuna cifra della pagina del benchmark li descrive, e ciascuno porta la propria ragione. Una capacità omessa in silenzio è una capacità che il lettore presume coperta dalle cifre.
- 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.
Perché alcune capacità non sono una percentuale
Il rilevamento ha una risposta giusta: la vulnerabilità è su quella riga oppure no. Parte di ciò che fa Cybseco avanza un'affermazione di altra natura, e precisione e richiamo non possono esprimerla. Pubblicare comunque una cifra sarebbe la cosa più facile di questa pagina e il modo più rapido di perdere la discussione con chi legge attentamente.
Il grafo di architettura
Un'affermazione fattuale: questi asset esistono e queste relazioni sussistono fra loro. Misurabile, ed è la prima cosa che intendiamo misurare. Richiede un corpus di repository completi annotati a mano, due revisori indipendenti e l'accordo fra loro pubblicato accanto al punteggio. Qualcosa di meno misura il processo di annotazione anziché l'estrattore.
Percorsi di attacco
Fattuali, ma solo una volta che qualcuno dichiara da che cosa parte l'attaccante. «Un attaccante può raggiungere il database» non è né vero né falso finché non si dice se parte da visitatore anonimo, da utente autenticato o da build runner compromesso. Lo stesso motore ha ragione sotto un'ipotesi e torto sotto un'altra, quindi una cifra senza quell'ipotesi stampata accanto non è riproducibile.
Prioritizzazione contestuale
Un'affermazione su che cosa conta di più, e non esiste un fatto indipendente da un obiettivo. Una startup senza ricavi e una banca regolamentata leggono lo stesso repository e hanno entrambe ragione a ordinarlo diversamente. Qualsiasi ordine «corretto» che pubblicassimo sarebbe la nostra opinione di prodotto, validata contro una verità di riferimento scritta anch'essa da noi.
Il motore decisionale
Agire ora, pianificare, verificare: una raccomandazione rispetto a una policy, e la policy è una decisione di prodotto. Possiamo verificare che segua la propria policy, che nessun risultato venga scartato in silenzio e che ogni raccomandazione citi prove esistenti. Questo è un test di conformità. Chiamarlo accuratezza inviterebbe esattamente all'equivoco che questa pagina è scritta per evitare.
Come leggere le cifre
Quattro cose da sapere prima di trarre una conclusione da una singola cifra della pagina del benchmark.
Dimensione del campione prima della percentuale
Ogni livello mostra da quanti risultati è stata calcolata la sua precisione. I livelli con campioni piccoli sono quelli aggiunti di recente, e le loro cifre si muoveranno man mano che il loro corpus cresce. Questo vale contro le righe lusinghiere quanto contro quella scomoda: un punteggio perfetto su nove risultati è un'affermazione debole, non forte.
Ogni falso positivo è pubblicato
I risultati che il motore produce su codice non vulnerabile sono elencati con l'analizzatore responsabile e il motivo per cui il risultato è sbagliato. Sono conteggiati a sfavore della precisione, mai esclusi da essa. Tre di essi scattano sulla mitigazione che la regola stessa raccomanda, che è proprio il tipo di difetto che un benchmark esiste per far emergere anziché assorbire.
Il livello LLM analizza il vostro codice
Legge il codice di integrazione della stessa applicazione alla ricerca di errori di LLM e di agenti: output del modello che raggiunge una shell, una credenziale inserita in un prompt, uno strumento agente in grado di eseguire qualsiasi cosa. Non è una misura di un'IA all'interno di Cybseco. Questo benchmark esegue il motore deterministico senza alcun modello nel ciclo.
Le lacune note sono nominate
Una vulnerabilità reale e fuori dalla portata attuale del motore è registrata come lacuna accettata, esclusa dal richiamo ed elencata. Registrare un limite è il modo in cui un miglioramento futuro si presenta come un guadagno misurato anziché essere proclamato oggi.
Le regole che ci imponiamo
Sono vincoli su di noi, non affermazioni sul prodotto. Sono ciò che rende le cifre degne di essere lette.
- Tutto ciò che Cybseco annuncia è misurato oppure nominato in questa pagina come fuori ambito. Non esiste un terzo stato, e un controllo automatico fa fallire la build quando un analizzatore viene distribuito senza l'uno o l'altro.
- La verità di riferimento descrive il codice ed è decisa prima che il motore venga eseguito. Un'etichetta scritta per coincidere con l'output del motore non è una prova.
- Una cifra è pubblicata insieme al campione da cui è stata calcolata.
- Un difetto che conosciamo viene pubblicato, non escluso dalla metrica. Un controllo fallisce anche quando un difetto pubblicato smette silenziosamente di riprodursi, così l'elenco può accorciarsi solo onestamente.
- Nessun confronto con un altro prodotto su capacità in cui saremmo noi a scegliere la sua configurazione, il suo corpus e lo scenario. Nessuno dovrebbe credere a un confronto simile, noi compresi.
- Nessuna cifra prima che la sua metodologia sia pubblica e la sua verità di riferimento ispezionabile.
Guarda Cybseco ragionare su un sistema reale
Guarda la demo interattiva, poi richiedi una prova guidata per il tuo team.