Jak poradzić sobie z rosnącą liczbą CVE w małym zespole

Co się zmieniło: liczby CVE

Poniższe dane pochodzą z rekordów samego CVE Program i są codziennie odświeżane na naszej stronie trendy publikacji CVE. Według migawki z 12 lis 2026 UTC:

• 47 801 CVE opublikowano w 2025 r., o 20% więcej niż rok wcześniej.
• 95 494 CVE opublikowano dotąd w 2026 r., czyli 303 dziennie, o +131% więcej niż dzienne tempo z 2025 r.
• 155 dziennie ma ocenę wysoką lub krytyczną.
• 17% wszystkich rekordów od 2020 r. nie ma oceny CVSS ani od przypisującego, ani z uzupełnień CISA. Pokrycie się poprawiło: w 2026 r. ten odsetek wynosi 6%.
• Liczba organizacji, które przypisały te rekordy: 505. Na 20 największych przypada 75% z nich.

• Wysoka lub krytyczna
• Pozostałe oceny i brak oceny

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Średnia dzienna liczba rekordów opublikowanych w danym roku; * oznacza bieżący rok do dziś. Źródło: rekordy cvelistV5 CVE Program, migawka z 12 lis 2026 UTC. Filtry według miesiąca, oceny i przypisującego: trendy publikacji CVE.

To nie jest jeden zły kwartał. Liczba rośnie co roku od 2020 r., a kilka zmian strukturalnych sprawia, że będzie rosła dalej:

• Więcej przypisujących, którzy przypisują szerzej. Projekt jądra Linux został CVE Numbering Authority w lutym 2024 r. Zgodnie z jego udokumentowaną polityką CVE otrzymuje każda poprawka błędu, który może być podatnością, gdy tylko trafi do stabilnego jądra, ponieważ w chwili wprowadzenia poprawki możliwość wykorzystania często nie jest jasna. Sam CNA jądra opublikował od tamtej pory 18 221 CVE.
• Wykrywanie wspierane przez AI. W listopadzie 2024 r. Project Zero Google i DeepMind poinformowały, że ich agent Big Sleep znalazł w SQLite możliwy do wykorzystania błąd bezpieczeństwa pamięci, zanim trafił on do wydania. Ich zdaniem był to pierwszy publiczny przykład agenta AI, który dokonał tego w powszechnie używanym oprogramowaniu. Takie narzędzia zwiększają to, ile może znaleźć jeden badacz.
• NVD nie jest już w stanie uzupełniać wszystkiego. Według NIST w National Vulnerability Database od początku 2024 r. narastały zaległości w uzupełnianiu CVE, których nie udało się nadrobić, bo zgłoszeń wciąż przybywało. W kwietniu 2026 r. baza przeszła na model oparty na ryzyku: najpierw uzupełniane są CVE z katalogu Known Exploited Vulnerabilities agencji CISA oraz CVE w oprogramowaniu federalnym lub krytycznym, a pozostałe są oznaczane jako niezaplanowane do natychmiastowego uzupełnienia. Proces, który opiera się na danych o produktach z jednej bazy, teraz czeka albo coś pomija.
• Mniej czasu na reakcję. Mandiant zmierzył w latach 2018 i 2019 średni czas do wykorzystania podatności na poziomie 63 dni. Raport M-Trends 2026 szacuje go dla 2025 r. na minus siedem dni: wykorzystanie rutynowo zaczyna się, zanim zostanie wydana poprawka.
• Terminy regulacyjne. Zgodnie z unijnym Cyber Resilience Act producenci zgłaszają aktywnie wykorzystywaną podatność wczesnym ostrzeżeniem w ciągu 24 godzin, powiadomieniem w ciągu 72 godzin i raportem końcowym w ciągu 14 dni od udostępnienia poprawki (czego wymaga CRA). Terminy są takie same dla zespołu trzyosobowego, jak dla zespołu liczącego trzysta osób.

