For noen måneder siden var KI-genererte sikkerhetsrapporter til open source-prosjekter for det meste støy. Plausible-utseende men feilaktige rapporter påla en asymmetrisk kostnad: billig å generere, dyrt å avvise. Det har endret seg dramatisk, ifølge Mozillas egen redegjørelse i hacks.mozilla.org. To faktorer drev endringen: modellene ble vesentlig dyktigere, og Mozilla bygde sin egen agent-pipeline rundt Firefox-kodebasen for å filtrere reproduserbare funn fra spekulasjon.
«Det er vanskelig å overdrive hvor mye dette skiftet for oss på noen få måneder. Den agentiske pipeline-en kan kjøre reproduserbare testtilfeller dynamisk for å bekrefte hypoteser om bugs i koden.» — Mozillas Firefox-team
Mozilla bryter med sin vanlige praksis om seks måneders embargo og publiserer detaljerte rapporter for åtte saker. Bug 2025977 er en 20 år gammel XSLT-feil der reentrant key()-kall trigger en hash-table-rehash som frigjør sin egen backing store mens en peker fortsatt brukes. Bug 2024918 er en JIT-feil som fjerner initialisering av en levende WebAssembly GC-struct og skaper et fake-object-primitiv. Bug 2021894 utnytter en race condition over IPC til å manipulere IndexedDB-refcounts i parent-prosessen for use-after-free og potensiell sandkasse-escape.
Flere av buggene er sandkasse-escape, som krever at angriperen allerede har kompromittert content-prosessen. Modellen fikk lov til å patche Firefox-kildekoden på sandkasse-siden under analysen, så lenge endringene var begrenset til den ikke-privilegerte prosessen. Mozilla rapporterer at modellen også gjorde mange forsøk på å eskalere via prototype pollution i parent-prosessen, men ble blokkert av tidligere herding som fryser disse prototypene.
For utviklere som vurderer egne KI-baserte revisjoner: Mozilla begynte med Claude Opus 4.6 og enkle prompts ikke ulike de som er publisert. Iterasjonen gikk på pipelinen rundt — parallellisering på efemerære VM-er, deduplisering mot kjente bugs, integrering med eksisterende fuzzing-infrastruktur. Mozillas anbefaling: start nå, og oppgradér modeller etter hvert.
Hva bør du gjøre?
- Start enkelt mot kjent risiko-kode: pek en agent mot 1-2 filer hvor du allerede har funnet bugs historisk. Be den finne en konkret feil og bygge et reproduserbart testcase.
- Bygg pipelinen rundt agenten, ikke prompten: deduplisering mot kjente bugs, automatisk reproduksjon, og triage-rute er det som skiller signal fra støy.
- Mål mot eksisterende forsvarslag: hvis modellen forsøker angrep og blir stoppet av herding du har gjort tidligere, er det et like verdifullt signal som å finne nye bugs.