Wprowadzenie: Zarządzanie podatnością na zagrożenia oparte na ryzyku w ramach ustawy o odporności cybernetycznej
Współczesne zespoły wiedzą już, że naprawienie każdej luki jest niemożliwe. Najważniejsze jest naprawienie tych właściwych. Właśnie dlatego zarządzanie lukami w zabezpieczeniach oparte na ryzyku stało się preferowanym podejściem dla zespołów DevSecOps. Jednak w Unii Europejskiej nie jest to już tylko najlepsza praktyka. Ustawa o cyberodporności wprowadza konkretne obowiązki prawne, zwłaszcza gdy oprogramowanie zawiera problemy wymienione w… CISKatalog znanych luk w zabezpieczeniach.
W tym nowym kontekście priorytetyzacja luk w zabezpieczeniach przenosi się z wyboru bezpieczeństwa na wymóg zgodności. Zespoły muszą udowodnić, że rozumieją, które luki są aktywnie wykorzystywane i jak podejmują decyzję, co naprawić w pierwszej kolejności. A zegar przestaje być abstrakcyjny: Obowiązki CRA dotyczące raportowania aktywnie wykorzystywanych luk i poważnych incydentów obowiązują od 11 września 2026 r., a pełen zestaw głównych obowiązków będzie obowiązywał od grudnia 2027 r. Niezależnie od tego, jaki model priorytetyzacji stosuje obecnie organizacja, musi on dać się obronić w ramach tego wymogu raportowania w ciągu kilku tygodni, a nie kwartałów.
Zarządzanie podatnościami w oparciu o ryzyko i znane wykorzystywane luki
Zarządzanie podatnościami oparte na ryzyku koncentruje się na rzeczywistym narażeniu, a nie na surowej dotkliwości. Zamiast traktować wszystkie CVE jednakowo, zespoły ustalają priorytety na podstawie stopnia wykorzystania, dostępności i wpływu.
W tym miejscu kluczową rolę odgrywają znane, wykorzystane luki w zabezpieczeniach. Kiedy w systemie pojawia się CVE, CISKatalog znanych luk w zabezpieczeniach potwierdza, że atakujący już go wykorzystują w rzeczywistych środowiskach. Ten sygnał ma znacznie większą wagę niż teoretyczny wynik.
Jeśli chcesz uzyskać głębsze wyjaśnienie tego, czym są KEV i jak je zidentyfikować, możesz przeczytać nasz wcześniejszy wpis Znane, wykorzystywane luki w zabezpieczeniach: co należy naprawić w pierwszej kolejnościW tym artykule skupiamy się na tym, jak KEV wpisują się w modele zgodności i priorytetyzacji zgodnie z ustawą o odporności cybernetycznej.
Czego naprawdę wymaga ustawa o odporności cybernetycznej
Ustawa o odporności cybernetycznej to rozporządzenie UE, które ustanawia obowiązkowe obowiązki w zakresie cyberbezpieczeństwa dla produktów z elementami cyfrowymi sprzedawanych w UE. Nakłada ono na dostawców obowiązek zarządzania lukami w zabezpieczeniach w całym cyklu życia produktu i unikania udostępniania oprogramowania ze znanymi lukami. Zgodnie z oficjalna dokumentacja UE, producenci muszą:
- Identyfikuj i usuwaj luki w zabezpieczeniach w całym cyklu życia produktu
- Zapobiegaj wysyłce oprogramowania ze znanymi lukami w zabezpieczeniach
- Zgłaszaj aktywnie wykorzystywane luki w zabezpieczeniach i poważne incydenty w ciągu 24 godzin od momentu ich wykrycia. Obowiązek raportowania wchodzi w życie 11 września 2026 r.
- Zachowaj dowody radzenia sobie z lukami w zabezpieczeniachcisjony
Innymi słowy, gdy pojawi się luka w zabezpieczeniach, CISKatalog znanych luk w zabezpieczeniach. Ignorowanie go stwarza ryzyko zarówno pod względem bezpieczeństwa, jak i przepisów. Od września 2026 r. ryzyko to będzie wiązało się z koniecznością raportowania.
Czym jest ustawa o odporności cybernetycznej (CRA)
Ustawa o odporności cybernetycznej to rozporządzenie UE, które określa obowiązkowe wymogi dotyczące cyberbezpieczeństwa dla oprogramowania i produktów cyfrowych sprzedawanych w Europie. Wymaga od dostawców zarządzania lukami w zabezpieczeniach w całym cyklu życia produktu i unikania udostępniania oprogramowania z znane wykorzystywane luki w zabezpieczeniach.
Lista kontrolna zarządzania podatnościami na ryzyko CRA Ready
Dlaczego KEV są kluczowe dla zgodności z przepisami CRA
CISKatalog znanych luk w zabezpieczeniach zawiera listę luk CVE, które atakujący już wykorzystują w praktyce. Innymi słowy, eliminuje niejednoznaczność w priorytetyzacji.
Zamiast pytać „Czy to może zostać wykorzystane?”, zespoły muszą teraz zadać sobie znacznie bardziej bezpośrednie pytanie: „Czy to już jest wykorzystywane i czy mimo to to udostępniamy?”
Zgodnie z ustawą o odporności cybernetycznej (Cyber Resilience Act) to rozróżnienie ma znaczenie prawne. W rezultacie, KEV stają się najsilniejszym bodźcem do zawierania umów SLA dotyczących napraw i blokowania wydań. W tym kontekście zarządzanie podatnościami oparte na ryzyku naturalnie wpisuje się w oczekiwania regulacyjne.
Omówiliśmy szczegółowo kwestię zgłaszania incydentów podczas wspólnej sesji z Narimanem Agą-Tagiyevem, architektem cyberbezpieczeństwa w SecureHabits.nl: 24 godziny na zgłoszenie: jak przetrwać zegar powiadomień CRA. Dokument przedstawia trzyetapowy cykl życia incydentu. CRA oczekuje, że organizacje będą śledzić zdarzenia od momentu zgłoszenia problemu, przez dochodzenie, aż do potwierdzonego incydentu, od którego rozpoczyna się 24-godzinne okno raportowania.
CVSS, EPSS i KEV służą różnym celom
Aby prawidłowo ustalić priorytety, zespoły muszą najpierw zrozumieć, co tak naprawdę przedstawia każdy sygnał.
- CVSS pokazuje potencjalny wpływ
- EPS szacuje prawdopodobieństwo eksploatacji
- CISKatalog znanych luk w zabezpieczeniach potwierdza, że eksploatacja już ma miejsce
Każda metryka rozpatrywana osobno może wprowadzać w błąd. Jednak gdy zespoły używają ich razem, zyskują znacznie jaśniejszy kontekst. Z tego powodu połączenie tych sygnałów stanowi podstawę skutecznego zarządzania podatnościami opartego na ryzyku.
Zarządzanie podatnościami oparte na ryzyku w praktyce
W praktyce model ustalania priorytetów oparty na ryzyku przebiega według jasnego i powtarzalnego schematu.
- Wykrywaj luki w kodzie i zależnościach
- Sprawdź mecze z CISKatalog znanych luk w zabezpieczeniach
- Oceń prawdopodobieństwo wykorzystania luk w zabezpieczeniach za pomocą EPSS
- Sprawdź dostępność w swojej aplikacji lub pipeline
- Zastosuj reguły naprawcze na podstawie narażenia i roli produktu
W rezultacie zespoły przestają traktować listy luk w zabezpieczeniach jako statyczne zaległości i zaczynają traktować je jako konkretne dane dotyczące bezpieczeństwa.cisJony.
Różne modele priorytetyzacji stosowane obecnie przez zespoły
Nie wszystkie zespoły traktują ryzyko w ten sam sposób. Zazwyczaj, w rzeczywistych środowiskach widzimy trzy powszechne modele.
1. Model „najpierw powaga”
Zespoły naprawiają problemy bazując wyłącznie na CVSS.
Ten model jest łatwy do wdrożenia, jednak generuje on sporo szumu informacyjnego i nie spełnia oczekiwań Ustawy o Cyberodporności.
2. Model oparty na prawdopodobieństwie
Zespoły wykorzystują EPSS, aby przewidywać, co atakujący mogą wykorzystać w następnej kolejności.
To podejście poprawia koncentrację. Mimo to nadal pomija luki, które atakujący już wykorzystują.
3. Model świadomy eksploatacji
Zespoły łączą EPSS z CISKatalog znanych luk w zabezpieczeniach i kontekst techniczny.
Natomiast model ten najlepiej wspiera zarządzanie podatnością na ryzyko i jest bezpośrednio powiązany z obowiązkami CRA.
W jaki sposób Xygeni wdraża priorytetyzację gotowości CRA
Xygeni pomaga zespołom przekształcić regulacje w codzienny przepływ pracy. Zamiast polegać wyłącznie na dashboards, Xygeni wymusza decisdokładnie tam, gdzie zachodzą zmiany w kodzie. W rezultacie priorytetyzacja staje się automatyczna i spójna.
Kluczowe możliwości obejmują:
- Automatyczna korelacja z CISKatalog znanych luk w zabezpieczeniach
- Ocena prawdopodobieństwa wykorzystania potencjału na podstawie EPSS
- Analiza dostępności w celu potwierdzenia rzeczywistego narażenia
- Guardrails ten blok łączy się lub zwalnia, gdy KEV wpływają na dostępny kod
- Zautomatyzowana naprawa za pomocą zabezpieczeń pull requests
- Pełne dzienniki audytu w celu wykazania zgodności z ustawą o odporności cybernetycznej
Krótko mówiąc, zespoły nie tylko dostrzegają ryzyko. Działają w sposób powtarzalny i możliwy do zweryfikowania.
Przykład Dev to Dev: KEV blokujący wydanie
Wyobraź sobie, że aktualizacja zależności wprowadza CVE.
- Luka pojawia się w CISKatalog znanych luk w zabezpieczeniach
- Xygeni wykrywa to podczas pull request
- Analiza dostępności potwierdza wykonanie ścieżki kodu
- Guardrails zablokuj scalanie automatycznie
- Bot proponuje bezpieczną aktualizację i przeprowadza testy
Deweloper rozwiązuje problem w ramach tego samego procesu. Wersja pozostaje zgodna z wymaganiami. Nie są wymagane żadne spotkania.
Innymi słowy, jest to zarządzanie podatnościami oparte na ryzyku, stosowane dokładnie tam, gdzie pracują programiści.
Dlaczego to ma znaczenie poza zgodnością
Chociaż ustawa o odporności cybernetycznej (Cyber Resilience Act) zapoczątkowała tę zmianę, korzyści sięgają dalej. Zespoły, które priorytetowo traktują wykorzystanie KEV, EPSS i kontekstu:
- Zmniejsz zmęczenie czujnością
- Skróć czas naprawy
- Unikaj łatek awaryjnych
- Dostarczaj bezpieczniejsze oprogramowanie z pewnością
Ogólnie rzecz biorąc, przestrzeganie zasad jest naturalną konsekwencją właściwego dbania o bezpieczeństwo.
Podsumowanie: CRA wprowadza obowiązkowe zarządzanie oparte na ryzyku
Ustawa o odporności cybernetycznej formalizuje to, czego zespoły ds. bezpieczeństwa nauczyły się już na własnej skórze. Nie wszystkie luki w zabezpieczeniach mają takie samo znaczenie.
CISKatalog znanych luk w zabezpieczeniach definiuje, czego atakujący używają obecnie. EPSS przewiduje, czego użyją w przyszłości. Kontekst pokazuje, czy ma to na Ciebie wpływ.
Razem tworzą one nowoczesne zarządzanie podatnościami oparte na ryzyku, a od 11 września 2026 roku przestaje być ono opcjonalne. Zespoły, które potrafią już odpowiedzieć na pytanie „czy to jest exploit i czy mimo to powinniśmy to udostępniać?”, bez problemu zdążą dotrzymać terminu raportowania CRA. Zespoły, które nie potrafią tego zrobić, przekonują się, jak krótkie są w rzeczywistości 24 godziny.
Xygeni pomaga zespołom stosować ten model w sposób ciągły, automatyczny i w sposób akceptowany przez programistów.
O autorze
Scenariusz Fatima Said, Menedżer ds. marketingu treści specjalizujący się w bezpieczeństwie aplikacji w Bezpieczeństwo Xygeni.
Fátima tworzy przyjazne dla programistów treści oparte na badaniach na temat AppSec, ASPMi DevSecOps. Przekłada złożone koncepcje techniczne na jasne, praktyczne wnioski, które łączą innowacje w dziedzinie cyberbezpieczeństwa z wpływem na biznes.
