Automatizovaná náprava zranitelností, od nálezu k opravě

Co znamená automatizovaná náprava zranitelností

Náprava zranitelnosti znamená odstranit známou zranitelnost z vašeho softwaru: aktualizovat dotčený balíček, použít patch nebo nahradit komponentu. Automatizovaná náprava předává mechanickou část této práce softwaru. Přečte nález, zjistí, která verze ho opravuje, změní manifest, lockfile nebo kód a navrhne změnu, nejčastěji jako pull request.

U závislostí třetích stran, kde se nachází většina známých zranitelností moderního kódu, vypadá tento cyklus v každém nástroji stejně:

1. Inventář. Vědět, které balíčky v jakých verzích jsou v každé věci, kterou dodáváte.
2. Porovnání. Porovnat inventář s bezpečnostními upozorněními a porovnávat dál, jak vycházejí nová.
3. Priority. Rozhodnout, co opravit nejdřív, podle závažnosti, zneužívání a expozice.
4. Oprava. Vybrat opravenou verzi, aktualizovat ji a upravit kód, pokud aktualizace něco rozbije.
5. Ověření. Sestavit a otestovat změnu a pak potvrdit, že se skutečně dodala opravená verze.
6. Záznam. Uchovat stopu toho, co bylo zasaženo, kdy se to opravilo a v jakém vydání.

Automatizace je nejsilnější v krocích 2, 4 a 6, kde se práce opakuje. Nejslabší je tam, kde jsou vstupy chybné, a vstupem pro všechno ostatní je krok 1.

Čtyři druhy automatizované nápravy

Přístup	Co dělá	Příklady	Kde končí
Boti pro aktualizace závislostí	Otevírají pull requesty, které zvýší zranitelnou závislost na opravenou verzi	Dependabot security updates, Renovate	Vychází z manifestů a lockfilů v repozitáři; aktualizace, která něco rozbije, stále potřebuje člověka, který upraví kód
Pull requesty s opravou ze SCA	Otevírají pull requesty s aktualizací pro nálezy, které hlásí komerční nástroj SCA	Snyk, Black Duck, Aikido, Endor Labs	Pokrytí se liší: některé nástroje opravují jen přímé závislosti, jiné přidávají patche nebo backporty
Opravy kódu pomocí AI	Generují změnu kódu pro nález, často pro upozornění statické analýzy	GitHub Copilot Autofix	Nedeterministické návrhy, které je třeba zkontrolovat; viz náprava pomocí AI
Automatická náprava infrastruktury	Vrátí chybnou konfiguraci nebo opraví hostitele, když se spustí pravidlo	Nástroje pro stav zabezpečení cloudu a koncové body	Pokrývá běžící infrastrukturu, nikoli závislosti uvnitř softwaru, který dodáváte

První tři opravují kód, který dodáváte, a všechny sdílejí jeden předpoklad: že seznam zranitelných balíčků, které opravují, je ten správný.

Každá oprava závisí na inventáři

Nástroj pro nápravu dokáže opravit jen zranitelnosti, o kterých ví, a ví o těch, které obsahuje jeho inventář. Většina inventářů se rekonstruuje ze souborů: z manifestů, lockfilů, nainstalovaných balíčků nebo hotového image kontejneru. Taková rekonstrukce předvídatelně něco vynechává.

• Balíčky, které soubory nedeklarují. Nástroje, které build stahuje, základní image, pluginy a cokoli nainstalovaného skriptem se v lockfilu nikdy neobjeví, takže se pro ně nikdy neotevře žádný pull request s opravou.
• Verze, které se liší od lockfilu. Build může vyřešit jinou verzi, než jakou čte skener, zvlášť bez commitnutého lockfilu. Oprava navázaná na špatnou verzi je sebejistá špatná odpověď.
• Balíčky obnovené z cache. Závislost z cache se už nikdy nedotkne registru, takže to, co build použil, může zaostávat za tím, co uvádí repozitář.

Řešením je vycházet z toho, co build skutečně použil. SBOM z doby buildu se zaznamenává během běhu buildu, takže uvádí balíčky, které si job stáhl, včetně tranzitivních, nikoli to, co by podle manifestu měl potřebovat. Náprava, která vychází z ní, opravuje to, co se skutečně dodává.

Co automatizovat a co ponechat lidem

Většina týmů, kterým náprava funguje, ji dělí takto:

• Automatizujte hledání a porovnávání. Nová bezpečnostní upozornění vycházejí každý den. Ruční kontrola každého dodaného buildu proti nim se nedá škálovat a je to přesně ten druh práce, který software zvládá dobře.
• Automatizujte návrh. Výběr opravené verze a otevření změny je mechanická práce. Seskupujte související aktualizace, aby recenzenti viděli jeden pull request místo dvaceti.
• Podmiňte sloučení testy. Bezpečnostní aktualizace na úrovni patche, které pokrývá sada testů, slučujte automaticky. Aktualizace, které něco rozbíjejí, a cokoli bez pokrytí testy nechte na člověku.
• Úsudek ponechte lidem. Zda se zranitelnost vašeho produktu vůbec týká a zda se riziková aktualizace tento týden vyplatí, jsou rozhodnutí. Zaznamenávejte je, například jako prohlášení VEX, aby se stejná otázka nekladla dvakrát.

Jak vyhodnotit nástroj pro nápravu

Než nástroji svěříte otevírání pull requestů ve svých repozitářích, zeptejte se:

1. Odkud pochází jeho seznam zranitelností: ze souborů v repozitáři, ze skenovaného image, nebo ze samotného buildu?
2. Opravuje tranzitivní závislosti, nebo jen přímé, které deklarujete?
3. Jak vybírá opravenou verzi: minimální opravenou verzi, nejnovější, nebo verzi, kterou připnete?
4. Je oprava sestavena a otestována dřív, než ji uvidíte, nebo pull request představuje její první spuštění?
5. Umí aktualizace seskupovat a plánovat, aby recenzenty nezahltil?
6. Zaznamenává, která vydání byla zasažena a kdy byla každá oprava dodána?

Kde dnes zapadá CRACI

CRACI 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. Tento záznam je inventář, ze kterého by měl workflow nápravy vycházet.

CRACI průběžně znovu vyhodnocuje monitorované SBOM, takže když vyjde nové bezpečnostní upozornění, vidíte, kterých dodaných buildů se týká napříč vašimi repozitáři. Bezpečnostní týmy provedou triáž každého nálezu a pošlou ho týmu, který vlastní opravu, a CRACI podporuje VEX pro zaznamenání toho, jak zranitelnost ovlivňuje váš produkt. SBOM dalšího buildu pak ukáže, zda opravená verze je ta, kterou build skutečně použil. Celou funkci popisuje stránka sledování zranitelností.

Podle evropského Cyber Resilience Act musí výrobci zranitelnosti bez zbytečného odkladu řešit a napravovat, mimo jiné prostřednictvím bezpečnostních aktualizací. Záznam o tom, co každý build obsahoval a kdy byla každá oprava dodána, je důkaz, který tento proces potřebuje.

Automatizovaná náprava zranitelností: časté dotazy

Co je automatizovaná náprava zranitelností?

Automatizovaná náprava zranitelností je software, který z nálezu zranitelnosti udělá opravu, aniž by na ní musel pracovat člověk: zjistí opravenou verzi, změní manifest, lockfile nebo kód a navrhne změnu, obvykle jako pull request. O tom, co se sloučí, stále rozhoduje člověk nebo politika, které tým důvěřuje.

Jaký je rozdíl mezi nápravou a zmírněním zranitelnosti?

Náprava zranitelnost odstraní, například aktualizací na opravenou verzi nebo použitím patche. Zmírnění snižuje riziko, dokud zranitelnost trvá, například vypnutím dotčené funkce nebo zablokováním cesty útoku. Zmírnění získává čas; náprava nález uzavírá.

Lze nápravu zranitelností plně automatizovat?

Částečně ano. Hledání zasažených buildů, porovnávání s bezpečnostními upozorněními a navržení vyšší verze jsou mechanické úkony a dobře se automatizují. Rozhodnutí, zda je aktualizace s nekompatibilními změnami bezpečná nebo zda se zranitelnost vašeho produktu vůbec týká, stále vyžaduje úsudek. Většina týmů automatizuje návrh a o sloučení nechává rozhodovat člověka, kterého podporují testy.

Provádí Dependabot automatizovanou nápravu zranitelností?

Dependabot security updates otevírají pull requesty, které aktualizují zranitelnou závislost na minimální opravenou verzi, a to pro upozornění, která GitHub hlásí na grafu závislostí vašeho repozitáře. Jde o automatizovanou nápravu toho, co deklarují manifesty a lockfily. CRACI vs Dependabot popisuje, kde se deklarované a dodané liší.

Na co se zaměřit u nástroje pro nápravu zranitelností?

Odkud pochází jeho seznam zranitelností, zda zvládá tranzitivní závislosti, jak vybírá verzi s opravou, zda je oprava sestavena a otestována dřív, než ji uvidíte, a zda zaznamenává, co a kdy bylo opraveno. To poslední je důležité pro audity a pro CRA, který po výrobcích požaduje nápravu zranitelností bez zbytečného odkladu.