Jak ograniczyć szum w zarządzaniu podatnościami

Skąd bierze się szum podatności

Weźmy jeden backlog i posortujmy go według źródła każdego znaleziska. Poniższe liczby są ilustracyjne, a nie są benchmarkiem, ale kategorie to te, które zespoły znajdują, gdy przeglądają próbkę własnego backlogu.

Źródło znaleziska	Z 1000 znalezisk (ilustracyjnie)	Krok, który je usuwa
Komponenty, których Państwo nie dostarczają: wpisy w lockfile i manifestach, warstwy buildera, narzędzia deweloperskie i testowe	300	1. Poprawić inwentarz
To samo CVE zgłoszone przez kilka narzędzi lub raz na każde repozytorium	250	2. Liczyć każde znalezisko raz
Błędne dopasowania: kolizje nazw CPE, backporty dystrybucji	80	1. Poprawić inwentarz
Prawdziwe znaleziska, których nie da się wykorzystać w Państwa produkcie	150	4. Dodać kontekst wykorzystania
Prawdziwe znaleziska, dla których nie ma jeszcze poprawki	70	5. Decyzja w ramach polityki, z datą wygaśnięcia
Znaleziska bez właściciela	50	5. Przekazać właścicielowi
Pozostaje do uszeregowania i naprawy	100	Priorytetyzacja

Jedno rozróżnienie ułatwia resztę strony. Część tych znalezisk to wyniki fałszywie dodatnie: znalezisko jest błędne, bo komponentu nie ma albo wersja nie jest podatna. Inne to szum: znalezisko jest prawdziwe, ale nie zmienia tego, co Państwo robią w tym tygodniu. Wymagają różnych rozwiązań, a mylenie ich sprawia, że zespoły wyciszają prawdziwe znaleziska albo spierają się o błędne.

Wynik fałszywie dodatni: znalezisko jest błędne	Szum: prawdziwe, ale niepilne
Komponentu nie ma w tym, co Państwo dostarczają	Podatnego kodu nie da się osiągnąć ani wywołać w Państwa produkcie
Dopasowanie jest błędne: kolizja CPE albo backport poprawki ukryty za numerem wersji	Poprawka jeszcze nie istnieje albo produkt jest wewnętrzny i niewystawiony
Rozwiązanie: poprawić inwentarz i dopasowywanie	Rozwiązanie: kontekst, udokumentowana decyzja i właściciel

Krok 1. Inwentarz zgodny z tym, co Państwo dostarczają

To największa pojedyncza dźwignia, ponieważ każdy kolejny krok mnoży błędy inwentarza. Komponent, który jest na liście, ale nigdy nie jest dostarczany, generuje znalezisko w każdym skanerze, każdym repozytorium i każdym wydaniu.

• Rejestrować z buildu. Inwentarz należy budować z tego, czego faktycznie użył build wydania, a nie z manifestów ani ze skanu gotowego artefaktu. SBOM z czasu buildu zawiera to, co pobrało zadanie, w tym to, czego nie wymienia żaden lockfile.
• Identyfikować komponenty za pomocą PURL. Adres URL pakietu, taki jak pkg:npm/[email protected], dokładnie określa ekosystem, pakiet i wersję. Dopasowywanie do biuletynów kluczowanych przez PURL, takich jak biuletyny ekosystemów w OSV, eliminuje błędne dopasowania wynikające ze zgadywania CPE na podstawie nazwy produktu.
• Dla pakietów systemu operacyjnego stosować dopasowywanie uwzględniające dystrybucję. Debian i inne dystrybucje przenoszą poprawki bezpieczeństwa do wersji, którą dostarczyły, zamiast ją aktualizować, więc numer wersji może wyglądać na starszy niż poprawka upstream. Należy dopasowywać do własnego trackera bezpieczeństwa dystrybucji, a nie do zakresów wersji upstream.
• Śledzić kompletność. Trzeba wiedzieć, kiedy inwentarz czegoś nie zobaczył, zamiast zakładać, że jest kompletny. Brakujący komponent jest gorszy niż ten, który generuje szum: nie daje żadnego znaleziska.