Nic z tego nie oznacza, że oprogramowanie staje się mniej bezpieczne. Oznacza to, że liczba rzeczy, którym zespół musi się przyjrzeć, rośnie z każdym rokiem, a zespół nie.

Co się psuje w procesie małego zespołu

Rosnące liczby nie psują zarządzania podatnościami dlatego, że jest więcej podatności do naprawienia. Psują je dlatego, że każdy ręczny krok powtarza się przy każdym CVE.

Ręczny krok	Dlaczego zawodzi przy dzisiejszej skali
Ręczne budowanie inwentarza	Arkusz kalkulacyjny albo SBOM przygotowany przed audytem jest nieaktualny dzień po kolejnym wydaniu.
Czytanie strumienia CVE	Przy 155 CVE dziennie o ocenie wysokiej lub krytycznej nikt nie nadąża.
Pytanie inżynierów „czy używamy X?”	To samo pytanie przy każdym CVE, do tych samych zapracowanych osób. Wąskim gardłem jest samo pytanie.
Jedno zgłoszenie na CVE na repozytorium	CVE we współdzielonej bibliotece zamienia się w dziesiątki zduplikowanych zgłoszeń, które zalewają backlog.
Odpowiadanie każdemu klientowi osobno	Zapytań przybywa wraz z bazą klientów, a nie z liczbą podatności.
Dokumenty w PDF lub na wiki	Narzędzia klientów nie dopasują PDF do swojego inwentarza, więc każdy czytelnik pyta ponownie.
Terminy, które się nie przesuwają	Czas do wykorzystania się skraca, a ręczny proces zwalnia w miarę wzrostu skali.

Inwentarz. Większość zespołów, które ręcznie prowadzą listę komponentów, aktualizuje ją przed audytem albo przed kwestionariuszem klienta. Pomiędzy tymi datami opisuje ona oprogramowanie, które już nie jest dostarczane. Każde pytanie o CVE zaczyna się wtedy od odtwarzania tego, co zawierało wydanie.

Strumień CVE. Czytanie biuletynów to krok, od którego zespoły zaczynają, i pierwszy, który się załamuje. Słyszymy o zespołach, które wciąż robią to ręcznie, w tym o takim, w którym skanowanie podatności oznacza ludzi czytających fora o CVE. Działa to do dnia, w którym przestaje, i nic nie sygnalizuje, kiedy ten dzień nadejdzie.

Pytanie do inżynierów. „Czy używamy tej biblioteki i w jakiej wersji?” odrywa programistę od pracy przy każdym CVE, które może mieć zastosowanie. Pewien dwuosobowy zespół bezpieczeństwa produktu powiedział nam, że jego praca to klikanie przycisków, byle nadążyć, bez czasu na ulepszanie procesu.

Zgłoszenia. Gdy współdzielona biblioteka ma CVE i każde repozytorium otwiera własne zgłoszenie, backlog liczy tę samą decyzję wiele razy. Zespoły uczą się ignorować backlog, a potem przeoczają zgłoszenie, które miało znaczenie.

Odpowiedzi dla klientów. Po głośnej podatności lub ataku na łańcuch dostaw klienci pytają „czy to nas dotyczy?”. Odpowiadanie każdemu osobno zabiera najwięcej czasu w dniu, w którym jest go najmniej.

Dokumenty. Oświadczenie w PDF albo strona wiki musi zostać przeczytana przez człowieka po stronie klienta. Skanery klientów, a coraz częściej także regulatorzy, oczekują SBOM, VEX i biuletynów w formatach, które maszyna potrafi dopasować.

Terminy. Wczesne ostrzeżenie wymagane w ciągu 24 godzin albo exploit, który pojawia się przed poprawką, nie czekają, aż kolejka się opróżni.

Co automatyzować i w jakiej kolejności

Każdy krok zdejmuje pracę z następnego, więc kolejność ma większe znaczenie niż wybór narzędzi.

