Náprava CVE: od bezpečnostního upozornění k opravenému a vydanému buildu

Proces nápravy CVE

Náprava CVE odstraňuje veřejně zveřejněnou zranitelnost ze softwaru, který provozujete nebo dodáváte. U vlastního kódu to znamená opravu. U open source závislostí, odkud pochází většina CVE v typickém produktu, to znamená přejít na verzi, ve které je zranitelnost opravena. Kroky jsou v obou případech stejné:

1. Najděte každý produkt, build a vydání, které obsahuje dotčený balíček a verzi.
2. Posuďte, zda se vás zranitelnost týká a jak závažně.
3. Stanovte prioritu vůči všemu ostatnímu, co je otevřené.
4. Opravte upgradem, záplatou, náhradou, nebo pokud oprava neexistuje, zmírněním.
5. Ověřte, že nový build skutečně obsahuje opravenou verzi.
6. Zaznamenejte, čeho se to týkalo, jak jste rozhodli a kdy byla oprava vydána.

Krok 1: najděte každý dotčený build

První otázka po bezpečnostním upozornění zní, kde balíček je. Odpovídat na ni z repozitářů zdrojového kódu je pomalé a často chybné: verze v lockfilu, verze, kterou build vyřešil, a verze ve vydaném image kontejneru se mohou lišit. Tranzitivní závislosti a balíčky, které build stahuje mimo správce balíčků, se v manifestech vůbec neobjeví.

Spolehlivou odpověď dává SBOM každého vydání, průběžně porovnávaná s bezpečnostními upozorněními. Pokud je tato SBOM zaznamenaná během buildu, uvádí, co build skutečně použil, takže porovnání ukáže, které vydané buildy obsahují zranitelnou verzi, a ne které repozitáře ji zmiňují.

Krok 2: prioritizujte podle závažnosti a zneužívání

Samotná závažnost označí za naléhavé příliš mnoho zranitelností. Většina týmů kombinuje tři signály:

Signál	Co vám říká	Kdo ho zveřejňuje
CVSS	Jak závažná je zranitelnost, pokud je zneužita, hodnoceno od 0 do 10	FIRST (standard); skóre zveřejňují NVD a dodavatelé
EPSS	Odhadovaná pravděpodobnost zneužití v příštích 30 dnech	FIRST
KEV	Zda je známo, že je zranitelnost aktivně zneužívána	Katalog Known Exploited Vulnerabilities agentury CISA

Pak přidejte vlastní kontext: zda se dotčený balíček dodává zákazníkům, nebo běží jen v testovacím jobu, a zda se zranitelná funkce vůbec používá. Známá zneužívaná zranitelnost v dodávaném balíčku jde na začátek seznamu. Prioritizace zranitelností z těchto signálů dělá metodu.

Lhůty pro nápravu

• CISA BOD 26-04. Od 10. června 2026 stanovují federální úřady USA každou lhůtu podle čtyř otázek: je aktivum veřejně dostupné, je zranitelnost v katalogu KEV, lze zneužití automatizovat a dává částečnou, nebo úplnou kontrolu? Odpovědi vedou ke lhůtám od 3 dnů, s forenzní triáží pro nejhorší případy, až po opravu při příštím upgradu systému. Směrnice nahradila BOD 22-01, která na většinu záznamů KEV dávala dva týdny.
• Unijní Cyber Resilience Act. Výrobci musejí zranitelnosti bez zbytečného odkladu řešit a napravovat, mimo jiné prostřednictvím bezpečnostních aktualizací (příloha I, část II). Od 11. září 2026 navíc aktivně zneužívaná zranitelnost v produktu spouští lhůty pro podávání zpráv: včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu do 14 dnů od zpřístupnění opravy.
• Vaše vlastní pravidla. Většina bezpečnostních programů si stanovuje interní cíle podle závažnosti. Ať jsou jakékoli, splníte je jen tehdy, když je krok 1 rychlý.

Krok 3: zvolte opravu

Možnost	Kdy ji použít
Upgrade	Opravená verze existuje. Upřednostněte nejmenší upgrade, který opravu obsahuje, abyste omezili nekompatibilní změny.
Upgrade nadřazeného balíčku	Zranitelný balíček je tranzitivní. Novější vydání přímé závislosti opravu často přinese.
Přepsání verze	Nadřazený balíček opravu nevydal. Vynuťte tranzitivní verzi pomocí npm overrides, Yarn resolutions nebo pnpm.overrides a otestujte ji.
Záplata nebo backport	Zatím nemůžete přejít na opravenou hlavní verzi. Aplikujte upstreamovou opravu na verzi, kterou používáte.
Náhrada	Balíček není udržován nebo v něm stále přibývají CVE. Přejděte na alternativu.
Zmírnění a dokumentace	Oprava zatím neexistuje nebo se vašeho produktu zranitelnost netýká. Omezte expozici a zaznamenejte posouzení, například jako prohlášení VEX.

