Vaše platforma SOC 2 ukazuje, že kontrola běží. CRACI zaznamenává, co build obsahoval.

Nastavení, o kterém je tato stránka

Mnoho SaaS týmů dospěje ke stejnému uspořádání. Generátor jako Syft nebo Trivy vytváří SBOM v CI, skener zranitelností hlídá repozitáře a platforma pro automatizaci compliance se připojuje ke GitHubu a cloudovému účtu, aby sbírala důkazy pro SOC 2. Funguje to. Auditoři to přijímají a nikdo netráví týden před auditem pořizováním snímků obrazovky.

Tyto platformy v tom jsou dobré. Vanta uvádí, že „connects read-only to your cloud, identity, code, and device tools“ a „automatically pulls evidence, maps it to controls“, s více než 1 200 automatizovanými testy, které běží každou hodinu. Drata se připojuje ke „cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more“, aby sbírala důkazy a mapovala je na kontroly SOC 2. Pokud je cílem čistá zpráva SOC 2, je to pro tu práci správný nástroj.

Tato stránka se zabývá užší otázkou: co tyto důkazy vypovídají o samotné SBOM.

Na co se kontrola SOC 2 skutečně ptá

Prověrky SOC 2 se vykazují vůči AICPA Trust Services Criteria. Kritériem nejbližším SBOM je 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

Kritérium popisuje výsledek. Metodu a hloubku inventáře komponent, který za ní stojí, nechává na vás a vašem auditorovi. Automatizovaný test se proto obvykle ptá, zda je kontrola zavedená a funguje: je skener připojený, proběhl, byly nálezy vyřešeny v souladu s vaší politikou? To je férová otázka a právě to je ono zaškrtávátko.

Kontrola se ale neptá, zda SBOM, ze které sken vychází, uváděla všechno, co vydání obsahovalo. Zranitelnost v komponentě, kterou SBOM nikdy neuvedla, nelze s ničím spárovat, takže sken dopadne čistě a kontrola dál svítí zeleně.

Kde se zelená kontrola a úplná SBOM rozcházejí

Generátory SBOM pracují se soubory, které mají před sebou, a jejich vlastní dokumentace ukazuje, kde to nechává mezery:

• U expressjs/express 5.2.1, který necommituje žádný lockfile, nemá generátor, jenž vyhodnocuje závislosti z lockfilů, co vyhodnotit. Přesto může vrátit dokument se vším ostatním, co rozpozná, například s GitHub Actions a soubory workflow, a bez jediné z npm závislostí deklarovaných v package.json.
• Různé generátory vracejí ze stejného checkoutu různé seznamy, protože každý si sám určuje, co se počítá za komponentu. Export grafu závislostí z GitHubu je ještě dál: vychází z toho, co GitHub o repozitáři ví, a čte výchozí větev místo připnutého commitu.
• Pole dodavatele podle NTIA vychází ve většině dokumentů prázdné, protože většina generátorů pro něj nemá zdroj.

Žádný z těchto nástrojů není rozbitý. Každý přečetl soubory, na které byl nasměrován, a každý včas vytvořil platný dokument ve standardním formátu. Z pohledu testu compliance kontrola fungovala. SBOM přesto software nepopisovala.

Co CRACI přidává k důkazům

CRACI nahrazuje runner GitHub Actions. Změníte runs-on na craci a běhy se dál zobrazují v rozhraní GitHubu. SBOM se generuje přímo v tomto runneru během buildu: proxy, která rozumí balíčkům, sleduje provoz ke zdrojům balíčků, takže záznam odráží to, co job skutečně stáhl, ne to, co by podle nějakého souboru stáhnout měl.

Úplnost je uvedena, ne předpokládána

Každý job a každá cache dostane jeden z pěti stavů úplnosti: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded. Důkazy o závislostech putují spolu s cache, takže balíčky obnovené z teplé cache se přenášejí dál, místo aby potichu vypadly. Když je záznam neúplný, říká to.

To odpovídá směru, kterým se ubírají standardy. Minimální prvky SBOM pro rok 2026 od CISA a jejích partnerů žádají, aby autoři SBOM „explicitly state whether the information is unknown to the SBOM author“, místo aby pole potichu nechávali prázdná.

Důkazy ve formátech, které auditoři přijímají

SBOM se exportují jako CycloneDX nebo SPDX, včetně zranitelností nalezených v jejich komponentách. Veřejné REST API vrací SBOM, síťový záznam jobu a data o provenance, takže stejné záznamy mohou putovat tam, kde máte uložené důkazy pro audit.

Inventář toho, co je kde nasazeno

Pohled inventáře v CRACI přesně ukazuje, které verze softwaru jsou nasazeny ve kterých produktech, a to globálně. Když se objeví nová zranitelnost, vidíte, které produkty používají dotčenou verzi, místo abyste to skládali z poznámek k vydání a tabulek.

Platformu SOC 2 si ponechte

CRACI není platformou pro automatizaci compliance a žádnou nenahrazuje. Nespravuje politiky, revize přístupů, kontroly zařízení ani dotazníky pro dodavatele. Obě řešení odpovídají na různé otázky. Vaše platforma pro compliance ukazuje, že kontrola existuje a běží. CRACI zaznamenává, co build stáhl a zda je tento záznam úplný.

Rozdíl roste, jakmile prodáváte software v EU. Cyber Resilience Act vyžaduje, aby výrobci identifikovali a dokumentovali komponenty „na základě vypracování softwarového kusovníku (SBOM) v běžně používaném strojově čitelném formátu, který obsahuje přinejmenším nejdůležitější závislosti produktu“ (příloha I, část II). Příloha VII řadí SBOM do technické dokumentace a umožňuje orgánu dozoru nad trhem si ji vyžádat. Zpráva SOC 2 osvědčuje, jak vaše organizace provozuje své kontroly. SBOM pro CRA popisuje konkrétní produkt. Náš přehled CRA popisuje harmonogram a stránka o souladu s CRA to, co CRACI automatizuje. CRACI automatizuje významnou část přehledu o dodavatelském řetězci a důkazů, které širší proces souladu s CRA potřebuje; sám o sobě vám soulad nezajistí.

Stejné důkazy slouží i pro ISO 27001 a NIS2. Přehled kontrolu po kontrole najdete v článku SBOM jako důkaz pro ISO 27001, SOC 2 a NIS2.

Jak to vyzkoušet bez zásahu do auditu

1. Vyberte jeden repozitář, jehož SBOM už vstupuje do vašich důkazů pro SOC 2.
2. Nasměrujte jeho release workflow na CRACI změnou runs-on na craci.
3. Porovnejte zaznamenanou SBOM s tou, kterou generujete dnes, komponentu po komponentě, a zkontrolujte stav úplnosti jobu.
4. Rozhodněte, zda rozdíl patří do vašich důkazů.

Přečtěte si více o generování SBOM z doby buildu a důkazech pro CRA, nebo se podívejte, jak dokumentujeme vlastní kontroly, na naší stránce o zabezpečení.