Ihre SOC-2-Plattform zeigt, dass die Kontrolle läuft. CRACI zeichnet auf, was der Build enthielt.

Um dieses Setup geht es hier

Viele SaaS-Teams landen beim selben Aufbau. Ein Generator wie Syft oder Trivy erzeugt im CI eine SBOM, ein Schwachstellen-Scanner beobachtet die Repositories, und eine Plattform für Compliance-Automatisierung bindet GitHub und das Cloud-Konto an, um Nachweise für SOC 2 zu sammeln. Das funktioniert. Auditoren akzeptieren es, und niemand verbringt die Woche vor einem Audit mit Screenshots.

Diese Plattformen können das gut. Vanta sagt, das Produkt „connects read-only to your cloud, identity, code, and device tools“ und „automatically pulls evidence, maps it to controls“, mit mehr als 1.200 automatisierten Tests, die stündlich laufen. Drata bindet „cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more“ an, um Nachweise zu sammeln und SOC-2-Kontrollen zuzuordnen. Wenn das Ziel ein sauberer SOC-2-Bericht ist, ist das das richtige Werkzeug.

Diese Seite behandelt eine engere Frage: Was sagen diese Nachweise über die SBOM selbst aus?

Was eine SOC-2-Prüfung tatsächlich fragt

SOC-2-Prüfungen berichten anhand der AICPA Trust Services Criteria. Das Kriterium, das SBOMs am nächsten kommt, ist 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

Das Kriterium beschreibt ein Ergebnis. Die Methode und die Tiefe des dahinterliegenden Komponenteninventars überlässt es Ihnen und Ihrem Auditor. Ein automatisierter Test fragt daher meist, ob die Kontrolle vorhanden ist und läuft: Ist ein Scanner angebunden, ist er gelaufen, wurden Befunde gemäß Ihrer Richtlinie behandelt? Das ist eine berechtigte Frage, und sie ist das Häkchen.

Nicht gefragt wird, ob die SBOM hinter dem Scan alles aufgeführt hat, was das Release enthielt. Eine Schwachstelle in einer Komponente, die die SBOM nie aufgeführt hat, lässt sich mit nichts abgleichen. Der Scan bleibt also sauber, und die Kontrolle zeigt weiterhin Grün.

Wo sich ein grünes Häkchen und eine vollständige SBOM trennen

SBOM-Generatoren arbeiten mit den Dateien, die ihnen vorliegen, und ihre eigene Dokumentation zeigt, wo dadurch Lücken entstehen:

• Bei expressjs/express 5.2.1, das kein Lockfile committet, hat ein Generator, der Abhängigkeiten aus Lockfiles auflöst, nichts aufzulösen. Er kann trotzdem ein Dokument zurückgeben, das aufführt, was er sonst noch erkennt, etwa GitHub Actions und Workflow-Dateien, und keine der in package.json deklarierten npm-Abhängigkeiten.
• Verschiedene Generatoren liefern aus demselben Checkout verschiedene Listen, weil jeder selbst entscheidet, was als Komponente zählt. Der Export des Abhängigkeitsgraphen von GitHub liegt noch weiter daneben: Er basiert auf dem, was GitHub über das Repository weiß, und liest den Default-Branch statt des gepinnten Commits.
• Das NTIA-Lieferantenfeld bleibt in den meisten Dokumenten leer, weil die meisten Generatoren keine Quelle dafür haben.

Keines dieser Tools ist defekt. Jedes hat die Dateien gelesen, auf die es angesetzt wurde, und jedes hat termingerecht ein gültiges Dokument in einem Standardformat erzeugt. Für einen Compliance-Test hat die Kontrolle funktioniert. Die SBOM hat die Software trotzdem nicht beschrieben.

Was CRACI zu den Nachweisen beiträgt