1. Wiedzieć, co się dostarcza. SBOM z każdego buildu zamienia pytanie „czy to nas dotyczy?” w wyszukiwanie.
2. Dopasowywać stale, do więcej niż jednego źródła. Nowe CVE są sprawdzane względem każdego zapisanego SBOM, więc nikt nie czyta strumienia.
3. Ograniczyć szum. Znaleziska dotyczące rzeczy, których Państwo nie dostarczają, oraz duplikaty nigdy nie trafiają do człowieka.
4. Prowadzić triaż półautomatycznie. Fakty są uzupełnione; decyzję podejmuje człowiek.
5. Udostępniać wszystko w formie czytelnej dla maszyn. Każda decyzja zapada raz i jest wykorzystywana przez każdego odbiorcę.
6. Odpowiadać raz, publicznie. Zapytanie, które nigdy nie przychodzi, nic nie kosztuje.

1. Automatycznie generować SBOM dla każdego buildu

Co zastępuje: arkusz kalkulacyjny i pytanie do inżynierów. SBOM generowany w czasie buildu opisuje to, czego build faktycznie użył, a przechowywanie go dla każdej dostarczonej wersji pozwala odpowiedzieć zarówno za zeszłoroczne wydanie, jak i za main. Klienci używają starych wersji; Państwa inwentarz musi je obejmować.

Wersja minimalna: SBOM generowany w CI dla każdego buildu wydania i przechowywany obok artefaktu wydania. Lepiej: SBOM zarejestrowany z samego buildu, a nie odtworzony później z plików lockfile, tak aby zawierał również komponenty pobrane poza menedżerem pakietów (SBOM-y z czasu buildu, automatyzacja SBOM).

Koszt: dzień lub dwa pracy nad pipeline w wersji minimalnej, potem nic przy kolejnych wydaniach. Sygnał, że to działa: dla dowolnego wydania mogą Państwo wymienić jego komponenty bez pytania kogokolwiek.

2. Stale dopasowywać do kilku źródeł danych o podatnościach

Co zastępuje: czytanie strumienia CVE. Dopasowywanie to praca dla maszyny: każde nowe CVE względem każdego zapisanego SBOM, a nie tylko SBOM buildu, który właśnie się wykonał. Stare wydanie, które było czyste w chwili dostarczenia, staje się podatne w dniu publikacji CVE dla jednego z jego komponentów.

Jedno źródło nie wystarcza. Z powodu zaległości NVD w uzupełnianiu danych informacje o podatnych produktach mogą przyjść późno albo wcale. Biuletyny ekosystemów, takie jak GitHub Advisory Database i OSV, są często szybsze i określają podatne wersje pakietów w kategoriach danego ekosystemu. Europejska baza podatności ENISA (EU Vulnerability Database) dodaje kontekst unijny.

Wersja minimalna: zaplanowane zadanie, które codziennie ponownie skanuje każdy zapisany SBOM względem zagregowanego źródła i zgłasza nowe dopasowania. Sygnał, że to działa: dowiadują się Państwo, że wydanie jest podatne, zanim powie to klient. Jak wygląda to w CRACI, pokazuje śledzenie podatności.

3. Ograniczyć szum, zanim ktokolwiek spojrzy

Co zastępuje: ręczny przegląd znalezisk, które nie mają znaczenia. Większość szumu powstaje wcześniej: w inwentarzach wymieniających rzeczy, których Państwo nie dostarczają, w kilku narzędziach zgłaszających to samo CVE i w zależnościach, których nikt nie potrzebuje. Należy poprawić inwentarz, liczyć każde znalezisko raz według adresu URL pakietu (PURL), wersji i CVE, dostarczać mniej zależności, a następnie dodać kontekst wykorzystania z CISA KEV, EPSS i VEX. Jak ograniczyć szum podatności omawia te dźwignie po kolei. Sygnał, że to działa: liczba znalezisk na dostarczone wydanie spada, a powody są udokumentowane.

4. Prowadzić triaż półautomatycznie

Co zastępuje: człowieka, który zbiera fakty do każdego znaleziska. Pracę należy podzielić precyzyjnie:

• Automatycznie: ocena ważności, informacja, czy podatność jest znana jako wykorzystywana, które produkty i wersje zawierają komponent, zespół odpowiedzialny, proponowany priorytet i termin.
• Człowiek: decyzja. Naprawić, złagodzić, zaakceptować z datą wygaśnięcia albo oznaczyć jako niedotyczące z uzasadnieniem.

Czego nie należy automatyzować: zamykania znaleziska jako niedotyczącego bez zapisanego powodu. To jest wyciszanie, a ono wraca przy audycie lub incydencie. Zasady ustalania kolejności opisuje priorytetyzacja podatności.

Wersja minimalna: 15 minut dziennie nad kolejką, która jest już posortowana i uzupełniona. Sygnał, że to działa: każda decyzja ma zapisany powód i nic nie czeka, aż ktoś coś sprawdzi.

5. Udostępniać wszystko w formie czytelnej dla maszyn

Co zastępuje: pliki PDF, strony wiki i e-maile, które musi przeczytać człowiek. SBOM-y należy publikować w formacie CycloneDX lub SPDX (CycloneDX vs SPDX), decyzje o niedotyczeniu jako VEX, a biuletyny w formacie CSAF. Skanery klientów i regulatorzy mogą je wtedy przetwarzać bez udziału człowieka, więc każda decyzja zapada raz i jest wykorzystywana przez każdego, kto pyta.

Wersja minimalna dla małego zespołu: SBOM-y i VEX na żądanie, ze stałej lokalizacji; CSAF, gdy klienci zaczną o niego prosić. Sygnał, że to działa: narzędzia klientów przestają oznaczać to, na co Państwo już odpowiedzieli.

6. Odpowiadać raz, publicznie

Co zastępuje: osobny wątek e-mailowy z każdym klientem. Dla każdego istotnego CVE należy opublikować biuletyn lub stronę statusu z wersjami podatnymi i poprawionymi oraz mieć szablon odpowiedzi, który do niej odsyła. Poradnik jak odpowiedzieć na pytanie „czy to CVE nas dotyczy?” pokazuje, jak ustalić odpowiedź. Szablony samej odpowiedzi zawiera tekst jak odpowiadać klientom po ataku na łańcuch dostaw. Najtańsze zapytanie to takie, które nigdy nie przychodzi. Sygnał, że to działa: na większość zapytań odpowiada się linkiem.

Potem naprawiać

Automatyczne pull requesty z aktualizacjami zależności utrzymują rutynową pracę w ruchu; warto grupować je tygodniowo lub według wydań, aby przegląd pozostał wykonalny. Aktualizacja jednego pakietu nadrzędnego często usuwa naraz kilka podatnych zależności przechodnich i jest tańsza niż łatanie każdej z osobna (automatyczna remediacja podatności). Następnie należy zablokować powrót znanych złych komponentów za pomocą bramek polityk, które zatrzymują build.

Plan według wielkości zespołu

Godziny to ilustracyjne szacunki do planowania, a nie benchmarki.

	Jedna osoba, w niepełnym wymiarze	Funkcja bezpieczeństwa lub PSIRT licząca od 2 do 5 osób	Większy zespół
Automatyzować najpierw	Kroki 1 i 2: SBOM dla każdego buildu i ciągłe dopasowywanie	Kroki od 1 do 3, potem przekazywanie do odpowiedzialnych w kroku 4	Wszystkie sześć, z bramkami polityk w każdym pipeline
Pozostaje ręczne	Decyzja przy każdym znalezisku o ocenie wysokiej lub krytycznej; odpowiedzi dla klientów z szablonu	Decyzje, uzasadnienia VEX, biuletyny dla istotnych CVE	Decyzje, wyjątki i sam proces
Czas tygodniowo, ilustracyjnie	Od 2 do 4 godzin	Od 4 do 8 godzin na osobę	Wyznacza go liczba decyzji, a nie strumień CVE

Jeśli mają już Państwo PSIRT, obowiązuje ta sama kolejność; pełny model procesu opisuje cykl życia zarządzania podatnościami. O zapytaniach klientów, których przybywa z każdym CVE, piszemy w tekście jak skalować PSIRT.