Většinu tohoto kroku lze automatizovat, od výběru verze po otevření pull requestu. Automatizovaná náprava zranitelností popisuje, co automatizovat a co nechat na člověku.

Krok 4: sloučená oprava ještě není vydaná oprava

Pull request byl sloučen, takže CVE je uzavřená. Ne nutně. Oprava je v repozitáři, ale build obnoví zastaralou cache, základní image stále obsahuje starý balíček nebo větev vydání změnu nikdy nepřevzala. Tiket hlásí opraveno, zatímco produkt stále dodává zranitelnou verzi.

Uzavřete smyčku z druhého konce: zkontrolujte SBOM dalšího buildu a ověřte, že zranitelná verze zmizela. Když tato SBOM zaznamenává, co si build skutečně stáhl, včetně balíčků obnovených z cache, kontrola odpovídá na otázku, kterou se zákazník, auditor i regulátor ve skutečnosti ptají.

Jak CRACI podporuje nápravu CVE

• Najít. CRACI zaznamenává balíčky, které si každý job GitHub Actions stáhl, včetně tranzitivních závislostí a balíčků obnovených z cache, a průběžně znovu vyhodnocuje monitorované SBOM. Zobrazení organizace agregují nálezy napříč buildy a repozitáři, takže vidíte, kterých buildů se nová CVE týká.
• Přiřadit. Bezpečnostní týmy provádějí triáž každého nálezu a posílají ho týmu, který odpovídá za opravu. CRACI podporuje VEX pro zaznamenání toho, jak zranitelnost ovlivňuje váš produkt.
• Ověřit. Každý nový build dostane vlastní SBOM se stavem úplnosti, takže můžete ověřit, že build použil opravenou verzi.
• Hlásit. U aktivně zneužívaných zranitelností podle CRA CRACI připravuje obsah oznámení a osoba na straně výrobce je podává přes Single Reporting Platform.

Úplný popis této funkce najdete na stránce sledování zranitelností.

Náprava CVE: časté dotazy

Co je náprava CVE?

Náprava CVE je odstranění veřejně zveřejněné zranitelnosti, označené identifikátorem CVE, ze softwaru, který provozujete nebo dodáváte. U závislosti to obvykle znamená upgrade na verzi, ve které je zranitelnost opravena. U vlastního kódu to znamená jeho opravu.

Jak určit, které CVE opravit nejdřív?

Zkombinujte závažnost s důkazy o zneužívání. CVSS popisuje, jak vážná zranitelnost je, EPSS odhaduje, s jakou pravděpodobností bude zneužita v příštích 30 dnech, a katalog Known Exploited Vulnerabilities agentury CISA uvádí ty, které už zneužívány jsou. Známá zneužívaná zranitelnost v balíčku, který dodáváte, jde na začátek.

Jak rychle je třeba CVE napravit?

Záleží na tom, kdo se ptá. Závazná operační směrnice CISA 26-04 dává federálním úřadům USA od 3 dnů až po příští upgrade systému, podle toho, zda je zranitelnost v katalogu KEV, zda je aktivum veřejně dostupné, zda lze zneužití automatizovat a jakou kontrolu dává útočníkovi. Unijní Cyber Resilience Act žádá po výrobcích, aby zranitelnosti napravovali bez zbytečného odkladu, a od 11. září 2026 aktivně zneužívaná zranitelnost v produktu spouští 24hodinovou lhůtu pro podání zprávy.

Co když opravená verze zatím neexistuje?

Zmírněte a zdokumentujte. Pokud to jde, vypněte dotčenou funkci, zablokujte cestu útoku nebo vyměňte komponentu a zaznamenejte své posouzení, například jako prohlášení VEX. Pak sledujte vydání s opravou a po jeho vydání zranitelnost napravte.

Jak opravit CVE v tranzitivní závislosti?

Nejdřív zkuste upgradovat přímou závislost, která ji natahuje, protože novější vydání opravu často obsahuje. Pokud takové zatím neexistuje, většina správců balíčků umožňuje vynutit verzi tranzitivního balíčku: overrides v npm, resolutions v Yarn, pnpm.overrides v pnpm. Výsledek otestujte, protože nadřazený balíček nebyl proti této verzi sestaven.