Náprava zranitelností pomocí AI: co zvládnou pull requesty s AI opravami

Co je náprava pomocí AI

Náprava zranitelností pomocí AI využívá jazykový model k vytvoření opravy známé zranitelnosti. Má tři podoby:

• Návrhy oprav kódu. Model navrhne patch vedle výstrahy ze statické analýzy. GitHub Copilot Autofix například „automaticky generuje návrhy změn kódu pro výstrahy CodeQL nalezené v pull requestech a ve výchozí větvi“.
• Upgrady závislostí, které upraví kód. Zvýšit verzi je snadné. Těžké jsou přejmenované funkce nebo změněné výchozí hodnoty, které nová verze přináší. Model dokáže tyto navazující změny provést ve stejném pull requestu.
• Agentní náprava. Agent provede opravu několika kroky sám: změní kód, spustí build a testy, přečte chyby, zkusí to znovu a pull request otevře, až když checky projdou.

Kde se AI opravy vyplatí

Aktualizační boti založení na pravidlech už dnes otevírají pull requesty, které zvednou zranitelný balíček na opravenou verzi. Zaseknou se, když upgrade něco rozbije, protože úprava volajícího kódu není pravidlo. Právě tam se hromadí backlog: bezpečnostní aktualizace, která zůstává měsíce otevřená, protože nikdo nemá čas projít změnu hlavní verze.

Přečíst changelog, najít místa volání a přepsat je, to je přesně práce, kterou jazykové modely zvládají dobře. AI oprava, která přijde s upgradem i změnami kódu, sestavená a otestovaná, promění týden něčí pozornosti v jedno review.

Kde AI opravy chybují

Nejjasněji popisují limity sami dodavatelé. O Copilot Autofix GitHub píše:

• „Používá generativní model, který je nedeterministický. I při stejné výstraze a stejném kódu nemusí vytvořit použitelný návrh, nebo se návrh může mezi pokusy lišit.“
• „Systém neví, které verze závislostí jsou podporované nebo bezpečné, a může navrhovat smyšlené závislosti publikované pod statisticky pravděpodobnými názvy.“

Druhý bod není hypotetický. Výzkum modelů generujících kód změřil, jak často doporučují balíčky, které neexistují: názvy, které si útočník může zaregistrovat a naplnit malwarem. Oprava, která nainstaluje halucinovaný balíček, nahradí jednu zranitelnost horší.

Většinu rizika pokrývají tři pojistky:

1. Každou opravu sestavte a otestujte dřív, než ji zkontroluje člověk, aby čas na review šel na opravy, které fungují.
2. Každý přidaný nebo změněný balíček ověřte proti registru a proti verzi, kterou očekáváte.
3. O merge ať rozhoduje člověk. AI oprava je pull request přispěvatele, ne rozhodnutí.

Co dovnitř, to pull requesty ven

Nástroj pro nápravu pomocí AI opravuje zranitelnosti, které dostane. Pokud je tento seznam rekonstruovaný z lockfilů nebo naskenovaného image, zdědí každou mezeru v rekonstrukci: nástroje, které build stahuje a které žádný manifest nedeklaruje, verze, které se liší od toho, co build vyřešil, balíčky obnovené z cache. Nástroj pak otevírá sebevědomé pull requesty pro některé zranitelnosti a o jiných se nikdy nedozví.

Některé týmy jdou ještě dál a nechají model, aby závislosti odvodil sám. Tím se stane nedeterministickým i inventář, tedy ta jediná část procesu, která má vycházet pokaždé stejně. Proč odhadnutý inventář není důkaz, vysvětluje článek SBOM generované AI.

Funguje vzor, kde dole leží deterministická data a nahoře úsudek AI: zaznamenaný seznam toho, co každý build skutečně obsahuje, porovnaný s bezpečnostními upozorněními prostým vyhledáním, a AI, která píše opravu.

Kam zapadá CRACI

CRACI je deterministická vrstva. Spouští vaše joby GitHub Actions na vlastních runnerech a zaznamenává balíčky, které každý job skutečně stáhl, včetně tranzitivních závislostí a balíčků obnovených z cache, se stavem úplnosti pro každý job. Monitorované SBOM průběžně znovu vyhodnocuje, takže nové bezpečnostní upozornění se objeví u buildů, kterých se týká, a bezpečnostní týmy u každého nálezu provedou triáž a pošlou ho týmu, který opravu vlastní.

To je seznam, ze kterého by AI oprava měla vycházet, a po merge opravy SBOM dalšího buildu ukáže, zda build skutečně použil opravenou verzi. Celou funkci popisuje sledování zranitelností a kam který přístup patří, rozebírá AI vs deterministická bezpečnost.

Náprava zranitelností pomocí AI: časté dotazy

Co je náprava zranitelností pomocí AI?

Náprava zranitelností pomocí AI využívá jazykový model k vytvoření opravy zranitelnosti: změny kódu pro nález ze statické analýzy, nebo upgradu závislosti spolu se změnami kódu, které upgrade vyžaduje. Výstupem je obvykle návrh nebo pull request, který zkontroluje člověk.

Co je agentní náprava?

Agentní náprava dává AI agentovi nástroje, aby opravu samostatně provedl několika kroky: přečte nález, změní kód, spustí build a testy a opakuje to, dokud neprojdou, a pak otevře pull request. Oproti jednorázovému návrhu agent svou práci sám ověří dřív, než ji uvidí člověk.

Je bezpečné mergovat bezpečnostní opravy vygenerované AI?

Přistupujte k nim jako k pull requestu od kteréhokoli jiného přispěvatele. GitHub popisuje Copilot Autofix jako nedeterministický a varuje, že může navrhovat smyšlené závislosti. Změnu proto zkontrolujte, spusťte testy a ověřte, že každý balíček, který přidává, existuje a je ten, který očekáváte.

Dokáže AI najít zranitelnosti v závislostech?

Na tuto část je to nesprávný nástroj. Zda je verze balíčku zasažena známým bezpečnostním upozorněním, je otázka vyhledání a výsledek má vyjít pokaždé stejně. Seznam zranitelných balíčků nechte vytvořit deterministické nástroje ze zaznamenané SBOM a AI použijte tam, kde pomáhá úsudek: při psaní a úpravě opravy.

Co nástroj pro nápravu pomocí AI potřebuje, aby dobře fungoval?

Přesný seznam toho, co je skutečně zranitelné, build a sadu testů, proti kterým může opravu spustit, a člověka, který rozhoduje o merge. Nejčastěji chybí to první: pull request s opravou balíčku, který produkt vůbec nedodává, je šum, a zranitelný balíček, který inventář přehlédl, opravu nikdy nedostane.