Innhold Vis
Hvis du bruker Chrome, har AI allerede vært med på å gjøre nettleseren sikrere. Google rettet 1 072 sikkerhetsfeil i Chrome 149 og 150 – flere enn i de 23 foregående milepælene til sammen.
Det oppsiktsvekkende er ikke bare at en AI fant noen mystiske feil i en enorm kodebase. Google har bygget AI inn i nesten hele løpet: finne sårbarheten, fjerne støy fra rapporten, gjenskape feilen, vurdere alvorlighetsgrad, foreslå flere rettelser, skrive tester og sende saken til riktig utvikler.
Det er først når hele denne kjeden går raskere at tallene virkelig begynner å flytte på seg. Samtidig bør overskriften leses litt mer nøkternt enn «AI fikset alt». Google oppgir at språkmodeller lager forslag til rettelser for de fleste sårbarhetene, men selskapet sier ikke hvor mange av de 1 072 feilene som ble funnet av AI, hvor mange rettelser som ble skrevet av AI, eller hvordan resultatet ville sett ut uten systemene.
Hva har Google faktisk oppnådd?
Google oppgir at Chrome 149 og 150 fikk rettet 1 072 sikkerhetsfeil. Det er flere enn summen for de 23 foregående Chrome-milepælene. Selskapet anslår også at den automatiserte sorteringen sparer utviklerne for flere hundre arbeidstimer hver måned.
Formuleringen «i juni» trenger likevel en fotnote. Chrome 149 kom 2. juni med 429 sikkerhetsrettelser, mens Chrome 150 kom 30. juni med 433. De to første Stable-utgivelsene sto dermed for 862 rettelser. Googles høyere total på 1 072 bruker en bredere opptelling av de to milepælene enn disse lanseringstallene, og kan ikke uten videre beskrives som arbeid gjort bare i juni.
De 23 foregående milepælene tilsvarer omtrent to år med den tidligere fireukersrytmen. Det gjør sammenligningen voldsom, men ikke helt ren. Chrome er på vei over til en ny milepæl annenhver uke, og tallet sier «sikkerhetsfeil rettet», ikke 1 072 unike alvorlige CVE-er. Poenget står likevel: kapasiteten i sikkerhetspipelinen har økt dramatisk.
AI gjør mer enn å lete etter feil
Googles viktigste grep er at AI ikke er plassert i én pyntelig boks merket «bugjakt». Systemet følger hele livsløpet til en sårbarhet. En feil må oppdages, bekreftes, forstås, rettes, testes, slippes i en oppdatering og til slutt installeres hos brukeren. Hvis ett ledd henger etter, har angriperne fortsatt et vindu.
Innsendte rapporter går først gjennom et filter som luker ut spam, duplikater og saker som ikke beskriver en Chrome-sårbarhet. Deretter forsøker systemet å gjenskape feilen på riktig operativsystem og nettleserversjon. Det legger ved detaljer som stack traces, anslår når feilen kom inn i kodebasen, vurderer alvorlighetsgraden og ruter rapporten til riktig komponent og menneskelig eier.
Tidligere brukte en utvikler fra 5 til 30 minutter eller mer på å sortere én sikkerhetsrapport. Noen minutter høres ikke voldsomt ut før rapportene kommer i industriell skala. Tidlig i 2026 økte alle kategorier, og allerede i mars hadde Chrome-teamet mottatt flere rapporter enn i hele 2025.
Flere agenter foreslår og kontrollerer rettelsen
Når feilen er bekreftet, lager en retteagent flere forslag til kodeendringer. En egen kritikeragent vurderer dem, og de to går flere runder i en løkke som etterligner vanlig code review. Testagenter skriver og kjører tester på tvers av plattformene og konfigurasjonene Chrome støtter, før et menneske vurderer rettelsen.
Det er et langt mer interessant bruksområde enn en chatbot som spytter ut én patch og ønsker lykke til. Kritikerrollen har separat kontekst, og agentene må forholde seg til Chromium-stil, lokal kodepraksis og funksjonelle krav. Google hevder testarbeidet i enkelte tilfeller kan spare flere uker.
Opplegget ligner retningen Google DeepMind allerede har vist med CodeMender. Den agenten bruker blant annet debugger, statisk og dynamisk analyse, fuzzing og egne kritikere for å finne rotårsaken og kontrollere at en patch ikke skaper nye problemer. Det er også et konkret eksempel på hvordan AI blir mer nyttig når den må kontrollere arbeidet sitt, ikke bare formulere et sannsynlig svar.
En 13 år gammel feil viser hvorfor dette virker
Tidlig i 2026 brukte Google et agentoppsett med Gemini på en større del av Chrome-koden. Det fant blant annet en sandbox escape som hadde overlevd i kodebasen i mer enn 13 år. Feilen kunne la en kompromittert renderer lure nettleseren til å lese lokale filer.
Agenten får mer enn kildekoden. Google har laget en kunnskapsbase med tidligere CVE-er og hele Git-historikken til Chrome. Utviklere legger også inn SECURITY.md-filer som forklarer tillitsgrenser og trusselmodell. En separat kritiker leser denne informasjonen, og søket kan kjøres flere ganger fordi modellene ikke gir helt samme resultat hver gang.
Dette er egentlig kjernen. Modellen er bare én del av maskinen. Verktøy, historikk, dokumenterte sikkerhetsgrenser, gjentatte kjøringer, testing og menneskelig kontroll gjør en generell språkmodell om til et operativt sikkerhetssystem. Gemini er blitt en plattform inne i Googles produkter, og Chrome-saken viser hva den integrasjonen kan bety når den kobles til en konkret arbeidsflyt.
Hvor mye overlater Google til AI?
Ikke alt. Utviklere kan overstyre alvorlighetsgraden, og mennesker vurderer rettelsene før de går inn. Google sier også uttrykkelig at AI-basert oppdagelse kommer i tillegg til eksisterende sikkerhetstesting. Fuzzing er fortsatt spesielt godt egnet til feil som oppstår gjennom lange kjeder av hendelser i ulike deler av kodebasen.
Agentene får heller ikke herje fritt. Kildekoden analyseres på låste maskiner uten generell internettilgang. Nettverkskall fanges opp og kontrolleres mot strenge tillatelseslister, mens underagentene bare får endre og lese bestemte kildekodemapper. Dette er kjedelige detaljer helt til en kodeagent finner ut at internett er mer spennende enn oppgaven. Da er de plutselig hele sikkerhetsmodellen.
Jeg synes også det er verdt å skille Googles dokumenterte driftstall fra et kontrollert eksperiment. 1 072 rettelser og hundrevis av sparte timer er selskapets egne tall. Google publiserer ikke en kontrollgruppe, presise treffrater eller en full fordeling mellom AI, klassisk automatisering, eksterne forskere og menneskelige utviklere. Resultatet er sterkt, men det er ikke et bevis på at en modell alene kan vedlikeholde Chrome.
Flere funn skaper et nytt problem
Når AI finner feil raskere, flyttes flaskehalsen. Rapportene må fortsatt sorteres, rettelsene må testes, oppdateringene må ut og brukerne må faktisk starte nettleseren på nytt. Google sier triage, retting, testing og utgivelse kan ta 1-2 dager, mens ventetiden fram til en omstart kan bli en betydelig del av risikoen.
Derfor tester Chrome-teamet to sikkerhetsutgivelser i uken og går mot nye hovedversjoner annenhver uke. Google jobber også med dynamisk patching, der bakgrunnsprosesser som renderer og GPU erstattes med oppdaterte utgaver uten full omstart. På macOS kan Chrome 150 allerede starte seg selv på nytt når alle vinduer er lukket og programmet bare ligger i bakgrunnen.
Dette handler om «patch gap»: perioden fra en rettelse blir synlig i den åpne kildekoden til den faktisk beskytter maskinen din. Angripere kan lese endringen, forstå sårbarheten og lage et angrep før alle har oppdatert. Å finne feilen på rekordtid hjelper lite hvis den ferdige medisinen blir liggende på apoteket.
Hva betyr dette for vanlig programvareutvikling?
Chrome har en kodebase, infrastruktur og sikkerhetsstab få andre kan kopiere. Likevel er mønsteret overførbart: Gi agenten et avgrenset miljø, relevant historikk og eksplisitte sikkerhetsgrenser. La den lage flere forslag. Bruk en separat kritiker. Kjør faktiske tester, og la et menneske eie beslutningen.
Det er fristende å spørre hvilken Gemini-modell som gjorde jobben. Google nevner Gemini i agentoppsettet fra tidlig 2026, men sier samtidig at infrastrukturen støtter både åpne og proprietære modeller. Det smarte ligger nettopp der. En robust pipeline bør kunne bruke ulike modeller til det de er best på, uten å gjøre én modell til en magisk flaskehals.
For meg er dette en av de tydeligste AI-historiene i år fordi resultatet ikke er en benchmark eller en demo. Feilene er rettet i nettleseren folk faktisk bruker. Den nøkterne versjonen er samtidig den mest interessante: AI erstattet ikke sikkerhetsteamet. Den gjorde det mulig for sikkerhetsteamet å behandle et volum som tidligere ville stoppet i køen.
Flere rettede feil betyr ikke at Chrome er blitt dårligere
Et hopp i antall sikkerhetsfeil kan se skummelt ut. Det betyr ikke automatisk at Chrome plutselig er 1 072 ganger farligere. Når verktøyene leter grundigere, finner de mer gammelt grums, og når feilrettingen skalerer, kan flere funn bli med i en utgivelse.
Google fanget også mer enn 20 sårbarheter før produksjon i mai, inkludert én kritisk S1+-sak. CodeMender og Big Sleep er koblet til kontinuerlig integrasjon og kjører hvert døgn over nye kodeendringer. Målet er ikke bare å rydde lageret, men å oppdage feil nær tidspunktet de blir skrevet.
Det store skiftet er derfor ikke «AI fant en bug». Det har skjedd før. Skiftet er at Google nå har en løpende fabrikk for å finne, forstå, rette, teste og levere sikkerhetsendringer i enorm skala. Tallene fra Chrome 149 og 150 er det første virkelig håndfaste tegnet på hva en sånn fabrikk kan produsere.
Ofte stilte spørsmål
Rettet AI 1 072 Chrome-feil helt på egen hånd?
Nei. Google sier at språkmodeller lager forslag til rettelser for de fleste sårbarhetene, men mennesker vurderer arbeidet og kan overstyre klassifiseringer. Tallet omfatter resultatet fra hele sikkerhetspipelinen, ikke 1 072 helautomatiske patcher fra én modell.
Ble alle de 1 072 sikkerhetsfeilene rettet i juni?
Ikke slik Google dokumenterer tallet. Chrome 149 og 150 ble lansert 2. og 30. juni med henholdsvis 429 og 433 sikkerhetsrettelser. Totalen på 1 072 gjelder en bredere opptelling av de to milepælene samlet enn tallene i de første Stable-kunngjøringene.
Er Chrome tryggere fordi flere feil blir rapportert?
Flere rapporter er ikke i seg selv et faresignal. Bedre søk finner flere eksisterende feil. Sikkerhetsgevinsten kommer når funnene blir bekreftet, rettet, testet og installert før angripere rekker å utnytte dem.
Må Chrome fortsatt startes på nytt etter en sikkerhetsoppdatering?
Som regel blir oppdateringen tatt i bruk ved neste omstart. Google utvikler dynamisk patching som kan bytte ut bakgrunnsprosesser uten full omstart, men dette er fortsatt under utvikling. Chrome 150 har også fått automatisk omstart i en bestemt vindusløs tilstand på macOS.