Przykład. Lockfile usługi Node.js zawiera [email protected], bibliotekę dopasowywania wzorców glob, od której zależą narzędzia testowe i buildowe. Skan lockfile zgłasza CVE-2024-4067, podatność typu odmowa usługi przez wyrażenie regularne, poprawioną w 4.0.8. Zadanie wydania instaluje wyłącznie zależności produkcyjne, poleceniem npm ci --omit=dev, więc micromatch nigdy nie trafia do dostarczanego buildu. Zapis tego buildu go nie zawiera, a znalezisko nigdy nie trafia do backlogu. CVE jest prawdziwe; dla tego produktu znalezisko jest wynikiem fałszywie dodatnim.

Krok 2. Liczyć każde znalezisko raz

To samo CVE przychodzi z narzędzia SCA, skanera kontenerów i platformy SBOM, a do tego jeszcze raz dla każdego repozytorium, które używa danej biblioteki. Deduplikację należy prowadzić według jednego klucza: adres URL pakietu, wersja i CVE. Na przykład pkg:npm/[email protected] z CVE-2024-45296 to jedno znalezisko, niezależnie od tego, ile narzędzi je zgłasza.

• Liczyć jedno znalezisko na dostarczany artefakt, a nie jedno na skaner.
• Agregować z wielu buildów i repozytoriów, aby CVE we współdzielonej bibliotece było jedną decyzją stosowaną wszędzie, a nie czterdziestoma zgłoszeniami.
• Konsolidować nakładające się skanery. Prosta zasada: znaleziska w zależnościach pochodzą z jednego źródła SCA lub SBOM, znaleziska w obrazach z jednego skanera kontenerów, a znaleziska we własnym kodzie z jednego narzędzia SAST. Jeśli dwa narzędzia zgłaszają ten sam sygnał, należy zachować to, które jest bliżej tego, co jest dostarczane (SAST vs SCA).

Krok 3. Dostarczać mniej

Każda zależność, której Państwo nie dostarczają, to źródło znalezisk, którymi nigdy nie trzeba się zajmować.

• Usuwać nieużywane zależności. Większość projektów ma kilka pakietów, których nic już nie importuje.
• Aktualizować pakiet, który wciąga podatne zależności. Express 4.19.2 przypina [email protected] i [email protected], które mają CVE-2024-45590 i CVE-2024-45296. Bez nadpisań nie da się ich zaktualizować osobno. Express 4.20.0, wydany we wrześniu 2024 r., zależy od poprawionych wersji, więc jedna aktualizacja usuwa oba problemy (zależności przechodnie).
• Używać minimalnych obrazów bazowych. Obrazy slim i distroless zawierają mniej pakietów systemu operacyjnego, więc dotyczy ich mniej biuletynów. Dźwignie specyficzne dla obrazów opisuje skanowanie kontenerów.
• Przypinać i aktualizować świadomie. Pliki lockfile i digesty utrzymują stabilny inwentarz między buildami.
• Blokować buildy zawierające znaną podatną wersję. Bramka polityki, która zatrzymuje build, nie wpuszcza podatnej biblioteki, zanim stanie się znaleziskiem wymagającym triażu.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Krok 4. Dodać kontekst wykorzystania

To, co zostaje po krokach od 1 do 3, jest prawdziwe. Kontekst decyduje, co z tego jest pilne.

• VEX. „Nie dotyczy” należy zapisać raz, z uzasadnieniem, jako oświadczenie VEX i wykorzystywać je ponownie w kolejnych wydaniach i u kolejnych klientów. Gdy klienci przesyłają własne skany Państwa produktu, te same zapisy na nie odpowiadają: zob. jak skalować PSIRT oraz, w sprawie szablonów odpowiedzi, jak odpowiadać klientom po ataku na łańcuch dostaw.
• Osiągalność, jeśli oferują ją Państwa narzędzia, pokazuje, czy Państwa kod może wywołać podatną funkcję. Pomaga, w pewnych granicach (analiza osiągalności).
• Sygnały wykorzystania. CISA KEV informuje, że podatność jest wykorzystywana w rzeczywistych atakach; EPSS szacuje prawdopodobieństwo wykorzystania w ciągu najbliższych 30 dni.
• Ekspozycja. Produkt wystawiony do internetu ma pierwszeństwo przed narzędziem wewnętrznym w sieci prywatnej.

