Katalog CISA KEV urósł o ~20% w 2025 i przekroczył 1 480 pozycji: co to oznacza dla zespołów bezpieczeństwa? - Security Bez Tabu

Katalog CISA KEV urósł o ~20% w 2025 i przekroczył 1 480 pozycji: co to oznacza dla zespołów bezpieczeństwa?

Wprowadzenie do problemu / definicja luki

CISA Known Exploited Vulnerabilities (KEV) to katalog podatności, co do których istnieją potwierdzone dowody, że są wykorzystywane „w dziczy” (in-the-wild). Dla praktyki bezpieczeństwa to ważny filtr: nie „co może być groźne”, tylko „co realnie jest używane przez atakujących”.

Na początku stycznia 2026 r. podsumowania za 2025 r. wskazały, że katalog KEV wyraźnie przyspieszył wzrost i przekroczył próg 1 480 wpisów.

W skrócie

  • 1 484: tyle podatności (software + hardware) znajdowało się w KEV po dopisaniach z 2025 r.
  • +245: o tyle pozycji rozszerzono katalog w samym 2025 r.
  • 24: tyle dopisanych w 2025 r. podatności zostało oznaczonych jako wykorzystywane w kampaniach ransomware.
  • Wśród głośniejszych przykładów: CitrixBleed 2 (CVE-2025-5777) oraz podatności w Oracle E-Business Suite (CVE-2025-61882, CVE-2025-61884).

Kontekst / historia / powiązania

KEV jest powiązany z amerykańskim podejściem regulacyjnym do priorytetyzacji łatania — w szczególności z Binding Operational Directive (BOD) 22-01, która opisuje model „ciągłego priorytetyzowania” poprzez katalog podatności znanych z realnego wykorzystania.

W praktyce rynkowej KEV stał się też punktem odniesienia poza administracją: dostarcza stabilnego, kuratorowanego sygnału „exploited”, który można wpiąć do procesów VM (Vulnerability Management), patch management i risk management.

Warto dodać kontekst operacyjny: CISA utrzymuje też publiczne mirrorowanie danych KEV na GitHubie (repo cisagov/kev-data), co ułatwia integracje automatyczne i śledzenie zmian w czasie.

Analiza techniczna / szczegóły (jak wygląda KEV „od środka”)

Z perspektywy automatyzacji najważniejsze jest to, że KEV da się konsumować jako dane. W repozytorium cisagov/kev-data publikowane są pliki m.in. w formacie CSV/JSON, aktualizowane wkrótce po zmianach w źródle kanonicznym.

Przykładowy rekord (CSV) zawiera m.in. pola (nazwy kolumn), które są bezpośrednio użyteczne w priorytetyzacji i raportowaniu:

  • cveID, vendorProject, product, vulnerabilityName
  • dateAdded (kiedy dodano do KEV)
  • shortDescription, requiredAction
  • dueDate (termin wykonania)
  • knownRansomwareCampaignUse (czy wiązane z ransomware)
  • notes, cwes

To jest istotna różnica względem „samego CVE w NVD”: KEV daje nie tylko identyfikator i opis, ale też operacyjny kontekst (termin, wymagane działanie, sygnał ransomware).

Co mówi trend 2025?

Podsumowania pokazują, że wzrost KEV w 2025 r. był większy niż w dwóch poprzednich latach: w 2023 r. dopisano 187 pozycji, w 2024 r. 185, a w 2025 r. 245.

Co ważne, do katalogu trafiały nie tylko nowe CVE — dopisywano również starsze podatności (np. wskazywano CVE-2007-0671 jako najstarszą dodaną w 2025 r.), a najstarsza pozycja w katalogu ma pochodzić z 2002 r.

Praktyczne konsekwencje / ryzyko

