A Google szerint a mesterséges intelligencia alapjaiban alakítja át a Chrome biztonsági fejlesztését: a Chrome 149 és Chrome 150 kiadásokban összesen 1072 biztonsági hibát javítottak, ami több, mint amennyi sérülékenységet az azt megelőző 23 nagy Chrome-verzióban összesen korrigáltak.
A látványos növekedés nem azt jelenti, hogy a Chrome hirtelen kevésbé biztonságossá vált. Sokkal inkább azt mutatja, hogy a Google AI-alapú rendszerei olyan mennyiségben képesek sérülékenységeket felkutatni, elemezni és javításra előkészíteni, amelyet kizárólag emberi szakértőkkel rendkívül nehéz lenne kezelni.
A vállalat ma már szinte a teljes sérülékenység-kezelési életciklusban alkalmaz nagy nyelvi modelleket.
A mesterséges intelligencia segít:
- sérülékenységeket keresni;
- beérkező hibajelentéseket ellenőrizni;
- proof-of-concept kódokat reprodukálni;
- meghatározni a sérülékenységek súlyosságát;
- azonosítani az érintett Chrome-komponenst;
- javítási javaslatokat készíteni;
- valamint regressziós teszteket generálni.
A Google ezen túl biztonsági AI-ügynököket épít közvetlenül a Chrome folyamatos integrációs, vagyis CI-infrastruktúrájába is, így bizonyos biztonsági problémákat már azelőtt megpróbál felismerni, hogy az érintett kód bekerülne a böngésző végleges forrásfájába.
Az AI jelentősen kibővítette a Chrome sérülékenység-keresési képességeit
A Google több éve dolgozik azon, hogy a nagy nyelvi modelleket hagyományos biztonsági tesztelési technológiákkal kombinálja.
A Chrome Security Team 2023-ban kezdte intenzívebben alkalmazni az LLM-eket a fuzzing hatékonyságának és lefedettségének növelésére.
A fuzzing során egy rendszer hatalmas mennyiségű szokatlan, hibásan formázott vagy véletlenszerű bemenetet juttat a vizsgált alkalmazásba, majd figyeli, hogy ezek összeomlást, memóriahibát vagy más rendellenes működést váltanak-e ki.
Az ilyen rendellenességek gyakran biztonsági sérülékenység jelenlétére utalnak.
A hagyományos fuzzerek elképesztően sok tesztet képesek lefuttatni, de bizonyos összetett adatstruktúrák vagy hosszabb műveletsorok létrehozásában korlátozottabbak lehetnek.
A nagy nyelvi modellek ezzel szemben képesek értelmezni a forráskódot, a fájlformátumok logikáját és a program várható működését, így célzottabb tesztbemeneteket generálhatnak és olyan kódrészeket érhetnek el, amelyeket a hagyományos mutációs fuzzing nehezebben talál meg.
A Naptime-tól a Big Sleepig
2024-ben a Google Project Zero létrehozta a Naptime kutatási környezetet, amely speciális eszközöket adott az AI-modelleknek a sérülékenységkutatáshoz.
Ahelyett, hogy egy modell pusztán egy forráskódot kapott volna elemzésre, egy ügynöki folyamat részeként dolgozhatott.
Képes volt például:
- hipotézist felállítani;
- forráskódot vizsgálni;
- programokat futtatni;
- hibákat reprodukálni;
- debuggerrel elemezni az összeomlást;
- Python-kódot írni;
- majd az eredmények alapján módosítani a saját vizsgálati stratégiáját.
Ez azért lényeges, mert a generatív AI egyik komoly problémája, hogy pusztán statikus kódelemzés alapján olyan elméleti hibákat is sérülékenységként azonosíthat, amelyek a valóságban nem használhatók ki.
Az eszközökkel felszerelt ügynök ezzel szemben megpróbálhatja ténylegesen bizonyítani a hiba létezését.
A Google DeepMind és a Project Zero ezt követően fejlesztette ki a Big Sleep AI-alapú sérülékenységkutató ügynököt, amely többek között a Chrome V8 JavaScript-motorjában és grafikus komponenseiben is talált hibákat.
2026 elején a Google egy Gemini-alapú ügynöki keretrendszerrel tovább bővítette ezt a technológiát, hogy a Chrome forráskódjának jóval nagyobb részét lehessen automatikusan elemezni, miközben csökkentik a téves pozitív találatok számát.
A Gemini egy több mint 13 éve rejtőző Chrome sandbox hibát is megtalált
Az új AI-alapú rendszer egyik legérdekesebb felfedezése egy olyan sandbox escape sérülékenység volt, amely több mint 13 éve jelen volt a Chrome kódbázisában.
A Chrome sandbox a böngésző egyik legfontosabb biztonsági védelmi mechanizmusa.
A webes tartalmak jelentős része korlátozott renderer folyamatokban fut. Ha egy támadó például egy memóriahibán keresztül átveszi egy renderer irányítását, a sandbox feladata az, hogy megakadályozza a támadót abban, hogy közvetlenül hozzáférjen az operációs rendszer érzékeny erőforrásaihoz.
Ezért egy sandbox escape gyakran kulcsfontosságú második elem egy teljes Chrome exploit chainben.
A Google szerint az AI által megtalált, hosszú ideje jelen lévő hiba lehetővé tehette egy már kompromittált renderer számára, hogy megtévessze a böngészőt, és helyi fájlokat olvastasson be vele.
Különösen figyelemre méltó, hogy a hibás kód több mint egy évtizeden keresztül túlélte a Chrome hagyományos kódellenőrzését, fuzzing infrastruktúráját, statikus elemzéseit és külső biztonsági kutatók vizsgálatait.
Ez arra utal, hogy az AI-alapú elemzés egyik komoly előnye éppen a régi feltételezések újraértékelése lehet.
A Google saját Chrome-biztonsági tudásbázist épített az AI számára
A modellek nem kizárólag az eredeti betanítás során megszerzett ismereteikre támaszkodnak.
A Google létrehozott egy Chrome-specifikus tudásbázist, amely többek között tartalmazza:
- a Chrome teljes Git-előzményeit;
- a korábban azonosított CVE-ket;
- régi biztonsági javításokat;
- valamint a kódbázis változásainak történetét.
Ennek segítségével a modellek összehasonlíthatják a jelenlegi kódot korábbi biztonsági javításokkal, felismerhetik a visszatérő sérülékenységi mintákat és jobban megérthetik a böngésző architektúrájának fejlődését.
A Google emellett arra ösztönzi a Chromium fejlesztőit, hogy az egyes komponensekhez SECURITY.md fájlokat készítsenek.
Ezekben dokumentálhatók például:
- a komponens biztonsági határai;
- a threat model;
- a megbízható és nem megbízható adatforrások;
- valamint a biztonságkritikus műveletek.
Ez rendkívül fontos egy AI-rendszer számára, mert a forráskódból önmagában nem mindig derül ki, hogy egy művelet valóban átlép-e egy biztonsági határt.
Egy külön „critic” ügynök ezeket a biztonsági dokumentumokat is felhasználhatja a sérülékenységi találatok és a javasolt javítások ellenőrzésekor.
Ugyanazt a kódot többször is megvizsgálják
A generatív modellek nem determinisztikusak.
Ez azt jelenti, hogy ugyanaz a modell ugyanarra a kódra két külön futtatás során nem feltétlenül pontosan ugyanazt az eredményt adja.
A Google ezt nem csupán problémának, hanem lehetőségnek is tekinti.
A Chrome kódbázisának egyes részeit ezért többször is megvizsgálják AI-modellekkel.
Egy újabb futtatás:
- más kódútvonalat vizsgálhat;
- más hipotézist állíthat fel;
- vagy olyan problémát találhat, amelyet az előző elemzés kihagyott.
A kódbázis ráadásul újra elemezhető akkor is, amikor egy újabb, fejlettebb modell válik elérhetővé.
Az AI nem váltja le sem a fuzzingot, sem az emberi szakértőket
A Google hangsúlyozza, hogy az AI nem helyettesíti a Chrome meglévő biztonsági infrastruktúráját.
A fuzzing továbbra is különösen hatékony olyan problémák felismerésében, amelyek hosszú műveletsorokat vagy a kódbázis egymástól távol lévő részei közötti összetett interakciókat igényelnek.
Az AI ehhez egy újabb elemzési réteget ad.
Képes:
- értelmezni a kód szándékát;
- kommenteket és dokumentációt használni;
- egymástól távoli kódrészletek között kapcsolatot keresni;
- vagy felismerni, hogy egy látszólag ártalmatlan változtatás más komponenssel együtt biztonsági problémát idézhet elő.
A végső döntés azonban továbbra is emberi fejlesztő kezében marad.
Az AI javítási javaslatokat és teszteket készíthet, de a kódot emberi szakértő ellenőrzi, mielőtt az bekerülne a Chromium projektbe.
Több AI-ügynök dolgozik együtt a biztonsági javításokon
A sérülékenység igazolása után egy többügynökös folyamat veszi át a javítás előkészítését.
Egy úgynevezett fixing agent megkapja a biztonsági hibával kapcsolatos információkat, majd több lehetséges javítást készít.
Ezután egy külön critic agent értékeli ezeket.
A két rendszer iteratív módon együtt dolgozhat:
- a fixing agent javítást készít;
- a critic agent megkeresi annak hibáit vagy hiányosságait;
- a fixing agent módosítja a megoldást;
- újabb ellenőrzés következik;
- végül tesztelő ügynökök regressziós teszteket generálnak.
A Google szerint ezek a tesztíró ügynökök a Chrome által támogatott különböző platformokon és konfigurációkon is ellenőrizhetik a javításokat még azelőtt, hogy egy emberi fejlesztő megkezdené a végső felülvizsgálatot.
Bizonyos esetekben ez akár hetekkel csökkentheti a manuális fejlesztési munkát.
Chrome 149 és 150: összesen 1072 biztonsági hiba javítva
A Google közlése szerint jelenleg már a Chrome-sérülékenységek többségénél LLM-ek is készítenek lehetséges javításokat.
Ennek hatása a javítások számán is jól látható.
A Chrome 149 és Chrome 150 kiadásokban összesen 1072 biztonsági hibát javítottak.
Ez több, mint az azt megelőző 23 Chrome Stable mérföldkőben összesen kijavított biztonsági hibák száma.
A számot azonban érdemes megfelelően értelmezni.
Ez nem 1072 darab kritikus, távolról kihasználható zero-day sérülékenységet jelent.
A biztonsági hibák között jelentős eltérések lehetnek:
- súlyosságban;
- kihasználhatóságban;
- elérhetőségben;
- szükséges előfeltételekben;
- és abban is, hogy egyáltalán eljutottak-e valaha production környezetbe.
A Google nem közölt részletes súlyossági bontást mind az 1072 problémáról.
A szám elsősorban azt mutatja, hogy az AI jelentősen megnövelte azt a mennyiséget, amelyet a Chrome Security Team képes feldolgozni.
A Big Sleep és CodeMender már közvetlenül a CI-rendszer része
A Google DeepMind és a Project Zero Big Sleep és CodeMender rendszerei mára közvetlenül integrálódtak a Chrome folyamatos integrációs rendszerébe.
A biztonsági AI-k 24 óránként lefutnak a Chrome kódváltozásain, és még azelőtt keresnek sérülékenységeket, hogy azok production környezetbe kerülhetnének.
A Google szerint csak 2026 májusában több mint 20 sérülékenységet akadályoztak meg abban, hogy eljusson a felhasználókhoz.
Ezek között egy S1+ kategóriájú kritikus biztonsági probléma is szerepelt.
Az AI a beérkező hibajelentések feldolgozását is automatizálja
A több sérülékenység egy másik problémát is létrehozott: valakinek minden egyes jelentést ellenőriznie kell.
A Google szerint 2026 elején drasztikusan emelkedett a Chrome Security Teamhez érkező hibajelentések száma.
Márciusra több jelentés érkezett, mint 2025 egészében összesen.
Korábban egyetlen biztonsági jelentés triázsa általában 5–30 percet, egyes esetekben ennél is több időt igényelt egy tapasztalt mérnöktől.
A Google ezért részben automatizálta a folyamatot.
Az új rendszer négy fő lépést végez el.
1. Kiszűri a zajt
Megvizsgálja, hogy a beküldött jelentés:
- spam-e;
- duplikáció-e;
- megfelel-e a Chrome VRP feltételeinek;
- illetve valóban biztonsági problémát ír-e le.
2. Megpróbálja reprodukálni a hibát
Ha rendelkezésre áll proof-of-concept, a rendszer megpróbálja azt az érintett Chrome- és operációsrendszer-verzión reprodukálni.
Sikeres reprodukció esetén például stack trace információkat adhat a jelentéshez.
3. Metaadatokkal egészíti ki
Megpróbálja meghatározni többek között:
- mikor került a sérülékenység a kódba;
- milyen súlyosságú;
- mely platformokat érinti.
A fejlesztők továbbra is felülbírálhatják az automatikusan megállapított súlyosságot.
4. Automatikusan a megfelelő csapathoz irányítja
Az azonosított problémát a rendszer a megfelelő Chrome-komponenshez és felelős fejlesztőhöz rendeli.
A Google becslése szerint ez a folyamat havonta több száz fejlesztői munkaórát takarít meg.
Az AI a Chrome Vulnerability Reward Programot is megváltoztatja
A mesterséges intelligencia által generált biztonsági jelentések rohamos növekedése a külső kutatók számára működtetett Chrome Vulnerability Reward Programot is érinti.
Egyre könnyebbé válik ugyanannak a viszonylag egyszerű hibának több független AI-rendszerrel történő megtalálása.
Emellett növekszik a:
- spekulatív;
- nem reprodukálható;
- bizonyíték nélküli;
- vagy már ismert hibát újra jelentő submissionök száma.
A Google ezért módosította VRP-feltételeit, és egyre inkább azokat a jelentéseket szeretné ösztönözni, amelyek valódi hozzáadott értéket jelentenek ahhoz képest, amit saját automatizált rendszerei már képesek megtalálni.
Ez nem jelenti a humán biztonsági kutatók szerepének végét.
Éppen ellenkezőleg: a vállalat szerint a külső szakértők kreativitása továbbra is különösen értékes a legösszetettebb és legnagyobb hatású problémák megtalálásában.
Az AI felgyorsítja a patch gap problémáját is
A sérülékenységek gyorsabb megtalálása és kijavítása önmagában még nem védi meg a felhasználót.
A frissítésnek el is kell jutnia a számítógépére.
A Chromium nyílt forráskódú projekt, ezért amikor egy biztonsági javítás bekerül a publikus forráskódba, egy támadó összehasonlíthatja a javítás előtti és utáni állapotot.
Ebből megpróbálhatja visszafejteni:
- hol volt a sérülékenység;
- hogyan működött;
- és hogyan lehet azt kihasználni.
Ha a javítás eközben még nem érkezett meg minden felhasználóhoz, létrejön az úgynevezett patch gap.
Ebben az időszakban a hiba már ismert vagy kikövetkeztethető, de a felhasználók egy része még mindig a sérülékeny kódot futtatja.
Az ilyen hibákat kihasználó támadásokat gyakran N-day támadásoknak nevezik.
A Google heti két Chrome biztonsági frissítést is tesztel
A Chrome ezért nemcsak a sérülékenységkutatást gyorsítja, hanem a javítások kiadását is.
A Google már megkezdte az átállást a kéthetes nagy Chrome milestone ciklusra, amely mellett heti security update-eket tervez.
A vállalat szerint azonban az AI-alapú támadások gyorsasága miatt még ez sem feltétlenül lesz elég.
Ezért a Chrome Security Team jelenleg azt is teszteli, hogy hetente két külön biztonsági frissítést adjon ki.
A cél egyértelmű:
minél rövidebb idő teljen el a sérülékenység azonosítása, a javítás elkészítése és a frissítés felhasználókhoz történő eljuttatása között.
Már a CVE-leírások elkészítését is automatizálnák
A Google dolgozik a biztonsági kiadási jegyzetek és CVE-leírások automatikus létrehozásán is.
Ez első pillantásra adminisztratív részletnek tűnhet, de nagy mennyiségű biztonsági hiba esetén a dokumentáció elkészítése is szűk keresztmetszetté válhat.
Ha a technikai javítás már elkészült, de a hozzá kapcsolódó:
- disclosure;
- release note;
- CVE-leírás;
- vagy biztonsági dokumentáció
napokkal később készül el, az lassíthatja a teljes folyamatot.
A Google célja ezért az, hogy a manuális adminisztráció minél kevésbé késleltesse a biztonsági javítások publikálását.
A következő probléma: a felhasználók nem indítják újra a Chrome-ot
A Chrome 2008 óta automatikusan tölti le a frissítéseket a háttérben.
A frissített kód azonban hagyományosan csak akkor válik aktívvá, amikor a böngészőt újraindítják.
Ez egyre nagyobb biztonsági problémává válik.
A Google szerint ha a sérülékenység triázsa, javítása, tesztelése és kiadása már mindössze 1–2 nap alatt megtörténhet, akkor a felhasználó által napokig halogatott újraindítás a teljes sebezhetőségi időablak jelentős részét teheti ki.
Sokan azonban érthető okból nem akarják újraindítani a böngészőt:
- több tucat nyitott lapjuk lehet;
- webalkalmazásokban dolgozhatnak;
- folyamatban lévő munkameneteik lehetnek;
- vagy egyszerűen nem akarják megszakítani a munkát.
A Google ezért azt szeretné, ha a frissítések aktiválása egyre kevésbé függne a felhasználói döntéstől.
Jön a „dynamic patching”
A vállalat egyik legérdekesebb fejlesztése az úgynevezett dynamic patching.
A tervek szerint sok Chrome-frissítést a jövőben anélkül lehetne aktiválni, hogy a teljes böngészőt újra kellene indítani.
A Chrome többfolyamatos architektúráját kihasználva a rendszer fokozatosan lecserélhetné a háttérben futó child processzeket.
Ilyenek például:
- a renderer folyamatok;
- a GPU-folyamat;
- valamint más elkülönített Chrome-komponensek.
A régi folyamat leállna, majd már az új, frissített binárisból indulna újra.
Így bizonyos javítások fokozatosan életbe léphetnének a teljes böngésző bezárása nélkül.
A technológia még fejlesztés alatt áll, és nem minden frissítés esetében lesz használható.
A böngésző főfolyamatát vagy inkompatibilis belső struktúrákat érintő módosítások továbbra is teljes újraindítást igényelhetnek.
Chrome 150: automatikus újraindítás macOS-en
A Google már bevezetett egy korai megoldást Chrome 150 alatt macOS rendszereken.
A macOS sajátossága, hogy egy alkalmazás a háttérben tovább működhet akkor is, amikor az összes ablaka bezárult.
Ha a Chrome ebben az ablak nélküli állapotban észleli, hogy frissítés vár aktiválásra, automatikusan újraindíthatja magát, így a felhasználó munkájának megszakítása nélkül életbe léphet az új verzió.
A Google hosszabb távú célja egy olyan böngésző létrehozása, amely gyakorlatilag folyamatosan naprakész:
- dinamikusan patch-elhető;
- megfelelő pillanatban automatikusan újraindul;
- és a lehető legkevesebb felhasználói beavatkozást igényli.
Az AI-ügynökök maguk is komoly biztonsági kockázatot jelenthetnek
A Google külön kitért arra is, hogyan próbálja korlátozni saját biztonsági AI-ügynökeinek működését.
Ez különösen fontos, mivel a sérülékenységkereső rendszerek:
- érzékeny forráskódhoz férnek hozzá;
- exploitálható hibákat vizsgálnak;
- kódot futtathatnak;
- és biztonsági javításokat generálhatnak.
A Chrome kódját vizsgáló modellek ezért lezárt környezetben, általános internetelérés nélkül működnek.
A Google szerint:
- minden hálózati kérést ellenőriznek;
- alkalmazás- és célállomás-alapú allowlisteket használnak;
- a gyanús kommunikációt blokkolják;
- az AI-modelleket nem futtatják korlátozás nélküli módban;
- az alügynökök nem módosíthatják szabadon a rendszert;
- és kizárólag az engedélyezett forráskód-könyvtárak fájljaihoz férhetnek hozzá.
Ez jól mutatja, hogy az AI-alapú sérülékenységkutatásnál nemcsak az számít, mire képes a modell, hanem az is, milyen technikai korlátok között működik.
A Chrome továbbra is komoly memória-biztonsági átalakítást végez
A Google szerint az AI által megtalált nagy mennyiségű hiba megerősítette, hogy hosszú távon nem elegendő egyenként kijavítani a sérülékenységeket.
Egész hibakategóriákat kell megszüntetni.
A Chromium kódbázis túlnyomó része jelenleg még mindig C++ nyelven íródott, ahol a memória-biztonsági hibák különösen jelentős támadási felületet jelentenek.
A Chrome ezért több irányból próbálja csökkenteni ezeket.
A Google többek között továbbfejleszti a MiraclePtr és MiracleObject technológiákat a use-after-free problémák visszaszorítására, és nagyszabású „spanification” programot folytat a pointer + méret típusú régi C++ konstrukciók std::span típusokra történő átalakítására.
A Google szerint jelenleg az első fél által írt Chrome-kód 97%-a már megfelel a szigorú unsafe-buffer fordítási ellenőrzéseknek.
Hosszabb távon a vállalat egyre több komponenst kíván memória-biztonságos nyelvekre, elsősorban Rust nyelvre átállítani.
Különösen olyan „bug nest” területeket céloznak, amelyek történelmileg sok biztonsági problémát okoztak, például:
- komplex parsereket;
- képkodekeket;
- betűtípus-feldolgozó komponenseket.
Több mint 2300 külső függőség is a Chrome része
A Chrome biztonsági kihívása nem ér véget a Google saját forráskódjánál.
A Chromium és a hozzá kapcsolódó projektek — például a V8, BoringSSL, Skia, ANGLE és Dawn — több mint 2300 külső függőséget használnak.
Ezek közül körülbelül 1700 valamilyen formában eljut a felhasználókhoz.
A Google ezért 2026-ban elkezdte ezeket a third-party dependency-ket fokozatosan automatikus frissítési folyamatokra átállítani.
A cél, hogy a Chrome ne csupán akkor frissítsen egy külső komponenst, amikor már ismert CVE jelenik meg hozzá, hanem lehetőség szerint folyamatosan kövesse annak legújabb biztonságos upstream verzióját.
Mit jelent mindez a vállalatok számára?
A Google AI-alapú biztonsági fejlesztései nem szüntetik meg a vállalati patch management szükségességét.
Sőt, éppen ellenkezőleg.
Minél gyorsabban képes a Google:
- megtalálni;
- kijavítani;
- publikálni
egy sérülékenységet, annál fontosabb, hogy a végpontokon is gyorsan aktiválódjon a javított Chrome-verzió.
A vállalati rendszergazdáknak ezért érdemes:
- központilag figyelniük a Chrome-verziókat;
- felderíteniük az elavult végpontokat;
- ellenőrizniük, hogy az automatikus frissítés valóban működik-e;
- és korlátozniuk a felhasználók lehetőségét a böngésző újraindításának hosszú ideig történő halasztására.
A Google kifejezetten javasolja a RelaunchNotification vállalati házirend használatát.
Ezzel a rendszer kezdetben csak emlékeztetheti a felhasználót a szükséges újraindításra, majd egy előre meghatározott időszak után kötelezővé teheti azt.
Különösen érzékeny vállalati környezetekben továbbra is használható a Chrome Extended Stable Channel, ha a szervezet számára fontosabb a hosszabb kompatibilitási tesztelési idő.
Ennek azonban ára van: a lassabb verzióváltás növelheti az ismert sérülékenységeknek való kitettségi időt.
Az AI korszakában nem feltétlenül a hibák megtalálása lesz a legnagyobb probléma
A Google bejelentésének talán legfontosabb tanulsága nem maga az 1072-es szám.
A sérülékenységkutatás eddig egyik legnagyobb korlátja az volt, hogy rendkívül sok magasan képzett szakemberi időt igényelt.
Az AI ezt a szűk keresztmetszetet részben megszüntetheti.
Ha azonban automatizált rendszerek ezrével kezdenek új sérülékenységeket találni, a probléma egyszerűen továbbtolódhat a következő fázisokra.
Valakinek továbbra is:
- ellenőriznie kell a találatokat;
- meg kell határoznia a valós kockázatot;
- megfelelő javítást kell készítenie;
- regressziós teszteket kell futtatnia;
- ki kell adnia a frissítést;
- és végül biztosítania kell, hogy azt a felhasználók rendszerei ténylegesen telepítsék és aktiválják.
A Google ezért nem egyszerűen egy „AI bug finder” rendszert épít.
A teljes sérülékenység-kezelési folyamat automatizálásán dolgozik a felfedezéstől egészen a frissítés aktiválásáig.
Az eredmények alapján pedig a változás már nem kísérleti.
A Chrome 149 és 150 során kijavított 1072 biztonsági hiba egyértelműen jelzi, hogy a mesterséges intelligencia a sérülékenységkutatásból fokozatosan a mindennapi szoftverbiztonsági mérnöki munka részévé válik.
Ez azonban egyben új versenyfutást is jelent.
Ugyanazok a technológiák, amelyekkel a Google gyorsabban fedezheti fel a sebezhetőségeket, a támadóknak is segíthetnek nyilvánosságra került patch-ek elemzésében és exploitok készítésében.
Ezért a következő évek egyik legfontosabb kiberbiztonsági kérdése már nem pusztán az lesz, hogy ki találja meg először a sérülékenységet, hanem az is, hogy a védők képesek-e gyorsabban kijavítani és telepíteni a patch-et, mint ahogy a támadók fegyverré alakítják ugyanazt a hibát.
A Chrome-felhasználók számára ebből egy nagyon egyszerű következtetés adódik:
az automatikus frissítést érdemes engedélyezve tartani, és amikor a Chrome újraindítást kér egy frissítés aktiválásához, azt nem célszerű napokig halogatni.
Az AI segíthet a Google-nek rekordsebességgel megtalálni és kijavítani a biztonsági hibákat — de a javítás csak akkor védi meg a felhasználót, amikor a frissített kód már ténylegesen fut a gépén.
