Priorytetyzacja podatności: jak zdecydować, co naprawić najpierw

Dlaczego sama ważność nie wystarcza

Domyślnie sortuje się według CVSS i schodzi w dół od krytycznych. Wydaje się to obiektywne, ale zawodzi z trzech powodów:

• CVSS mierzy ważność, a nie ryzyko. Opisuje, jak poważna byłaby podatność, gdyby ją wykorzystano. Nie mówi, czy ktokolwiek ją wykorzystuje ani czy ma ona znaczenie w Państwa produkcie.
• Zbyt duża część listy jest pilna. Wiele opublikowanych CVE ma ocenę wysoką lub krytyczną, więc kolejka posortowana według CVSS stawia na szczycie setki znalezisk i nie daje możliwości wyboru między nimi.
• Lista jest tylko tak dobra jak inwentarz. Skaner odczytujący lockfile zgłasza zależności deweloperskie, które nigdy nie są dostarczane, i pomija pakiety pobrane przez build poza menedżerem pakietów. Jedno i drugie zniekształca ranking, zanim jeszcze powstanie.

Priorytetyzacja dodaje brakujące pytania: czy podatność jest wykorzystywana, jak prawdopodobne jest, że będzie, i jakie będą dla Państwa skutki, jeśli tak się stanie.

Sygnały

Sygnał	Na jakie pytanie odpowiada	Źródło
CVSS	Jak poważna jest podatność, jeśli zostanie wykorzystana? Skala od 0 do 10.	FIRST (standard); oceny publikują NVD i dostawcy
EPSS	Jak prawdopodobne jest wykorzystanie w ciągu najbliższych 30 dni? Prawdopodobieństwo od 0 do 1.	FIRST, aktualizowane codziennie, bezpłatne
CISA KEV	Czy jest już wykorzystywana w rzeczywistych atakach?	Katalog Known Exploited Vulnerabilities agencji CISA
SSVC	Biorąc pod uwagę wykorzystanie, skutki i Państwa misję, co należy zrobić: śledzić, zająć się czy działać?	Drzewa decyzyjne CERT/CC i CISA
Państwa kontekst	Czy podatna wersja jest dostarczana? Czy jest wystawiona? Jak ważny jest produkt? Czy istnieje poprawka?	Państwa inwentarz, architektura i rejestry zasobów

Sygnały publiczne opisują podatność. Tylko Państwa kontekst opisuje Państwa ryzyko, a większość zespołów czerpie go z najmniej wiarygodnego źródła.

Praktyczna metoda priorytetyzacji

Większość programów dochodzi do jakiejś wersji tych poziomów. Terminy należy ustalić zgodnie z tym, czego wymagają Państwa polityka i klienci.

1. Naprawić teraz: znane wykorzystywane, w dostarczanym oprogramowaniu. Wszystko, co jest na liście KEV lub ma inne dowody wykorzystania i znajduje się w wydanym buildzie. Dla porównania: dyrektywa BOD 26-04 agencji CISA daje federalnym agencjom USA zaledwie 3 dni na wpis KEV w systemie wystawionym publicznie.
2. Naprawić następnie: duże prawdopodobieństwo wykorzystania i wysoka ważność. Wysoki wynik EPSS w połączeniu z wysokim lub krytycznym CVSS, w dostarczanym i wystawionym komponencie. Należy wybrać próg EPSS, który daje kolejkę możliwą do faktycznego przerobienia przez Państwa zespół.
3. Naprawiać rutynowo: wszystko inne, co jest dostarczane. Należy łączyć to w regularne aktualizacje zależności, zamiast traktować każde znalezisko jako incydent.
4. Udokumentować: nie dotyczy. Podatny pakiet jest obecny, ale podatny kod nie jest używany, albo komponent nie jest dostarczany. Uzasadnienie należy zapisać jako oświadczenie VEX, aby to samo znalezisko nie wracało do przeglądu i aby pytający klienci mogli zobaczyć powód.

Następnie należy stale aktualizować ranking. Podatność z poziomu trzeciego może z dnia na dzień przejść na poziom pierwszy, gdy zostanie dodana do KEV lub gdy jej wynik EPSS gwałtownie wzrośnie.

Podatności, które nigdy nie trafiają do rankingu

Każda metoda priorytetyzacji szereguje znaleziska, które ma przed sobą. Podatny pakiet, którego skaner nigdy nie zobaczył, nie tworzy znaleziska, więc nigdy nie otrzymuje oceny CVSS ani wyniku EPSS i nie jest dopasowywany do KEV. Nie ma niskiej pozycji w rankingu. Nie ma w nim żadnej pozycji, a i tak jest dostarczany.

