SBOM-Automatisierung

Warum manuelle SBOMs an Grenzen stoßen

• Sie veralten mit dem nächsten Build. Abhängigkeiten ändern sich mit jedem Release, eine Tabelle aber nur, wenn jemand daran denkt, sie zu aktualisieren.
• Sie enden dort, wo der Blick endet. Direkte Abhängigkeiten lassen sich leicht auflisten. Die transitiven Abhängigkeiten darunter nicht, und von Hand kann sie niemand nachverfolgen.
• Sie vervielfachen sich. Mehrere Produkte mit jeweils mehreren unterstützten Versionen ergeben Dutzende Dateien, jede mit eigenem Verantwortlichen und eigener Version der Wahrheit.
• Sie beantworten die entscheidende Frage nicht. Taucht eine neue Schwachstelle auf, müssen Sie wissen, welche Releases das Paket enthalten. Einen Ordner voller Tabellen zu durchsuchen dauert lange, und auf das Ergebnis können Sie sich nicht verlassen.
• Sie sind nicht das, was andere verlangen. Kunden und Tools erwarten ein maschinenlesbares Format wie CycloneDX oder SPDX. Siehe so beantworten Sie eine SBOM-Anfrage von Kunden.

Was gute SBOM-Automatisierung leistet

1. Sie erzeugt für jeden Build eine SBOM, ohne dass jemand etwas ausführen oder daran denken muss.
2. Sie deckt den gesamten Baum ab, transitive Abhängigkeiten eingeschlossen, auf jeder Ebene.
3. Sie verknüpft jede SBOM mit genau einem Build, sodass Sie wissen, welche Datei welches Release beschreibt.
4. Sie benennt, was sie nicht sehen konnte, statt eine Teilliste als vollständig auszugeben.
5. Sie exportiert ein Standardformat, sodass die SBOM auch mit dem nächsten Tool und beim nächsten Kunden funktioniert.
6. Sie überwacht weiter, was ausgeliefert wurde, denn ein Release, das am Montag sauber war, kann am Dienstag betroffen sein.

Drei Wege, SBOMs zu führen, im Vergleich

Frage	Tabelle	Scanner im CI	Während des Builds aufgezeichnet
Wann wird sie aktualisiert?	Wenn jemand daran denkt	Wenn der Scan-Schritt läuft	Bei jedem Build
Woher stammen die Daten?	Von Menschen	Aus Lockfiles oder dem fertigen Build-Ergebnis	Aus dem, was der Build tatsächlich geladen hat
Transitive Abhängigkeiten?	Selten	Die, die er ableiten kann	Auf jeder Ebene
Versteckte Abhängigkeiten, etwa Downloads von Install-Skripten?	Nein	Werden übersehen	Werden aufgezeichnet
Pakete aus einem CI-Cache?	Nein	Hängt vom Tool ab	Aufgezeichnet und als gecacht markiert
Schwachstellenüberwachung?	Manuell	Meist ein separates Tool	Bei CRACI integriert

Die Automatisierung per Scanner ist gegenüber einer Tabelle ein echter Fortschritt, und doch rät sie weiterhin, was eingeflossen ist. Die Begründung lesen Sie unter warum der Build die verlässliche Quelle ist.

Was aus Ihren Tabellen wird

Die Komponentendaten wandern aus der Tabelle: Versionen und Pakete kommen aus dem Build, sodass niemand sie eintippen muss. Es bleibt das Wissen, das nur Ihr Team hat, etwa welche Produkte es gibt, wer dafür zuständig ist und welche Versionen noch unterstützt werden. Dafür lohnt sich die Zeit eines Menschen.

Wie CRACI das umsetzt

CRACI ersetzt Ihre GitHub-gehosteten Runner durch schnellere, günstigere und zeichnet die SBOM auf, während jeder Build läuft. Sie setzen runs-on: craci, und Ihre Ausführungen erscheinen weiterhin in GitHub. Standard-Builds erhalten ohne Konfiguration eine vollständige SBOM. Builds mit eigenen Paket-Registries oder ungewöhnlichen Container-Setups brauchen unter Umständen etwas Konfiguration.

• Aufgezeichnet, nicht gescannt. CRACI sieht den Datenverkehr, der in jeden Build hineinkommt, einschließlich der versteckten Abhängigkeiten, die Lockfile-basierte Tools übersehen. Jede Komponente in der SBOM war im Build.
• Ein Vollständigkeitsstatus für jeden Job, sodass Sie wissen, wann ein Build nicht vollständig aufgezeichnet werden konnte und warum.
• Export als CycloneDX und SPDX, einschließlich transitiver Abhängigkeiten und der in den Komponenten gefundenen Schwachstellen.
• Eine Ansicht über alle Produkte. Die Inventaransicht zeigt, welche Softwareversionen auf welchen Produkten laufen, und CRACI bewertet überwachte SBOMs laufend neu.

Für die Einführung in Teams mit unterschiedlichen Pipelines siehe SBOM-Generierung über Engineering-Teams hinweg.

SBOM-Automatisierung: häufig gestellte Fragen

Was ist SBOM-Automatisierung?

Das Erzeugen einer Software Bill of Materials als Teil des Builds, sodass jedes Release eine hat, ohne dass jemand sie von Hand erstellt. Die besseren Lösungen überwachen jede SBOM außerdem auf neue Schwachstellen, nachdem das Release ausgeliefert wurde.

Können wir unsere SBOMs in Excel führen?

Als erstes Inventar kann eine Tabelle funktionieren, aber sie lässt sich nur schwer aktuell halten und erreicht transitive Abhängigkeiten nicht. Außerdem ist sie kein Standard-SBOM-Format. Kunden und Sicherheitstools erwarten in der Regel CycloneDX oder SPDX, und der Cyber Resilience Act verlangt ein gängiges, maschinenlesbares Format.

Braucht SBOM-Automatisierung einen neuen Schritt in jeder Pipeline?

Bei den meisten Generatoren ja: Sie fügen jedem Workflow einen Schritt hinzu und halten ihn aktuell. CRACI zeichnet die SBOM im Runner auf, Ihre Jobs brauchen also keinen zusätzlichen Schritt.

Welche Ökosysteme zeichnet CRACI auf?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian- und Ubuntu-Pakete (apt), Alpine-Pakete (apk) und Git-Quellen, dazu Yocto- und OpenEmbedded-Downloads. Maven und Java sind auf der Roadmap.

Welche CI-Systeme und Plattformen unterstützt CRACI?

Heute GitHub Actions, weitere CI-Systeme sind auf der Roadmap. Die Runner laufen heute auf Linux x86-64 und ARM64, Windows und macOS sind auf der Roadmap.

Was ist mit Komponenten, die wir von Herstellern kaufen?

Sie können SBOMs von Herstellern zu CRACI hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden.

Was kostet das?

CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Kosten pro SBOM.