Platforma SOC 2 pokazuje, że kontrola działa. CRACI rejestruje, co zawierał build.

Układ, którego dotyczy ta strona

Wiele zespołów SaaS dochodzi do tego samego układu. Generator, taki jak Syft lub Trivy, tworzy SBOM w CI, skaner podatności obserwuje repozytoria, a platforma automatyzacji zgodności łączy się z GitHub i kontem w chmurze, aby zbierać dowody na potrzeby SOC 2. To działa. Audytorzy to akceptują, a nikt nie spędza tygodnia przed audytem na robieniu zrzutów ekranu.

Te platformy są w tym dobre. Vanta podaje, że „connects read-only to your cloud, identity, code, and device tools” i „automatically pulls evidence, maps it to controls”, z ponad 1200 automatycznych testów uruchamianych co godzinę. Drata łączy się z „cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more”, aby zbierać dowody i mapować je na mechanizmy kontrolne SOC 2. Jeśli celem jest czysty raport SOC 2, to właściwe narzędzie.

Ta strona dotyczy węższego pytania: co te dowody mówią o samym SBOM.

O co naprawdę pyta kontrola SOC 2

Badania SOC 2 odnoszą się do AICPA Trust Services Criteria. Kryterium najbliższe SBOM to CC7.1:

"To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities."

AICPA, 2017 Trust Services Criteria, CC7.1

Kryterium opisuje rezultat. Metodę i szczegółowość stojącego za nią inwentarza komponentów pozostawia Państwu i audytorowi. Test automatyczny zwykle pyta więc, czy mechanizm kontrolny istnieje i działa: czy skaner jest podłączony, czy się uruchomił, czy znaleziska obsłużono zgodnie z polityką. To uczciwe pytanie i to właśnie jest checkbox.

Kontrola nie pyta natomiast, czy SBOM stojący za skanem wymienia wszystko, co zawierało wydanie. Podatności w komponencie, którego SBOM nigdy nie wymienił, nie można do niczego dopasować, więc skan wraca czysty, a kontrola nadal świeci się na zielono.

Gdzie zielona kontrola rozmija się z kompletnym SBOM

Generatory SBOM pracują na plikach, które mają przed sobą, a ich własna dokumentacja pokazuje, gdzie powstają luki:

• W expressjs/express 5.2.1, który nie ma lockfile w repozytorium, generator rozwiązujący zależności z plików lock nie ma czego rozwiązywać. Może nadal zwrócić dokument z tym, co jeszcze rozpozna, na przykład GitHub Actions i pliki workflow, ale bez żadnej zależności npm zadeklarowanej w package.json.
• Różne generatory zwracają różne listy z tego samego checkoutu, ponieważ każdy sam decyduje, co liczy się jako komponent. Eksport grafu zależności GitHub jest jeszcze dalej: powstaje z tego, co GitHub wie o repozytorium, i odczytuje domyślną gałąź, a nie przypięty commit.
• Pole dostawcy NTIA w większości dokumentów jest puste, ponieważ większość generatorów nie ma dla niego źródła.

Żadne z tych narzędzi nie jest zepsute. Każde odczytało wskazane pliki i każde wytworzyło poprawny dokument w standardowym formacie, zgodnie z harmonogramem. Z punktu widzenia testu zgodności mechanizm kontrolny zadziałał. SBOM nadal jednak nie opisywał oprogramowania.

Co CRACI wnosi do dowodów

CRACI zastępuje runner GitHub Actions. Zmieniają Państwo runs-on na craci, a uruchomienia nadal są widoczne w interfejsie GitHub. SBOM powstaje wewnątrz tego runnera podczas buildu: proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów, więc zapis odzwierciedla to, co zadanie pobrało, a nie to, co według pliku powinno pobrać.

Kompletność jest określona, a nie zakładana

Każde zadanie i każdy cache otrzymuje jeden z pięciu stanów kompletności: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Dowody zależności przemieszczają się razem z cache, więc pakiety przywrócone z rozgrzanego cache są przenoszone dalej, zamiast po cichu znikać. Gdy zapis jest niekompletny, mówi o tym wprost.

To zgodne z kierunkiem rozwoju standardów. Minimalne elementy SBOM 2026 od CISA i jej partnerów wymagają, aby autorzy SBOM „explicitly state whether the information is unknown to the SBOM author”, zamiast po cichu zostawiać puste pola.

Dowody w formatach akceptowanych przez audytorów

SBOM-y eksportuje się w formacie CycloneDX lub SPDX, łącznie z podatnościami znalezionymi w ich komponentach. Publiczne REST API zwraca SBOM, ślad sieciowy zadania i dane o pochodzeniu, więc te same zapisy mogą trafić tam, gdzie przechowują Państwo dowody audytowe.

Inwentarz tego, co gdzie jest wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawi się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast odtwarzać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Platforma SOC 2 zostaje

CRACI nie jest platformą automatyzacji zgodności i jej nie zastępuje. Nie zarządza politykami, przeglądami dostępu, kontrolami urządzeń ani kwestionariuszami dostawców. Oba rozwiązania odpowiadają na różne pytania. Platforma zgodności pokazuje, że mechanizm kontrolny istnieje i działa. CRACI rejestruje, co pobrał build i czy ten zapis jest kompletny.

Różnica rośnie, gdy sprzedają Państwo oprogramowanie w UE. Cyber Resilience Act wymaga od producentów zidentyfikowania i udokumentowania komponentów, w tym przez sporządzenie zestawienia komponentów oprogramowania w powszechnie stosowanym formacie czytelnym maszynowo, obejmującego co najmniej zależności najwyższego poziomu produktów (załącznik I, część II). Załącznik VII umieszcza SBOM w dokumentacji technicznej i pozwala organowi nadzoru rynku go zażądać. Raport SOC 2 poświadcza, jak Państwa organizacja stosuje mechanizmy kontrolne. SBOM dla CRA opisuje konkretny produkt. Nasz przegląd CRA omawia harmonogram, a strona o zgodności z CRA to, co automatyzuje CRACI. CRACI automatyzuje znaczną część widoczności łańcucha dostaw i dowodów potrzebnych w szerszym procesie zgodności z CRA; sam w sobie nie zapewnia zgodności.

Jak to wypróbować bez ingerencji w audyt

1. Proszę wybrać jedno repozytorium, którego SBOM zasila już Państwa dowody SOC 2.
2. Proszę skierować jego workflow wydania na CRACI, zmieniając runs-on na craci.
3. Proszę porównać zarejestrowany SBOM z generowanym dziś, komponent po komponencie, i sprawdzić stan kompletności zadania.
4. Proszę zdecydować, czy ta różnica powinna znaleźć się w Państwa dowodach.

Więcej o generowaniu SBOM w czasie buildu i dowodach dla CRA, a o tym, jak dokumentujemy własne mechanizmy kontrolne, piszemy na stronie o bezpieczeństwie.