Google åpner Mantis: KI-agenter som finner og fikser sikkerhetshull selv

«Slurv i KI-skanning av kode fører ofte til hallusinerte feil og svake treffrater under 7 prosent.» — Nick Galloway og Yulong Zhang, sikkerhetsingeniører i Google

Den observasjonen er utgangspunktet for hele designet. Google skriver at de bygde Mantis rundt kjente agentteknikker som kritiker- og gjennomgangsagenter, kombinert med at hver påstått sårbarhet må reproduseres i en sandkasse før den regnes som ekte. Det er reproduksjonen som skiller Mantis fra en skanner som spytter ut lister: en feil som ikke lar seg utløse i sandkassen, slipper ikke gjennom.

Mantis leser også repoets egen historikk. Det går gjennom tidligere sikkerhetsfikser for å lære hva slags feil som faktisk har oppstått i akkurat denne kodebasen, og bygger opp arkitektur- og trusselmodelldokumentasjon selv om ingen har skrevet den. For å håndtere store repoer bygger det et hierarkisk sammendragstre: enkeltfiler kondenseres til katalognivå og videre til rotnivå. Google oppgir at dette kuttet token-forbruket med over 85 prosent uten å miste den strukturelle konteksten.

Oppstarten er kortere enn du forventer av et sikkerhetsverktøy fra Google. Du kloner repoet lokalt, åpner kodeagenten du allerede bruker, og ber den om hjelp til å bruke Mantis mot koden din. Google skriver at akkurat den prompten er den de bruker internt til å finne ekte sårbarheter på tvers av sine egne repoer. Repoet inneholder eksempler på sandkasseoppsett, men du kan koble på ditt eget.

Når du først har fått KI-oppdagede sårbarheter ut av systemet, peker Google videre til en ferdighet de kaller mantis-advise. Den tar den akkumulerte kunnskapen om hva som har gått galt og mater den tilbake til kodeagentene dine, slik at de skriver sikrere kode i første omgang i stedet for å bli ryddet opp etter.

To råd fra teamet er verdt å ta med seg uavhengig av om du kjører Mantis. Det ene er å gi verktøyet riktig kontekst: Mantis leser commit-historikk og kode selv, men menneskelig kuratert kunnskap forbedrer resultatet kraftig. Vet du at feil der brukeren bare kan krasje sitt eget program aldri er verdt å fikse hos deg, er det kritisk informasjon for skannepipelinen. Det andre er å bygge en sandkasse med klare akseptkriterier for hva som teller som en reprodusert sårbarhet, både for å luke ut støy og for å bekrefte at fiksene faktisk virker.

Hva bør du gjøre?

1. Klon Mantis-repoet og kjør det mot et av dine egne prosjekter med kodeagenten du allerede bruker. Oppsettet krever ingen egen pipeline.
2. Skriv ned hvilke feilklasser du ikke bryr deg om før du kjører, og gi listen til verktøyet. Uten den drukner du i treff du uansett ikke ville fikset.
3. Definer hva som teller som en reprodusert sårbarhet i sandkassen din, slik at du kan verifisere at en foreslått patch faktisk lukker hullet.