CRACI ersetzt den GitHub-Actions-Runner. Sie ändern runs-on auf craci, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Die SBOM entsteht in diesem Runner, während der Build läuft: Ein paketbewusster Proxy beobachtet den Datenverkehr zu Paketquellen, die Aufzeichnung spiegelt also wider, was der Job geladen hat, nicht, was er laut einer Datei laden sollte.

Vollständigkeit wird angegeben, nicht angenommen

Jeder Job und jeder Cache erhält einen von fünf Vollständigkeitsstatus: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Die Abhängigkeitsnachweise reisen mit Caches, sodass aus einem Warm Cache wiederhergestellte Pakete fortgeschrieben werden, statt stillschweigend herauszufallen. Ist eine Aufzeichnung unvollständig, sagt sie das.

Das entspricht der Richtung der Standards. Die SBOM Minimum Elements 2026 von CISA und ihren Partnern fordern SBOM-Autoren auf, „explicitly state whether the information is unknown to the SBOM author“, statt Felder stillschweigend leer zu lassen.

Nachweise in Formaten, die Auditoren akzeptieren

SBOMs lassen sich als CycloneDX oder SPDX exportieren, einschließlich der in ihren Komponenten gefundenen Schwachstellen. Die öffentliche REST-API liefert die SBOM, den Netzwerk-Trace des Jobs und Provenienzdaten, dieselben Aufzeichnungen können also dorthin gehen, wo Ihre Audit-Nachweise liegen.

Ein Inventar dessen, was wo im Einsatz ist

Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. Wenn eine neue Schwachstelle bekannt wird, sehen Sie, welche Produkte die betroffene Version ausführen, statt es aus Release Notes und Tabellen zusammenzusuchen.

Behalten Sie die SOC-2-Plattform

CRACI ist keine Plattform für Compliance-Automatisierung und ersetzt keine. Es verwaltet keine Richtlinien, Zugriffsprüfungen, Gerätekontrollen oder Anbieterfragebögen. Beide beantworten unterschiedliche Fragen. Ihre Compliance-Plattform zeigt, dass eine Kontrolle existiert und läuft. CRACI zeichnet auf, was der Build geladen hat und ob diese Aufzeichnung vollständig ist.

Der Unterschied wächst, sobald Sie Software in die EU verkaufen. Der Cyber Resilience Act verlangt von Herstellern, Komponenten zu ermitteln und zu dokumentieren, „durch Erstellung einer Software-Stückliste in einem gängigen und maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten der Produkte erfasst“ (Anhang I Teil II). Anhang VII ordnet die SBOM der technischen Dokumentation zu und erlaubt einer Marktüberwachungsbehörde, sie anzufordern. Ein SOC-2-Bericht bescheinigt, wie Ihre Organisation ihre Kontrollen betreibt. Eine CRA-SBOM beschreibt ein bestimmtes Produkt. Unser Überblick über den CRA behandelt den Zeitplan, und die Seite zur CRA-Compliance zeigt, was CRACI automatisiert. CRACI automatisiert einen erheblichen Teil der Lieferketten-Transparenz und der Nachweise, die ein umfassenderer CRA-Compliance-Prozess braucht; allein macht es Sie nicht konform.

So probieren Sie es aus, ohne Ihr Audit zu berühren

1. Wählen Sie ein Repository, dessen SBOM bereits in Ihre SOC-2-Nachweise einfließt.
2. Richten Sie seinen Release-Workflow auf CRACI aus, indem Sie runs-on auf craci ändern.
3. Vergleichen Sie die aufgezeichnete SBOM Komponente für Komponente mit der, die Sie heute erzeugen, und prüfen Sie den Vollständigkeitsstatus des Jobs.
4. Entscheiden Sie, ob der Unterschied in Ihre Nachweise gehört.

Lesen Sie mehr über SBOM-Generierung während des Builds und CRA-Nachweise, oder sehen Sie auf unserer Sicherheitsseite, wie wir unsere eigenen Kontrollen dokumentieren.