Usuwanie CVE: od biuletynu do naprawionego, dostarczonego buildu

Proces usuwania CVE

Usuwanie CVE polega na wyeliminowaniu publicznie ujawnionej podatności z oprogramowania, które Państwo uruchamiają lub dostarczają. W przypadku własnego kodu oznacza to poprawkę. W przypadku zależności open source, z których pochodzi większość CVE w typowym produkcie, oznacza to przejście na wersję, w której podatność została naprawiona. Tak czy inaczej kroki są te same:

1. Znaleźć każdy produkt, build i wydanie zawierające dany pakiet i wersję.
2. Ocenić, czy podatność dotyczy Państwa i jak poważnie.
3. Ustalić priorytet względem wszystkiego innego, co pozostaje otwarte.
4. Naprawić przez aktualizację, załatanie, zastąpienie lub, jeśli poprawka nie istnieje, złagodzenie.
5. Zweryfikować, czy nowy build faktycznie zawiera naprawioną wersję.
6. Zapisać, czego to dotyczyło, co Państwo zdecydowali i kiedy dostarczono poprawkę.

Krok 1: znaleźć każdy build, którego to dotyczy

Pierwsze pytanie po biuletynie brzmi: gdzie jest ten pakiet? Odpowiadanie na nie na podstawie repozytoriów kodu jest powolne i często błędne: wersja w lockfile, wersja rozwiązana przez build i wersja w wydanym obrazie kontenera mogą się różnić. Zależności przechodnie i pakiety pobierane przez build poza menedżerem pakietów w ogóle nie pojawiają się w manifestach.

Wiarygodną odpowiedź daje SBOM każdego wydania, stale dopasowywany do biuletynów. Jeśli ten SBOM jest rejestrowany podczas buildu, wymienia to, czego build faktycznie użył, więc dopasowanie mówi, które dostarczone buildy zawierają podatną wersję, a nie które repozytoria o niej wspominają.

Krok 2: ustalić priorytety według dotkliwości i wykorzystania

Sama dotkliwość oznacza zbyt wiele podatności jako pilne. Większość zespołów łączy trzy sygnały:

Sygnał	Co mówi	Kto publikuje
CVSS	Jak dotkliwa jest podatność w razie wykorzystania, w skali od 0 do 10	FIRST (standard); oceny publikują NVD i dostawcy
EPSS	Szacowane prawdopodobieństwo wykorzystania w ciągu najbliższych 30 dni	FIRST
KEV	Czy wiadomo, że podatność jest wykorzystywana w rzeczywistych atakach	Katalog Known Exploited Vulnerabilities agencji CISA

Następnie należy dodać własny kontekst: czy dany pakiet trafia do klientów, czy działa tylko w zadaniu testowym, i czy podatna funkcja jest w ogóle używana. Znana wykorzystywana podatność w dostarczanym pakiecie trafia na szczyt listy. Priorytetyzacja podatności zamienia te sygnały w metodę.

Terminy usuwania

• CISA BOD 26-04. Od 10 czerwca 2026 agencje federalne USA ustalają każdy termin na podstawie czterech pytań: czy zasób jest publicznie dostępny, czy podatność jest w katalogu KEV, czy wykorzystanie można zautomatyzować i czy daje częściową, czy pełną kontrolę. Odpowiedzi prowadzą do terminów od 3 dni, z triażem forensycznym w najgorszych przypadkach, po naprawę przy następnej aktualizacji systemu. Dyrektywa zastąpiła BOD 22-01, która dawała dwa tygodnie na większość wpisów KEV.
• Unijny Cyber Resilience Act. Producenci muszą bez zwłoki zajmować się podatnościami i je usuwać, także przez aktualizacje bezpieczeństwa (załącznik I, część II). Od 11 września 2026 aktywnie wykorzystywana podatność w produkcie uruchamia też zegar zgłoszeń: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu 14 dni od udostępnienia poprawki.
• Własna polityka. Większość programów bezpieczeństwa ustala wewnętrzne cele według dotkliwości. Jakiekolwiek by były, można je osiągnąć tylko wtedy, gdy krok 1 przebiega szybko.

Krok 3: wybrać poprawkę

Opcja	Kiedy jej użyć
Aktualizacja	Istnieje naprawiona wersja. Najlepiej wybrać najmniejszą aktualizację zawierającą poprawkę, aby ograniczyć zmiany łamiące zgodność.
Aktualizacja pakietu nadrzędnego	Podatny pakiet jest zależnością przechodnią. Nowsze wydanie zależności bezpośredniej często wciąga poprawkę.
Nadpisanie	Pakiet nadrzędny nie wydał poprawki. Należy wymusić wersję przechodnią za pomocą npm overrides, Yarn resolutions lub pnpm.overrides i ją przetestować.
Łatka lub backport	Nie mogą Państwo jeszcze przejść na naprawioną wersję główną. Należy zastosować poprawkę upstream do używanej wersji.
Zastąpienie	Pakiet nie jest utrzymywany lub wciąż generuje CVE. Należy przejść na alternatywę.
Złagodzenie i udokumentowanie	Poprawka jeszcze nie istnieje albo Państwa produkt nie jest podatny. Należy ograniczyć narażenie i zapisać ocenę, na przykład jako oświadczenie VEX.