Krok 5. Przekazywać znaleziska właścicielowi, według polityki

• Zapisać progi jako politykę. Progi ważności i możliwości wykorzystania należy ustalać dla produktu lub repozytorium w polityce, a nie jako filtr pulpitu ustawiony przez jedną osobę.
• Przypisać właścicieli według repozytorium lub zespołu, aby każde znalezisko miało kogoś, kto decyduje.
• Jawnie decydować o braku poprawki: zaakceptować z datą wygaśnięcia, złagodzić albo zastąpić komponent. Znalezisko bez poprawki nie powinno pozostawać otwarte bez decyzji.

Programiści ignorują znaleziska z czterech powodów: brak właściciela, brak kontekstu, brak terminu albo niewłaściwy kanał. Zespoły, z którymi rozmawiamy, opisują sytuacje, w których dział inżynierii wyłączał skanery, bo ich wyniki były zbyt zaszumione, by je czytać. Należy usunąć każdy z tych powodów: właściciel dla każdego repozytorium, kontekst z kroku 4 dołączony do znaleziska, termin wynikający z polityki i dostarczanie tam, gdzie zespół już pracuje.

Ograniczanie szumu a ukrywanie ryzyka

Mniejszy backlog jest lepszy tylko wtedy, gdy zmalał z właściwych powodów.

• Wyciszenie bez powodu i daty wygaśnięcia to ukryty dług. Wraca przy audycie lub incydencie, gdy nie ma już nikogo, kto pamięta, dlaczego je wprowadzono.
• Progi ważności ukrywają błędne znaleziska, zamiast je usuwać. Reguła „nic poniżej CVSS 7” sprawia, że wynik fałszywie dodatni z CVSS 6 znika, a ten z CVSS 9 zostaje.
• Każda decyzja o nienaprawianiu wymaga zapisu. Oczekują go klienci, a także regulacje, takie jak unijny Cyber Resilience Act, który wymaga od producentów obsługi podatności przez cały okres wsparcia produktu.

Jak to mierzyć

• Znaleziska na dostarczone wydanie, a nie na skan.
• Odsetek znalezisk, wobec których podjęto działanie: naprawionych, złagodzonych lub rozstrzygniętych.
• Zamknięte jako niedotyczące z zapisem VEX, w porównaniu z wyciszonymi bez niego.
• Czas od buildu do właściciela: jak długo nowe znalezisko czeka, aż ktoś je przejmie.
• Odsetek duplikatów między narzędziami.

Próbka 50 znalezisk, którą można przejrzeć w jedno popołudnie. Proszę wybrać losowo 50 otwartych znalezisk. Dla każdego należy zapisać, czy komponent jest dostarczany w wydaniu, czy inne narzędzie lub repozytorium zgłasza to samo znalezisko, czy dopasowanie jest poprawne, czy podatność da się wykorzystać w Państwa produkcie, czy istnieje poprawka i kto jest właścicielem. Wyniki pokażą, od którego kroku zacząć. Tę samą próbkę warto powtórzyć kwartał później. Nie przytaczamy branżowych benchmarków dla tych liczb, ponieważ żadne źródło pierwotne ich nie potwierdza.

Gdzie pasuje CRACI

CRACI działa w krokach 1 i 2, w bramce buildu z kroku 3 i w części kroków 4 i 5, dla oprogramowania budowanego w GitHub Actions.

• Inwentarz. CRACI zastępuje Państwa runnery hostowane przez GitHub i rejestruje pakiety, które każde zadanie faktycznie pobrało, z PURL dla każdego komponentu i stanem kompletności dla każdego SBOM. Każdy komponent w SBOM z CRACI był w buildzie. Ta dokładność dotyczy komponentów SBOM; dopasowane CVE wciąż może nie dotyczyć Państwa produktu. Do tego służy VEX, a CRACI obsługuje VEX.
• Jedno znalezisko, wiele buildów. Znaleziska są agregowane z wielu buildów i repozytoriów, a monitorowane SBOM-y są stale ponownie oceniane w miarę publikowania nowych podatności.
• Bramki. Bramki polityk mogą zatrzymać build w czasie rzeczywistym na podstawie znalezisk, 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ę.
• Powiadomienia. CRACI powiadamia właściwe osoby o podatności i jej ważności.