Zdarza się to częściej, niż się wydaje, ponieważ większość skanerów ustala zawartość Państwa oprogramowania na podstawie plików: lockfile, manifestów lub wyniku buildu. Wszystko, co build pobiera, a czego nie wymienia żaden lockfile, jest ukrytą zależnością, a narzędzia oparte na plikach ją pomijają:

• Hooki instalacyjne. Kod pobierany przez skrypty npm preinstall i postinstall, droga wykorzystana przez robaka Shai-Hulud.
• Skrypty buildu. Na przykład skrypty buildu w Rust, które pobierają kod w czasie buildu.
• Obrazy bazowe. Obraz bazowy buildu kontenera i jego warstwy systemu operacyjnego.
• Cache. Pakiety przywrócone z cache CI zamiast zainstalowanych z lockfile.

Późniejsze skanowanie wyniku nie zamyka tej luki. Gotowy plik binarny, zwłaszcza kod kompilowany, taki jak Rust, zmusza skaner do zgadywania, co do niego trafiło. A ponieważ buildy domyślnie nie są odtwarzalne, ponowny build tego samego commita w późniejszym czasie nie gwarantuje tych samych zależności.

SBOM z czasu buildu zaczyna od drugiego końca. CRACI uruchamia Państwa zadania GitHub Actions i widzi ruch wchodzący do każdego buildu, więc rejestruje każdy pakiet faktycznie pobrany przez zadanie, łącznie z ukrytymi zależnościami. Każdy SBOM ma stan kompletności, który informuje, kiedy czegoś nie dało się zobaczyć. W praktyce CRACI znalazł podatne pakiety, których Snyk i Aikido nie zgłosiły, ponieważ w ich skanach brakowało tych komponentów. To właśnie te znaleziska, których metoda priorytetyzacji nigdy nie ma szansy uszeregować.

Kontekst: to, czego skanery nie ocenią za Państwa

Czy podatna wersja jest faktycznie dostarczana?

To pytanie usuwa najwięcej szumu. Framework testowy w lockfile, pakiet przypięty w gałęzi, która nigdy nie trafia do wydania, odrzucany etap kontenera: nic z tego nie dociera do klientów. SBOM zarejestrowany podczas buildu odpowiada na to pytanie na podstawie tego, czego faktycznie użył build wydania, a nie tego, co deklaruje repozytorium.

Które wydania ją zawierają i od kiedy?

Znalezisko w produkcie dostarczanym klientom, dotyczące każdego wydania od zeszłej wiosny, jest ważniejsze niż to samo znalezisko w narzędziu wewnętrznym. Znajomość okresu narażenia mówi też, co należy ujawnić.

Czy podatny kod jest osiągalny?

Analiza osiągalności śledzi, czy Państwa kod może wywołać podatną funkcję w zależności. Oferuje ją kilka narzędzi SCA i skutecznie przesuwa ona nieosiągalne znaleziska w dół listy. Należy ją traktować jako jeden z sygnałów wejściowych: widzi tylko ścieżki kodu, za którymi analiza potrafi podążyć, a osiągalna funkcja to nie to samo co funkcja możliwa do wykorzystania.

Czy jest wystawiona i czy istnieje poprawka?

Usługa dostępna z internetu ma wyższą pozycję niż zadanie wsadowe w sieci prywatnej. Podatność z wersją zawierającą poprawkę taniej jest zamknąć niż taką, która wymaga środków łagodzących. Obie te rzeczy zmieniają kolejność, a nie to, czy podatność zostanie obsłużona.

Zarządzanie podatnościami oparte na ryzyku

Zarządzanie podatnościami oparte na ryzyku to nazwa tej samej idei na poziomie programu: szeregowanie według dowodów wykorzystania, prawdopodobieństwa, ważności i kontekstu biznesowego, mierzenie tempa zamykania najbardziej ryzykownych znalezisk i akceptacja tego, że znaleziska niskiego ryzyka mogą pozostać otwarte. Zmieniają się też metryki. Zamiast łącznej liczby otwartych podatności należy śledzić, ile znanych wykorzystywanych podatności jest otwartych w dostarczanym oprogramowaniu i jak długo pozostają otwarte.

Narzędzia do priorytetyzacji podatności

Większość szeregowania wykonują dziś trzy rodzaje narzędzi:

