Hvad vi måler, hvad vi ikke måler, og hvorfor

Hvert tilfælde er et lille projekt der indeholder den mindste kode som udviser, eller sikkert undgår, én sårbarhed. Hvert bærer en kommentar der siger hvad der er galt, hvad der forventes og hvorfor. Korpuset er versioneret: en ændring i det er en ændring i de offentliggjorte tal.

Det forventede resultat er en bedømmelse af koden, besluttet før motoren kører, aldrig en beskrivelse af hvad motoren producerede. Når de to er uenige, undersøger vi motoren først. En mærkning skrevet for at matche motorens output måler intet, og vi har måttet rette mærkninger der var drevet den vej.

Hvert tilfælde analyseres sådan som en kundescanning kører: den fulde orkestrator på maksimal dybde, ingen eksterne scannere, ingen model i løkken. Tallene beskriver den motor der leveres identisk overalt, ikke en laboratoriekonfiguration sammensat til lejligheden.

En tredjedel af korpuset er kode der ikke er sårbar, det meste af det den rettede form af et tilfælde der er. Et korpus af sårbarheder alene kan ikke afsløre en falsk positiv, og falske positiver er det der får et sikkerhedsværktøj til at holde op med at blive læst.

En faktuel påstand: disse aktiver findes, og disse relationer gælder mellem dem. Målbar, og det første vi har til hensigt at måle. Det kræver et korpus af komplette repositories annoteret i hånden, to uafhængige bedømmere, og enigheden mellem dem offentliggjort ved siden af scoren. Noget mindre måler annoteringsprocessen snarere end ekstraktoren.

Faktuelle, men først når nogen angiver hvad angriberen starter med. »En angriber kan nå databasen« er hverken sandt eller falsk før du siger om de begynder som en anonym besøgende, en autentificeret bruger eller en kompromitteret build-runner. Den samme motor har ret under én antagelse og uret under en anden, så et tal uden den antagelse trykt ved siden af er ikke reproducerbart.

En påstand om hvad der betyder mere, og der findes intet faktum om sagen uafhængigt af et mål. En startup før omsætning og en reguleret bank læser det samme repository og har begge ret i at rangere det forskelligt. Enhver korrekt rækkefølge vi offentliggjorde ville være vores egen produktholdning, valideret mod en ground truth vi også selv skrev.

Handl nu, planlæg, verificér: en anbefaling op mod en politik, og politikken er en produktbeslutning. Vi kan teste at den følger sin egen politik, at intet fund droppes i stilhed, og at hver anbefaling citerer evidens der findes. Det er en konformitetstest. At kalde det nøjagtighed ville indbyde til præcis den fejllæsning denne side er skrevet for at forhindre.

Hvert lag viser hvor mange fund dets præcision blev beregnet ud fra. Lagene med små stikprøver er de nyligt tilføjede, og deres tal vil flytte sig efterhånden som deres korpus vokser. Dette taler imod de smigrende rækker lige så meget som den akavede: en perfekt score over ni fund er en svag påstand, ikke en stærk.

Fund som motoren producerer på kode der ikke er sårbar er anført med den ansvarlige analysator og grunden til at fundet er forkert. De tælles med imod præcisionen, aldrig udeladt fra den. Tre af dem udløses på den afhjælpning som reglen selv anbefaler, hvilket er præcis den slags defekt et benchmark findes for at bringe frem snarere end at absorbere.

Det læser en applikations egen integrationskode for LLM- og agentfejl: modeloutput der når en shell, en legitimationsoplysning placeret i en prompt, et agentværktøj der kan køre hvad som helst. Det er ikke et mål for en AI inde i Cybseco. Dette benchmark kører den deterministiske motor uden nogen model i løkken.

En sårbarhed der er reel og uden for motorens nuværende rækkevidde registreres som et accepteret hul, udelades fra recall og anføres. At registrere en begrænsning er måden hvorpå en fremtidig forbedring viser sig som en målt gevinst i stedet for at blive hævdet i dag.