Metodologia benchmarku
Co mierzymy, czego nie mierzymy i dlaczego
Benchmark istnieje po to, by go sprawdzać, a nie podziwiać. Ta strona podaje jego dokładny zakres: co obejmują publikowane liczby, co celowo pomijają i których naszych możliwości nie da się uczciwie sprowadzić do procentu.
Co mierzy benchmark
Jedno pytanie, zadane na wersjonowanym korpusie projektów ocenionych ręcznie: czy dla pliku, o którym już zdecydowaliśmy, silnik zgłasza podatność, która tam jest, we właściwym wierszu, nie zgłaszając rzeczy, których nie ma?
Wersjonowany korpus
Każdy przypadek to mały projekt zawierający najmniejszy kod, który wykazuje lub bezpiecznie omija jedną podatność. Każdy niesie komentarz mówiący, co jest nie tak, czego się oczekuje i dlaczego. Korpus jest wersjonowany: jego zmiana to zmiana publikowanych liczb.
Prawda odniesienia zapisana o kodzie
Oczekiwany wynik jest osądem o kodzie, podjętym zanim silnik zostanie uruchomiony, nigdy opisem tego, co silnik wyprodukował. Gdy te dwa się rozchodzą, najpierw badamy silnik. Etykieta napisana tak, by pasowała do wyjścia silnika, nie mierzy niczego, a musieliśmy już poprawiać etykiety, które w tę stronę zdryfowały.
Potok, który jest dostarczany
Każdy przypadek jest analizowany tak, jak przebiega skan klienta: pełny orkiestrator na maksymalnej głębokości, bez zewnętrznych skanerów, bez modelu w pętli. Liczby opisują silnik dostarczany identycznie wszędzie, a nie konfigurację laboratoryjną złożoną na tę okazję.
Poprawny kod, celowo
Jedna trzecia korpusu to kod niepodatny, w większości poprawiona wersja przypadku, który podatny jest. Korpus złożony wyłącznie z podatności nie potrafi wykryć fałszywego alarmu, a to właśnie fałszywe alarmy sprawiają, że narzędzie bezpieczeństwa przestaje być czytane.
Czego benchmark nie mierzy
Cybseco je dostarcza. Żadna liczba na stronie benchmarku ich nie opisuje, a każda niesie swoje uzasadnienie. Możliwość pominięta po cichu to możliwość, co do której czytelnik zakłada, że liczby ją obejmowały.
- 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.
Dlaczego niektóre możliwości nie są procentem
Wykrywanie ma poprawną odpowiedź: podatność jest w tym wierszu albo jej nie ma. Część tego, co robi Cybseco, formułuje twierdzenie innego rodzaju, a precyzja i czułość nie potrafią go wyrazić. Opublikowanie mimo to jakiejś liczby byłoby najłatwiejszą rzeczą na tej stronie i najszybszym sposobem na przegranie dyskusji z kimś, kto czyta uważnie.
Graf architektury
Twierdzenie faktyczne: te zasoby istnieją i te relacje między nimi zachodzą. Mierzalne i jest to pierwsza rzecz, którą zamierzamy zmierzyć. Wymaga korpusu kompletnych repozytoriów oznaczonych ręcznie, dwóch niezależnych recenzentów oraz zgodności między nimi publikowanej obok wyniku. Cokolwiek mniej mierzy proces oznaczania, a nie ekstraktor.
Ścieżki ataku
Faktyczne, ale dopiero gdy ktoś określi, od czego zaczyna atakujący. „Atakujący może dosięgnąć bazy danych” nie jest ani prawdą, ani fałszem, dopóki nie powie się, czy zaczyna jako anonimowy odwiedzający, uwierzytelniony użytkownik czy przejęty runner buildów. Ten sam silnik ma rację przy jednym założeniu i nie ma jej przy innym, więc liczba bez wydrukowanego obok założenia nie jest odtwarzalna.
Priorytetyzacja kontekstowa
Twierdzenie o tym, co ma większe znaczenie, a nie istnieje żaden fakt niezależny od celu. Startup przed pierwszymi przychodami i regulowany bank czytają to samo repozytorium i oba mają rację, porządkując je inaczej. Każda „poprawna” kolejność, którą byśmy opublikowali, byłaby naszą własną opinią produktową, zwalidowaną wobec prawdy odniesienia, którą też sami napisaliśmy.
Silnik decyzyjny
Działaj teraz, zaplanuj, zweryfikuj: rekomendacja wobec polityki, a polityka jest decyzją produktową. Możemy sprawdzić, że stosuje własną politykę, że żaden wynik nie znika po cichu i że każda rekomendacja powołuje się na istniejący dowód. To test zgodności. Nazwanie go dokładnością zapraszałoby dokładnie do tego nieporozumienia, któremu ta strona ma zapobiec.
Jak czytać liczby
Cztery rzeczy warte wiedzy, zanim wyciągnie się wniosek z jakiejkolwiek pojedynczej liczby na stronie benchmarku.
Wielkość próby przed procentem
Każda warstwa pokazuje, z ilu wyników obliczono jej precyzję. Warstwy z małymi próbami to te dodane niedawno, a ich liczby będą się zmieniać wraz ze wzrostem korpusu. Działa to przeciw pochlebnym wierszom tak samo jak przeciw niewygodnemu: idealny wynik z dziewięciu wyników to słabe twierdzenie, a nie mocne.
Każdy fałszywy alarm jest publikowany
Wyniki, które silnik generuje na kodzie niepodatnym, są wymienione wraz z odpowiedzialnym analizatorem i powodem, dla którego wynik jest błędny. Są liczone przeciwko precyzji i nigdy z niej nie wyłączane. Trzy z nich uruchamiają się na zabezpieczeniu, które sama reguła zaleca, a to właśnie ten rodzaj usterki, który benchmark ma ujawniać, a nie pochłaniać.
Warstwa LLM analizuje Twój kod
Czyta własny kod integracyjny aplikacji pod kątem błędów LLM i agentów: wyjście modelu docierające do powłoki, poświadczenie umieszczone w prompcie, narzędzie agenta zdolne uruchomić cokolwiek. Nie jest miarą sztucznej inteligencji wewnątrz Cybseco. Ten benchmark uruchamia silnik deterministyczny bez modelu w pętli.
Znane luki są nazwane
Podatność rzeczywista i poza obecnym zasięgiem silnika jest rejestrowana jako przyjęta luka, wyłączana z czułości i wymieniana. Zapisanie ograniczenia jest sposobem, w jaki przyszła poprawa pojawia się jako zmierzony zysk, zamiast być deklarowana dzisiaj.
Zasady, którym sami podlegamy
To ograniczenia nałożone na nas, a nie twierdzenia o produkcie. To one sprawiają, że liczby warto czytać.
- Wszystko, co Cybseco ogłasza, jest albo zmierzone, albo nazwane na tej stronie jako poza zakresem. Trzeciego stanu nie ma, a automatyczna bramka przerywa build, gdy analizator zostaje dostarczony bez jednego lub drugiego.
- Prawda odniesienia opisuje kod i jest ustalana zanim silnik zostanie uruchomiony. Etykieta napisana tak, by pasowała do wyjścia silnika, nie jest dowodem.
- Liczba jest publikowana wraz z próbą, z której ją obliczono.
- Usterka, o której wiemy, jest publikowana, a nie wyłączana z metryki. Bramka przerywa build także wtedy, gdy opublikowana usterka po cichu przestaje się odtwarzać, dzięki czemu lista może kurczyć się wyłącznie uczciwie.
- Żadnych porównań z innym produktem w obszarach, w których to my wybieralibyśmy jego konfigurację, jego korpus i scenariusz. W takie porównanie nikt nie powinien wierzyć, łącznie z nami.
- Żadnej liczby, zanim jej metodologia nie będzie publiczna, a prawda odniesienia możliwa do sprawdzenia.
Zobacz, jak Cybseco wnioskuje o rzeczywistym systemie
Obejrzyj interaktywne demo, a następnie poproś o prowadzony okres próbny dla swojego zespołu.