• Platformy zarządzania podatnościami infrastruktury, takie jak Tenable, Qualys i Rapid7, oceniają hosty, punkty końcowe i zasoby chmurowe własnymi ocenami ryzyka, opartymi na danych o wykorzystaniu.
• Narzędzia SCA i bezpieczeństwa aplikacji, takie jak Snyk, Endor Labs i Semgrep, szeregują znaleziska w zależnościach, a kilka z nich stosuje analizę osiągalności.
• Narzędzia open source, takie jak Grype, który podaje dane EPSS i KEV wraz ze znaleziskami, oraz Dependency-Track, który stale analizuje SBOM-y.

Porównanie narzędzi do zarządzania podatnościami omawia je po kolei.

Jak CRACI wspiera priorytetyzację

CRACI zaczyna tam, gdzie ranking najczęściej zawodzi: od inwentarza. Uruchamia Państwa zadania GitHub Actions i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache i ukrytymi zależnościami, których nie wymienia żaden lockfile.

• Znaleziska dla tego, co dostarczono. Monitorowane SBOM-y są stale ponownie oceniane, a widoki organizacji agregują znaleziska z wielu buildów i repozytoriów. Każdy pakiet pokazuje swoje biuletyny wraz z ważnością oraz pakiety, które go pobierają.
• Okres narażenia. Historia buildów pokazuje, które wcześniejsze buildy zawierały podatną zależność, bezpośrednią lub przechodnią, dzięki czemu wiedzą Państwo, których wydań to dotyczyło i jak długo.
• Triage i przekazywanie. Zespoły bezpieczeństwa wykonują triage znalezisk i przekazują każde z nich zespołowi odpowiedzialnemu za poprawkę. CRACI obsługuje VEX do zapisywania, że podatność nie dotyczy Państwa produktu.
• Bramki. Bramki polityk mogą blokować build na podstawie znalezisk, w tym build zawierający określoną CVE.

CRACI nie oferuje analizy osiągalności. Jeśli to najważniejszy dla Państwa sygnał, należy wybrać jedno z narzędzi SCA, które ją oferują. Pełne możliwości opisuje strona śledzenie podatności.

Priorytetyzacja podatności: najczęściej zadawane pytania

Czym jest priorytetyzacja podatności?

Priorytetyzacja podatności to decydowanie, które znane podatności naprawić najpierw, które mogą poczekać, a które w ogóle Państwa nie dotyczą. Szereguje znaleziska według tego, jak prawdopodobne jest ich wykorzystanie i jakie szkody spowodowałoby ono w Państwa środowisku, a nie tylko według ważności.

Jak priorytetyzować podatności?

Należy zacząć od dokładnego inwentarza, aby szeregować podatności w oprogramowaniu, które faktycznie jest dostarczane. Na pierwszym miejscu należy postawić wszystko z listy Known Exploited Vulnerabilities agencji CISA, a resztę uszeregować według prawdopodobieństwa wykorzystania (EPSS) i ważności (CVSS), z uwzględnieniem kontekstu: wystawienia, znaczenia produktu i dostępności poprawki. Podatności, które Państwa nie dotyczą, należy zapisać jako oświadczenia VEX.

Czy CVSS wystarczy do priorytetyzacji podatności?

Nie. CVSS mierzy, jak poważna jest podatność, a nie jak prawdopodobne jest jej wykorzystanie ani jakie ma znaczenie dla Państwa. Szeregowanie wyłącznie według CVSS klasyfikuje dużą część backlogu jako wysoką lub krytyczną, a większość tych podatności nigdy nie zostaje wykorzystana.

Czym jest zarządzanie podatnościami oparte na ryzyku?

Zarządzanie podatnościami oparte na ryzyku szereguje i naprawia podatności według ryzyka, jakie stwarzają dla Państwa organizacji, łącząc dowody wykorzystania, prawdopodobieństwo, ważność i kontekst biznesowy, zamiast przerabiać je według wyniku CVSS lub wieku.

Czym EPSS różni się od KEV?

EPSS to prognoza: szacowane prawdopodobieństwo, że CVE zostanie wykorzystana w ciągu najbliższych 30 dni. KEV to rejestr: katalog agencji CISA obejmujący podatności z dowodami wykorzystania w rzeczywistych atakach. Wpis w KEV to fakt; wynik EPSS to prawdopodobieństwo. Najpierw należy użyć KEV, a EPSS do uszeregowania całej reszty.

Czy analiza osiągalności zastępuje priorytetyzację?

Nie, to kolejny sygnał wejściowy. Osiągalność sprawdza, czy Państwa kod może wywołać podatną funkcję w zależności. Usuwa znaleziska, których nie da się wywołać, ale nie mówi nic o prawdopodobieństwie wykorzystania i obejmuje tylko kod, za którym analiza potrafi podążyć.