Jak sprawdzić, że to działa

• Czas od publikacji CVE do ustalenia „dotyczy” lub „nie dotyczy”, dla każdego produktu.
• Odsetek zapytań klientów, na które odpowiedziano opublikowanymi materiałami.
• Znaleziska na dostarczone wydanie, a nie na skan.
• Odsetek decyzji z zapisanym powodem.
• Godziny tygodniowo poświęcane na pracę z podatnościami i to, czy ich ubywa.

Najpierw należy zmierzyć własny punkt wyjścia. Nie ma wiarygodnych benchmarków branżowych dla tych miar i nie przytaczamy żadnych.

Zatrudnić, kupić czy zmienić proces?

• Zatrudnić, gdy praca polega na naprawianiu podatności we własnym kodzie albo na pracy z klientami w obszarze bezpieczeństwa, która wymaga osądu.
• Kupić narzędzia do kroków, które powtarzają się przy każdym CVE: kroków 1, 2, 3 i 5.
• Zmienić proces w zakresie odpowiedzialności i terminów: kto decyduje i do kiedy.

Warto być szczerym co do ostatniego punktu. Narzędzie bez właściciela daje pulpit, którego nikt nie czyta.

Gdzie pasuje CRACI

CRACI automatyzuje kroki 1 i 2 oraz część kroków 3 i 4 dla oprogramowania budowanego w GitHub Actions. Zastępuje Państwa runnery hostowane przez GitHub i w trakcie każdego zadania rejestruje pakiety, które zadanie faktycznie pobrało, w tym pakiety przywrócone z cache CI i ukryte zależności, których nie wymienia żaden lockfile.

• SBOM z każdego buildu. SBOM każdego zadania identyfikuje każdy komponent za pomocą PURL i ma stan kompletności, więc wiedzą Państwo, kiedy czegoś nie dało się zobaczyć. Historia buildów przechowuje każdy wcześniejszy build wraz z jego SBOM, więc widać, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią.
• Ciągłe dopasowywanie. Monitorowane SBOM-y są stale ponownie oceniane, a znaleziska agregowane z wielu buildów i repozytoriów, więc CVE we współdzielonej bibliotece pojawia się jako jeden problem, a nie czterdzieści.
• Powiadomienia i bramki. CRACI powiadamia właściwe osoby o podatności i jej ocenie, a bramki polityk mogą zatrzymać build w czasie rzeczywistym, w tym build zawierający konkretne CVE.
• Triaż i przypisanie. Zespoły bezpieczeństwa prowadzą triaż znalezisk w CRACI i kierują każde z nich do zespołu odpowiedzialnego za poprawkę.
• SBOM-y czytelne dla maszyn. SBOM-y są eksportowane w formacie CycloneDX lub SPDX, a CRACI obsługuje VEX.

CRACI nie publikuje biuletynów, nie oferuje analizy osiągalności i nie skanuje Państwa własnego kodu. Pobiera opłaty wyłącznie za minuty buildu: $0.002 za minutę vCPU ($0.004 za domyślny runner z 2 vCPU), rozliczane co do sekundy, bez opłaty miesięcznej, bez opłaty za SBOM i obecnie bez opłaty licencyjnej. Szczegóły: cennik.

Pierwsze dwa kroki można zautomatyzować już dziś: uruchomić buildy w CRACI. Przed ogólną dostępnością wdrażamy każdy zespół osobiście.

Kiedy CRACI nie jest odpowiedzią

• Państwa oprogramowanie nie jest budowane w GitHub Actions. GitLab CI i Jenkins są na roadmapie.
• Państwa ekspozycja dotyczy głównie infrastruktury: serwerów, punktów końcowych i konfiguracji chmury. Lepiej sprawdzą się narzędzia do zarządzania podatnościami infrastruktury.
• Integrują Państwo oprogramowanie układowe firm trzecich, którego sami nie budują. Lepiej sprawdzą się narzędzia do analizy binarnej.
• Państwa backlog to głównie prawdziwe, możliwe do wykorzystania znaleziska we własnym kodzie. To problem zdolności do naprawiania, a nie problem automatyzacji.