Jeśli KEV rośnie szybciej, rośnie też presja na trzy obszary:

  1. Priorytetyzacja i „patch capacity”
    245 nowych wpisów rocznie (i trend przyspieszenia) oznacza, że „łatamy wszystko krytyczne” przestaje być wykonalne — potrzebujesz twardego filtra, a exploited-in-the-wild jest jednym z najsilniejszych.
  2. Ryzyko ransomware i incydentów masowych
    Oznaczenie „knownRansomwareCampaignUse” (tam, gdzie występuje) to gotowy sygnał do osobnej ścieżki eskalacji. Wśród przykładów z 2025 r. pojawiają się m.in. CitrixBleed 2 oraz wybrane podatności Oracle E-Business Suite.
  3. Dług techniczny i „stare CVE, nowe ataki”
    Dopisywanie starszych CVE do KEV przypomina, że exploitacja nie jest funkcją „świeżości” podatności. To argument za twardą inwentaryzacją i kontrolą EOL/EOS.

Rekomendacje operacyjne / co zrobić teraz

  1. Wepnij KEV jako obowiązkowy sygnał w VM
    Minimum: codzienny import danych KEV i korelacja z asset inventory + wynikami skanerów.
  2. Zbuduj 2–3 tory priorytetyzacji
    • Tor A (natychmiast): KEV + internet-facing + (jeśli masz) telemetry/exploit-attempts
    • Tor B (szybko): KEV (pozostałe) wg dueDate
    • Tor C (ciągłe): reszta CVE wg CVSS/EPSS/krytyczności usługi
  3. Traktuj „dueDate” jako SLO, nie „ładną metrykę”
    Skoro KEV publikuje termin oraz wymagane działanie, to możesz budować KPI typu: % KEV w terminie oraz średni czas do remediacji od dateAdded.
  4. Wydziel ścieżkę „ransomware-labeled”
    Tam, gdzie pole knownRansomwareCampaignUse jest ustawione, automatycznie:
    • eskaluj do właściciela usługi,
    • uruchom szybkie skanowanie ekspozycji,
    • sprawdź logi pod kątem exploit patternów.
  5. Zautomatyzuj monitoring zmian (diff)
    GitHubowe mirrorowanie KEV ułatwia śledzenie: co doszło, co zmieniono, co usunięto — przydatne do alertingu i audytu.
    (W 2025 r. raportowano też przypadek usunięcia podatności z KEV po ocenie „insufficient evidence of exploitation”, co pokazuje, że katalog jest kuratorowany, a nie „tylko rośnie”.)

Różnice / porównania z innymi przypadkami

KEV vs CVSS:
CVSS to głównie potencjalny wpływ, KEV to potwierdzona exploitacja + komponent operacyjny (termin, wymagane działanie).

KEV vs NVD (i ogólnie „wszystkie CVE”):
NVD obejmuje ogromny zbiór podatności; KEV jest węższy i nastawiony na „risk that is being realized”. To dobry filtr do sytuacji, gdy backlog CVE jest większy niż realna przepustowość zespołów.

KEV vs „vendor advisories / hype w mediach”:
KEV jest zwykle mniej podatny na szum: jeśli coś jest „głośne”, ale brak dowodów wykorzystania, nie musi trafić do KEV — a jeśli dowody się pojawią, KEV jest jednym z najważniejszych sygnałów, że temat przestał być teoretyczny.

Podsumowanie / kluczowe wnioski

  • W 2025 r. KEV urósł do ok. 1 484 wpisów, a tempo wzrostu (+245) było wyższe niż w 2023–2024.
  • Wpisy KEV są operacyjnie użyteczne, bo zawierają m.in. termin (dueDate), wymagane działanie i oznaczenia (np. ransomware).
  • Jeżeli dziś nie masz procesu „KEV-first”, to przy takim trendzie backlog i ryzyko będą rosnąć szybciej niż zdolność do łatania.

Źródła / bibliografia

  1. SecurityWeek – podsumowanie wzrostu KEV w 2025 r. (1 484 wpisy, +245, 24 ransomware). (SecurityWeek)
  2. Cyble – analiza trendów KEV w 2025 r., przykłady CVE wykorzystywanych przez ransomware, dynamika wzrostu. (Cyble)
  3. GitHub cisagov/kev-data – oficjalne repo-mirror danych KEV i informacje o synchronizacji/aktualizacjach. (GitHub)
  4. known_exploited_vulnerabilities.csv – struktura danych (kolumny m.in. dueDate, requiredAction, knownRansomwareCampaignUse). (GitHub)
  5. NIST (prezentacja) – kontekst BOD 22-01 i rola katalogu KEV w priorytetyzacji remediacji. (NIST Computer Security Resource Center)