Większość tego kroku można zautomatyzować, od wyboru wersji po otwarcie pull requesta. Automatyczne usuwanie podatności wyjaśnia, co automatyzować, a co zostawić człowiekowi.

Krok 4: scalona poprawka to nie dostarczona poprawka

Pull request został scalony, więc CVE jest zamknięta. Niekoniecznie. Poprawka jest w repozytorium, ale build przywraca nieaktualny cache, obraz bazowy nadal zawiera stary pakiet albo gałąź wydania nigdy nie przejęła zmiany. Zgłoszenie mówi, że naprawiono, a produkt nadal dostarcza podatną wersję.

Należy zamknąć pętlę z drugiej strony: sprawdzić SBOM następnego buildu i potwierdzić, że podatnej wersji już nie ma. Gdy ten SBOM rejestruje to, co build faktycznie pobrał, łącznie z pakietami przywróconymi z cache, kontrola odpowiada na pytanie, które naprawdę zadają klient, audytor i regulator.

Jak CRACI wspiera usuwanie CVE

• Znalezienie. CRACI rejestruje pakiety pobrane przez każde zadanie GitHub Actions, łącznie z zależnościami przechodnimi i pakietami przywróconymi z cache, oraz stale ponownie ocenia monitorowane SBOM-y. Widoki organizacji zbierają znaleziska z różnych buildów i repozytoriów, dzięki czemu widać, których buildów dotyczy nowa CVE.
• Przypisanie. Zespoły bezpieczeństwa wykonują triaż każdego znaleziska i przekazują je zespołowi odpowiedzialnemu za poprawkę. CRACI obsługuje VEX do zapisywania, jak podatność wpływa na Państwa produkt.
• Weryfikacja. Każdy nowy build otrzymuje własny SBOM z określonym stanem kompletności, dzięki czemu mogą Państwo potwierdzić, że build użył naprawionej wersji.
• Zgłoszenie. W przypadku aktywnie wykorzystywanych podatności objętych CRA CRACI składa zgłoszenia do organów w imieniu producenta.

Pełny opis tej funkcji znajdą Państwo na stronie śledzenie podatności.

Usuwanie CVE: najczęściej zadawane pytania

Czym jest usuwanie CVE?

Usuwanie CVE to wyeliminowanie publicznie ujawnionej podatności, oznaczonej identyfikatorem CVE, z oprogramowania, które Państwo uruchamiają lub dostarczają. W przypadku zależności zwykle oznacza to aktualizację do wersji z naprawioną podatnością. W przypadku własnego kodu oznacza to jego załatanie.

Jak ustalić, które CVE naprawić najpierw?

Należy połączyć dotkliwość z dowodami wykorzystania. CVSS opisuje, jak poważna jest podatność, EPSS szacuje, jak prawdopodobne jest jej wykorzystanie w ciągu najbliższych 30 dni, a katalog Known Exploited Vulnerabilities agencji CISA wymienia te już wykorzystywane. Znana wykorzystywana podatność w dostarczanym pakiecie trafia na szczyt listy.

Jak szybko trzeba usuwać CVE?

To zależy od tego, kto pyta. Binding Operational Directive 26-04 agencji CISA daje agencjom federalnym USA od 3 dni do następnej aktualizacji systemu, zależnie od tego, czy podatność jest w katalogu KEV, czy zasób jest publicznie dostępny, czy wykorzystanie można zautomatyzować i jaką kontrolę daje napastnikowi. Unijny Cyber Resilience Act wymaga od producentów usuwania podatności bez zwłoki, a od 11 września 2026 aktywnie wykorzystywana podatność w produkcie uruchamia 24-godzinny zegar zgłoszeń.

Co zrobić, jeśli naprawiona wersja jeszcze nie istnieje?

Złagodzić i udokumentować. Jeśli to możliwe, należy wyłączyć daną funkcję, zablokować ścieżkę ataku lub wymienić komponent i zapisać swoją ocenę, na przykład jako oświadczenie VEX. Następnie obserwować, czy pojawi się naprawione wydanie, i usunąć podatność, gdy będzie dostępne.

Jak naprawić CVE w zależności przechodniej?

Najpierw warto spróbować aktualizacji zależności bezpośredniej, która ją wciąga, ponieważ nowsze wydanie często zawiera poprawkę. Jeśli takiego nie ma, większość menedżerów pakietów pozwala wymusić wersję pakietu przechodniego: overrides w npm, resolutions w Yarn, pnpm.overrides w pnpm. Wynik należy przetestować, ponieważ pakiet nadrzędny nie był budowany z tą wersją.