CRACI nie oferuje analizy osiągalności, SAST ani pulpitów MTTR. Pełny zakres możliwości opisuje śledzenie podatności; można też zobaczyć, co faktycznie zawierają Państwa buildy.

Kiedy CRACI nie jest odpowiedzią

• Większość Państwa szumu to znaleziska SAST we własnym kodzie. To problem strojenia SAST.
• Państwa backlog to głównie prawdziwe, możliwe do wykorzystania znaleziska w dostarczanym kodzie. To problem zdolności do naprawiania, a nie problem szumu.
• Potrzebują Państwo kontekstu w czasie działania z obciążeń produkcyjnych. Na to odpowiada CNAPP lub narzędzie runtime security.

Szerszy plan opisuje strona co automatyzować, gdy liczba CVE wciąż rośnie, a aktualne dane można znaleźć w trendach publikacji CVE.

Ograniczanie szumu podatności: najczęściej zadawane pytania

Jak zmniejszyć liczbę alertów o podatnościach?

Ograniczać je u źródła, po kolei: dopasować inwentarz do tego, co jest dostarczane, deduplikować znaleziska według adresu URL pakietu, wersji i CVE, dostarczać mniej zależności, dodać kontekst wykorzystania, taki jak VEX, KEV i EPSS, a to, co zostanie, przekazać właścicielowi zgodnie ze spisaną polityką. Dopiero potem priorytetyzować.

Dlaczego nasz skaner zgłasza tysiące podatności i które z nich mają znaczenie?

Zwykle dlatego, że zgłasza komponenty, których Państwo nie dostarczają, zgłasza to samo CVE raz na każde narzędzie i repozytorium, a część dopasowań zgaduje błędnie. Znaczenie mają te, które dotyczą komponentów faktycznie zawartych w wydaniu, dają się wykorzystać w Państwa produkcie i są znane jako wykorzystywane lub prawdopodobnie zostaną wykorzystane.

Jak deduplikować znaleziska z kilku narzędzi bezpieczeństwa?

Każde znalezisko należy kluczować adresem URL pakietu, wersją i CVE oraz liczyć jedno znalezisko na dostarczany artefakt. Agregacja z wielu repozytoriów sprawia, że współdzielona biblioteka to jedna decyzja. Następnie każdy rodzaj sygnału należy przypisać jednemu narzędziu, aby dwa skanery przestały zgłaszać to samo.

Czy wyciszać podatności, dla których nie ma poprawki?

Nie po cichu. Należy podjąć jawną decyzję: zaakceptować ryzyko z pisemnym uzasadnieniem i datą wygaśnięcia, złagodzić je albo zastąpić komponent. Potem wrócić do sprawy, gdy pojawi się poprawka. Wyciszenie bez powodu i daty wygaśnięcia to ukryty dług.

Czy podatność, której nikt nie naprawił od roku, to nadal szum?

Niekoniecznie. Wiek nic nie mówi o ryzyku. Jeśli jest dostarczana i da się ją wykorzystać, wymaga decyzji i właściciela. Jeśli nie dotyczy Państwa produktu, należy to zapisać jako oświadczenie VEX, aby przestała wracać. Tak czy inaczej nie powinna pozostawać otwarta bez decyzji.

Jak sprawić, by programiści przestali ignorować znaleziska bezpieczeństwa?

Każde znalezisko powinno mieć właściciela, kontekst potrzebny do działania i termin wynikający ze spisanej polityki, a trafiać tam, gdzie zespół już pracuje. Najpierw należy usunąć szum: programiści przestają czytać kanał, w którym większość znalezisk nie ma znaczenia.

Jaka liczba otwartych podatności jest dobra?

Nie ma wiarygodnego benchmarku, a surowa liczba to zła miara. Warto śledzić znaleziska na dostarczone wydanie, odsetek znalezisk, wobec których podjęto działanie, odsetek zamkniętych z zapisanym powodem oraz to, jak długo znane wykorzystywane podatności pozostają otwarte w dostarczanym oprogramowaniu.