CRACI dla zespołów PSIRT i liderów bezpieczeństwa produktu

Problem PSIRT managera

Szef bezpieczeństwa produktu jest rozliczany z odpowiedzi, których PSIRT nie udzieli samodzielnie. Gdy CVE pojawia się w powszechnie używanej bibliotece, klienci, kadra zarządzająca i coraz częściej regulatorzy w ciągu kilku godzin zadają te same pytania: czy nas to dotyczy, w których produktach i wersjach, od kiedy i kiedy zostanie to naprawione?

Odpowiedzi zależą od inwentaryzacji, a ta zwykle pochodzi ze skanerów odczytujących lockfile lub manifesty po fakcie. Skanery te wymieniają zależności deweloperskie, które nigdy nie trafiają do klientów, i pomijają pakiety pobrane przez build w inny sposób. PSIRT prosi więc zespoły inżynierskie o ręczne sprawdzenie, a odpowiedź przychodzi po kilku dniach i z zastrzeżeniami.

FIRST PSIRT Services Framework uznaje inwentaryzację komponentów produktu za niezbędną do szybkiego wskazania produktów dotkniętych odziedziczonymi podatnościami. Właśnie od tej inwentaryzacji zaczyna CRACI. Pełny obraz tej roli znajdą Państwo na stronie czym jest PSIRT.

Co CRACI daje zespołowi PSIRT

Inwentaryzacja zarejestrowana z buildu

CRACI uruchamia Państwa buildy GitHub Actions na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache CI i zależnościami, których nie wymienia żaden lockfile. To rejestrator, a nie skaner. Każdy SBOM ma określony stan kompletności, więc częściowy zapis jest oznaczony jako częściowy, a SBOM-y eksportuje się jako CycloneDX lub SPDX.

Ciągłe monitorowanie tego, co dostarczono

Monitorowane SBOM-y są stale oceniane ponownie w miarę publikowania nowych podatności, a ustalenia są agregowane w obrębie buildów i repozytoriów. CVE opublikowane w przyszłym miesiącu jest dopasowywane do wydań już dostarczonych, a nie tylko do następnego buildu. Znane złośliwe wydania z opublikowanym CVE są oznaczane jak każda inna podatność.

Produkty, wersje i okresy objęte problemem

Historia buildów pokazuje każdy poprzedni build wraz z jego SBOM oraz to, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, więc w ramach okresu przechowywania wiadomo, w jakim czasie problem Państwa dotyczył. Widok inwentarza pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach. Razem zamieniają pytanie „czy nas to dotyczy?” w zwykłe wyszukiwanie.

Komponenty kupowane

Produkty rzadko składają się wyłącznie z własnego kodu. Można dodawać SBOM-y dostawców, dzięki czemu komponenty zewnętrzne są monitorowane razem z Państwa buildami.

Triaż, kierowanie i VEX

Zespoły bezpieczeństwa przeprowadzają triaż wykrytych podatności i kierują je do zespołów odpowiedzialnych za poprawkę, co odpowiada rozproszonemu modelowi PSIRT, w którym naprawą zajmują się zespoły produktowe. CRACI obsługuje VEX. Na stronie VEX wyjaśniamy, jak oświadczenia not affected oszczędzają pracę zespołowi PSIRT i jego klientom.

Niedopuszczanie naprawionego CVE do późniejszych buildów

Bramki polityk mogą blokować build na podstawie ustaleń, w tym buildy zawierające konkretne CVE. Po zamknięciu sprawy PSIRT bramka dla tego CVE nie pozwala podatnej wersji po cichu wrócić w późniejszym wydaniu.

Dowody dla audytów i klientów

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu dla każdego buildu, więc zapis stojący za biuletynem lub odpowiedzią dla audytora jest dostępny poza interfejsem. Tam, gdzie obowiązuje unijny Cyber Resilience Act, CRACI składa również wymagane zgłoszenia do organów w imieniu producenta; obowiązek pozostaje po stronie producenta. Zob. czym jest CRA.

Miejsce CRACI w procesie PSIRT

Etap PSIRT	Wkład CRACI
Przygotowanie	SBOM dla każdego buildu, rejestrowany w trakcie jego działania, z określonym stanem kompletności
Wykrywanie	Ciągła ponowna ocena monitorowanych SBOM-ów, także SBOM-ów dostawców
Weryfikacja	Które buildy, wersje i produkty zawierają komponent i od kiedy
Naprawa	Triaż do odpowiedzialnego zespołu; bramki polityk, które nie dopuszczają CVE do późniejszych buildów
Wydanie i ujawnienie	Obsługa VEX; eksport SBOM; dostęp przez API do zapisu buildu

Etapy odpowiadają cyklowi życia zarządzania podatnościami.

Czego CRACI nie robi

• Analiza osiągalności. CRACI pokazuje, że podatny pakiet był w buildzie, a nie to, czy Państwa kod wywołuje podatną funkcję.
• Skanowanie kodu źródłowego. SAST i skanowanie sekretów są poza zakresem; wiele dobrych narzędzi robi to obok CRACI.
• Systemy CI inne niż GitHub Actions. Dziś GitHub Actions; inne systemy CI są w planach rozwoju.
• Zgodność za Państwa. CRACI dostarcza dowody; spełnienie NIS2, CRA lub innego frameworku pozostaje procesem Państwa organizacji.

CRACI dla zespołów PSIRT: najczęściej zadawane pytania

Czy CRACI to narzędzie PSIRT?

CRACI obejmuje tę część pracy PSIRT, która zależy od wiedzy o tym, co Państwo dostarczają: SBOM-y z buildu, ich ciągłe monitorowanie, informację, które buildy i produkty zawierają podatny komponent, oraz triaż do odpowiedzialnego zespołu. Państwa kanał ujawniania i proces publikowania biuletynów opierają się na tym zapisie.

Skąd CRACI wie, co jest w produkcie?

Buildy działają na runnerach GitHub Actions CRACI, a CRACI rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache CI i zależnościami, których nie wymienia żaden lockfile. To rejestrator, a nie skaner. Każdy SBOM ma określony stan kompletności, więc wiadomo, kiedy zapis jest częściowy.

Czy CRACI potrafi wskazać, których wcześniejszych wydań dotyczyło dane CVE?

Tak, w ramach okresu przechowywania. Historia buildów pokazuje każdy poprzedni build i jego SBOM oraz to, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, więc wiadomo, w jakim czasie problem Państwa dotyczył. Widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach.

Czy CRACI obejmuje komponenty kupowane od dostawców?

Można dodawać SBOM-y dostawców, dzięki czemu kupowane komponenty są monitorowane razem z Państwa buildami.

Czy CRACI obsługuje VEX?

Tak. CRACI obsługuje VEX do rejestrowania, jak znana podatność wpływa na Państwa produkt. Statusy i formaty opisuje strona VEX, a to, jak przenoszą je biuletyny, strona CSAF.

Jakie systemy CI obsługuje CRACI?

Dziś GitHub Actions. Inne systemy CI są w planach rozwoju.