Automatyzacja zarządzania podatnościami: najczęściej zadawane pytania

Dlaczego CVE jest teraz o tyle więcej?

Więcej organizacji przypisuje CVE, a niektóre robią to szeroko: jądro Linux zostało CVE Numbering Authority w 2024 r. i przypisuje CVE każdej poprawce błędu, który może być podatnością. Narzędzia wspierane przez AI znajdują więcej błędów na jednego badacza. W 2025 r. opublikowano 47 801 CVE, a w 2026 r. tempo wynosi 303 dziennie. Ten trend trwa od lat.

Jak mały zespół może nadążyć za nowymi CVE?

Nie czytając ich. Należy generować SBOM dla każdego buildu, automatycznie dopasowywać nowe CVE do każdego zapisanego SBOM, ograniczyć szum i zostawić ludziom tylko decyzje w sprawie tego, co zostanie. Mały zespół nadąża, eliminując kroki powtarzane przy każdym CVE, a nie pracując szybciej.

Co zautomatyzować najpierw w zarządzaniu podatnościami?

Inwentarz: SBOM generowany w CI dla każdego buildu wydania i przechowywany razem z wydaniem. Zależy od niego każdy kolejny krok, a pytanie „czy to nas dotyczy?” zamienia się z pytania do inżynierów w wyszukiwanie. Na drugim miejscu jest ciągłe dopasowywanie do tych SBOM-ów.

Czy do obsługi podatności potrzebny jest zespół bezpieczeństwa?

Nie na początek. Jedna osoba odpowiedzialna za proces w niepełnym wymiarze może go prowadzić, jeśli inwentarz, dopasowywanie i ograniczanie szumu są zautomatyzowane. Bardziej niż zespołu potrzeba wskazanego właściciela i terminów. Zatrudniać warto wtedy, gdy praca polega na naprawianiu własnego kodu albo na pracy z klientami w obszarze bezpieczeństwa.

Jak sprawdzić, które nowe CVE dotyczą naszego produktu?

Należy przechowywać SBOM dla każdej dostarczonej wersji i ponownie sprawdzać wszystkie przy każdej publikacji nowych CVE, względem więcej niż jednego źródła danych o podatnościach. CVE dotyczy Państwa, gdy pasuje do komponentu i wersji, które faktycznie są dostarczane. Kontekst wykorzystania i VEX mówią następnie, czy ma to znaczenie.

Co oznacza „czytelny dla maszyn” w przypadku SBOM, VEX i biuletynów i dlaczego to ważne?

Oznacza standardowy, ustrukturyzowany format, który narzędzie potrafi przetworzyć: CycloneDX lub SPDX dla SBOM, VEX dla oświadczeń o niedotyczeniu, CSAF dla biuletynów. Skaner klienta może dopasować je do swojego inwentarza bez czytania ich przez kogokolwiek, więc decyzja podjęta raz jest wykorzystywana przez każdego klienta i każde narzędzie.

Jaką część triażu można bezpiecznie zautomatyzować?

Zbieranie faktów: ocenę ważności, status wykorzystania, informację, które produkty i wersje zawierają komponent, właściciela, proponowany priorytet i termin. Sama decyzja powinna należeć do człowieka. Nigdy nie należy automatycznie zamykać znaleziska jako niedotyczącego bez zapisanego powodu.

Ile mamy czasu na reakcję na krytyczne CVE?

Mniej, niż zakłada większość procesów. Raport M-Trends 2026 firmy Mandiant szacuje średni czas do wykorzystania w 2025 r. na minus siedem dni, co oznacza wykorzystanie, zanim istnieje poprawka. Zgodnie z unijnym Cyber Resilience Act aktywnie wykorzystywana podatność wymaga wczesnego ostrzeżenia w ciągu 24 godzin. Warto ustalić własny termin według oceny i wykorzystania, a potem mierzyć się względem niego.