Vad vi mäter, vad vi inte mäter, och varför

Varje fall är ett litet projekt som innehåller den minsta kod som uppvisar, eller säkert undviker, en sårbarhet. Varje bär en kommentar som säger vad som är fel, vad som förväntas och varför. Korpuset är versionshanterat: en ändring i det är en ändring i de publicerade siffrorna.

Det förväntade resultatet är en bedömning av koden, beslutad innan motorn körs, aldrig en beskrivning av vad motorn producerade. När de två är oense undersöker vi motorn först. En etikett skriven för att matcha motorns utdata mäter ingenting, och vi har fått korrigera etiketter som hade drivit åt det hållet.

Varje fall analyseras så som en kundskanning körs: den fullständiga orkestratorn på maximalt djup, inga externa skannrar, ingen modell i loopen. Siffrorna beskriver motorn som levereras identiskt överallt, inte en laboratoriekonfiguration hopsatt för tillfället.

En tredjedel av korpuset är kod som inte är sårbar, merparten av den den korrigerade formen av ett fall som är det. Ett korpus av enbart sårbarheter kan inte upptäcka en falsk positiv, och falska positiva är det som får ett säkerhetsverktyg att sluta läsas.

Ett faktapåstående: dessa tillgångar finns och dessa relationer gäller mellan dem. Mätbart, och det första vi avser att mäta. Det kräver ett korpus av kompletta repositorier annoterade för hand, två oberoende granskare, och överensstämmelsen mellan dem publicerad bredvid poängen. Något mindre mäter annoteringsprocessen snarare än extraktorn.

Faktiska, men först när någon anger vad angriparen startar med. ”En angripare kan nå databasen” är varken sant eller falskt förrän du säger om de börjar som en anonym besökare, en autentiserad användare eller en komprometterad build-runner. Samma motor har rätt under ett antagande och fel under ett annat, så en siffra utan det antagandet tryckt bredvid är inte reproducerbar.

Ett påstående om vad som betyder mer, och det finns inget sakförhållande oberoende av ett mål. En startup före intäkter och en reglerad bank läser samma repositorium och har båda rätt i att rangordna det olika. Varje korrekt ordning vi publicerade skulle vara vår egen produktåsikt, validerad mot en ground truth som vi också skrev.

Agera nu, planera, verifiera: en rekommendation mot en policy, och policyn är ett produktbeslut. Vi kan testa att den följer sin egen policy, att inget fynd tyst förkastas, och att varje rekommendation hänvisar till bevis som finns. Det är ett konformitetstest. Att kalla det noggrannhet vore att bjuda in exakt den misstolkning som den här sidan är skriven för att förhindra.

Varje lager visar från hur många fynd dess precision beräknades. Lagren med små urval är de nyligen tillagda, och deras siffror kommer att röra sig när deras korpus växer. Detta talar emot de smickrande raderna lika mycket som den besvärliga: ett perfekt resultat över nio fynd är ett svagt påstående, inte ett starkt.

Fynd som motorn producerar på kod som inte är sårbar listas med den felande analysatorn och skälet till att fyndet är fel. De räknas mot precisionen, de undantas aldrig från den. Tre av dem utlöses på den åtgärd som regeln själv rekommenderar, vilket är precis den sortens defekt som ett benchmark finns till för att blottlägga snarare än att absorbera.

Det läser en applikations egen integrationskod efter LLM- och agentmisstag: modellutdata som når ett skal, en autentiseringsuppgift placerad i en prompt, ett agentverktyg som kan köra vad som helst. Det är inte ett mått på en AI inuti Cybseco. Detta benchmark kör den deterministiska motorn utan någon modell i loopen.

En sårbarhet som är verklig och utanför motorns nuvarande räckvidd registreras som en accepterad lucka, utesluts från recall och listas. Att registrera en gräns är hur en framtida förbättring visar sig som en mätt vinst i stället för att påstås idag.