TL; DR
Większość list podatności wskazuje, co może pójść nie tak. CISKatalog KEV podpowie Ci, co aktualnie idzie nie tak. Znane wykorzystywane luki w zabezpieczeniach (KEV) to luki CVE, co do których potwierdzono, że są aktywnie wykorzystywane. CISA prowadzi oficjalny katalog i narzuca harmonogram działań naprawczych agencjom federalnym poprzez wiążącą dyrektywę operacyjną 22-01. Większość organizacji prywatnych korzysta z tej samej listy, aby odciąć się od szumu alarmowego i zidentyfikować, co faktycznie wymaga naprawy w pierwszej kolejności.
CVSS, EPSS i KEV odpowiadają na trzy różne pytania. CVSS mierzy teoretyczną wagę – jak poważna może być sytuacja? EPSS przewiduje prawdopodobieństwo wykorzystania w ciągu 30 dni – jak prawdopodobne jest, że to atak? KEV potwierdza aktywną eksploatację – czy to jest atakowane właśnie teraz? Luka z umiarkowanym wynikiem CVSS, wysokim wynikiem EPSS i znacznikiem KEV jest bardziej pilna niż krytyczna wartość CVSS bez dowodów na wykorzystanie. Te trzy sygnały działają razem, a nie zamiennie.
KEV w Twoim przypadku nie jest ryzykiem teoretycznym — ma określony termin. W przypadku KEV często stosuje się komponenty, struktury, kontenery i inne rozwiązania innych firm. CI/CD zależności, które zespoły uznają za bezpieczne. Luka CVE-2023-4966 (CitrixBleed) została potwierdzona w ciągu kilku dni od ujawnienia. Luka CVE-2024-1086 została wykryta przez grupy ransomware wkrótce po jej wpisaniu do katalogu KEV. standard Okres wdrażania poprawek dla KEV skierowanych do Internetu wynosi 1–3 dni, co nie jest typowym cyklem poprawek.
Ten post obejmuje: czym są KEV i czym różnią się od CVE, CVSS i EPSS; jak zbudować przepływ pracy dotyczący priorytetyzacji CISKatalog i jak Xygeni automatyzuje korelację KEV, egzekwowanie przepisów ochronnych i naprawę w całym CI/CD pipelines — w tym działająca polityka ochronna YAML.
Czym są znane wykorzystywane luki w zabezpieczeniach (KEV)?
Każdy skaner luk w zabezpieczeniach generuje wyniki uszeregowane według ważności CVSS. Problem polega na tym, że CVSS mierzy teoretyczny wpływ, a nie aktywną eksploatację. CISKatalog znanych luk w zabezpieczeniach (KEV) rozwiązuje inny, pilniejszy problem: zawiera listę luk CVE wykorzystywanych obecnie przez atakujących, wraz z terminami wdrażania poprawek. Dla każdego zespołu zastanawiającego się, co naprawić w pierwszej kolejności, jest to najbardziej podatny na podjęcie działań sygnał.
Znane wykorzystywane luki w zabezpieczeniach (KEV) jest Potwierdzono, że luki w zabezpieczeniach wymienione na liście CVE są wykorzystywane w praktyce. Amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) utrzymuje oficjalne Katalog KEV i nakazuje harmonogramy naprawcze poprzez Wiążąca Dyrektywa Operacyjna 22-01. Wiele organizacji prywatnych korzysta obecnie z tej listy w celu ustalenia priorytetów wdrażania poprawek.
Chociaż CVSS wyniki mierzą potencjał wpływ, KEV reprezentują aktywny eksploatacja. Innymi słowy, zmieniają się one w „być wykorzystywanym”, co wymaga szybszych umów SLA i zautomatyzowanych guardrails.
KEV vs CVE vs EPSS
Zespoły ds. bezpieczeństwa często mylą te powiązane terminy. Zrozumienie różnicy jest kluczowe dla precyzyjnego określenia ryzyka.
| Akronim | Źródło | Cel |
|---|---|---|
| CVE | NDV | Unikalny identyfikator ujawnionej luki w zabezpieczeniach. |
| CVSS | NVD / PIERWSZY | Mierzy teoretyczną powagę (wpływ + podatność na wykorzystanie). |
| EPS | FIRST.org | Przewiduje prawdopodobieństwo eksploatacji w ciągu 30 dni. |
| KEW | CISA | Potwierdza rzeczywiste wykorzystanie oprogramowania i ustala terminy wdrażania poprawek. |
Razem systemy te tworzą hierarchię ryzyka: CVSS pokazuje, jak poważny może być dany przypadek, EPSS pokazuje, jak prawdopodobne jest wystąpienie takiego zdarzenia, a Znane Wykorzystane Luki pokazują, co się faktycznie dzieje.
Dalsza lektura: Wynik CVSS: Jak działa punktacja CVSS oraz EPSS a CVSS: jaka jest różnica?
Dlaczego KEV-y są ważne dla deweloperów i CISOs
Po pierwsze, KEV-y podkreślają zachowanie atakującego na żywoPo drugie, często wiążą się one komponenty innych firm, frameworki, kontenery lub CI/CD zależności, które zespoły uznają za bezpieczne. W związku z tym, Opóźniona naprawa może otworzyć ścieżki bocznego ruchu w obrębie infrastruktury kompilacji i dostarczania.
Ostatnie przykłady:
- CVE-2024-1086 (Linux nf_tables): dodany do katalogu KEV; wykorzystany przez grupy ransomware w połowie 2024 r.
- CVE-2023-4966 (CitrixBleed): potwierdzone wykorzystanie danych w ciągu kilku dni od ujawnienia; wymuszone cykle wprowadzania awaryjnych poprawek na całym świecie.
Na wynos: Pojazdy KEV nie stanowią potencjalnego zagrożenia, są aktywny jedynki. Dlatego każdą znaną, wykorzystywaną lukę należy traktować jako „napraw-teraz”chyba że analiza dostępności dowodzi inaczej.
Jak śledzić i priorytetyzować znane, wykorzystywane luki w zabezpieczeniach
Na początek sprawdź oficjalne CISKatalog znanych luk w zabezpieczeniach i zaznacz wszystkie pasujące wyniki w skanerze bezpieczeństwa. Następnie wykorzystaj te informacje, aby zdecydować, które poprawki należy wykonać w pierwszej kolejności. Dodatkowo połącz Znane wykorzystywane luki w zabezpieczeniach w Wyniki EPSS aby wyeliminować szum informacyjny i skupić się na słabościach, które rzeczywiście mają wpływ na działający kod.
Przepływ pracy krok po kroku:
- Synchronizuj dane: Pobierz najnowsze aktualizacje z CISCodzienna lista, którą możesz łączyć z innymi źródłami informacji o podatnościach.
- Wyniki tagów: Oznacz każde znalezisko jako „Znane jako wykorzystane”, gdy jego identyfikator będzie zgodny z CISLista.
- Sprawdź dostępność: Sprawdź, czy podatny kod faktycznie działa w Twojej aplikacji lub kompilacji pipeline.
- Ocena podatności na wykorzystanie: Zastosowanie EPS aby dowiedzieć się, jakie inne problemy mogą wkrótce stać się przedmiotem zainteresowania.
- Zastosuj terminy:
- Luki w zabezpieczeniach Internetu: naprawa w ciągu 1–3 dni.
- Wewnętrzne: naprawa w ciągu tygodnia.
- Kod nie jest używany: zwracaj na niego uwagę i często go sprawdzaj.
- Zautomatyzuj odpowiedzi: System blokuje niebezpieczne połączenia, otwiera bezpieczne pull requestsi rejestruje wyjątki, aby mieć pewność, że zespoły niczego nie przeoczą.
Od świadomości do działania: automatyzacja napraw z Xygeni
W praktyce, ręczne wykonywanie wszystkich tych czynności nie jest skalowalne. Dlatego Xygeni łączy znane, wykorzystywane luki w zabezpieczeniach bezpośrednio z Twoim CI/CD przepływy pracy, zmieniające alerty w rzeczywiste, kierowane działania.
- Inteligentna korelacja: Wykryto dopasowania CVE do CISLista i wyróżnienia problemów, które należy rozwiązać natychmiast pull requests.
- Dostępność + Możliwość wykorzystania: Potwierdza, czy ścieżka z podatnym kodem działa i łączy się EPS dane dla precise priorytetyzacja.
- Guardrails: Zatrzymuje ryzykowne łączenia lub wdrożenia, gdy wykorzystana luka wpływa na wrażliwe pliki lub usługi.
- Auto-naprawa: Otwiera bezpieczne żądania ściągnięcia, sprawdza, czy nie występują zmiany powodujące przerwanie działania, i przeprowadza testy przed scaleniem.
- Dzienniki audytu: Prowadzi przejrzyste zapisy tego, co i kiedy zostało naprawione, wspierając w ten sposób wewnętrzne cele bezpieczeństwa.
Krótko mówiąc, informacje o zagrożeniach pokazują, co jest celem ataku, a Xygeni dba o szybką, bezpieczną i automatyczną naprawę.
Przykładowa polityka barier ochronnych (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7d
Ta zasada egzekwuje bez łączenia w przypadku aktywnych znanych luk w zabezpieczeniach, powiadamia odpowiednie kanały i automatycznie tworzy żądanie naprawy, wszystko w Twoim CI/CD guardrails.
Mini sprawa: Zapobieganie rozmieszczeniu KEV
- Tydzień 1: Nowa biblioteka open-source przechodzi SAST ale obejmuje CVE-2023-4966.
- Tydzień 2: Korelacja KEV firmy Xygeni wykrywa ją w najnowszej wersji CISAktualizacja.
- Tydzień 3: Guardrails Zatrzymaj scalanie; funkcja automatycznej naprawy zaproponuje poprawioną wersję.
Wynik: Zespół uniknął wysyłki znana wykorzystana luka do produkcji i restauracji pipeline przepływu w ramach tego samego sprintu.
Xygeni koreluje otwarte CVE z CISKatalog KEV automatycznie oznacza znane, wykorzystane luki w zabezpieczeniach pull requests, egzekwuje guardrails które blokują niebezpieczne połączenia i otwierają żądania naprawcze z wbudowaną walidacją zmian niezgodnych z przepisami.
