SBOM und Software-Supply-Chain-Security: Können Sie Ihren Abhängigkeiten vertrauen?

Eine durchschnittliche Produktionsanwendung enthält deutlich mehr Code von Fremden als von Ihrem eigenen Team. Nach unserer Erfahrung zieht ein Node.js-Service mit 30 direkten Abhängigkeiten regelmäßig über tausend transitive Pakete nach sich, und gelesen hat sie so gut wie niemand. Wenn der nächste Fall vom Kaliber XZ Utils oder event-stream eintritt, gewinnen die Teams, die eine einzige Frage in Minuten beantworten können: Läuft bei uns tatsächlich die betroffene Version?

Der Eisberg unter Ihrer Codebasis

Sie auditieren Ihren Code. Sie reviewen jeden Pull Request. Und dann führt npm install beliebige Postinstall-Skripte eines Pakets aus, das sechs Ebenen tief in Ihrem Abhängigkeitsbaum hängt, gepflegt von jemandem, dessen Konto ein Passwort aus dem Jahr 2014 schützt. Das ist die Asymmetrie im Kern der Supply-Chain-Security: Ihre Kontrollen decken die zehn Prozent der Codebasis ab, die Sie selbst geschrieben haben, und Ihre Angreifer wissen das.

Drei Eigenschaften machen Abhängigkeiten zu einer besonders unangenehmen Angriffsfläche:

• Transitive Unsichtbarkeit. Sie haben sich für express entschieden. Die Dutzenden Pakete, die es mitbringt, haben weder Sie noch sonst jemand in Ihrem Team ausgewählt. Für den Großteil Ihres Baums hat nie ein Mensch eine Vertrauensentscheidung getroffen.
• Codeausführung bei der Installation. Viele Ökosysteme führen beim Installieren Lifecycle-Skripte aus. Wer ein populäres Paket kompromittiert, hat Codeausführung auf jedem Entwickler-Notebook und jedem CI-Runner, der es lädt, noch bevor die Anwendung überhaupt startet.
• Vererbtes Vertrauen. Das kompromittierte Notebook eines Maintainers, eine ausgelaufene E-Mail-Domain oder ein weitergereichtes Hobbyprojekt werden zu Ihrem Sicherheitsvorfall. Genau so funktionierte der Angriff auf event-stream: Ein hilfsbereiter Fremder bat um Publish-Rechte für ein verwaistes Paket und bekam sie.

Aus diesem Problem können Sie sich nicht herausreviewen. Der Baum ist zu groß und ändert sich wöchentlich. Was Sie aufbauen können, sind drei Schichten: Inventar (wissen, was Sie ausliefern), Verifikation (belegen, woher es stammt) und Kontrollen am Eingang (verlangsamen und filtern, was hereinkommt). Die SBOM ist die Inventarschicht, und alles Weitere baut darauf auf.

Was eine SBOM tatsächlich ist

Eine Software Bill of Materials ist ein maschinenlesbares Verzeichnis jeder Komponente eines konkreten Artefakts: Paketname, exakte Version, Lieferant, kryptografische Hashes, Lizenz und die Abhängigkeitsbeziehungen zwischen den Komponenten. Keine Excel-Tabelle. Auch nicht Ihre package.json, die Absichten auflistet statt aufgelöster Versionen. Sondern ein strukturiertes Dokument, das an genau einen Build gebunden ist. Wer mit der DSGVO vertraut ist, kennt das Prinzip: Was das Verzeichnis von Verarbeitungstätigkeiten für Ihre Datenflüsse ist, ist die SBOM für Ihren Code.

Zwei Formate dominieren, und die Wahl ist weniger dramatisch, als das Internet behauptet:

• SPDX (ISO/IEC 5962). Der Altmeister. Stärkste Wurzeln in der Lizenz-Compliance, breite Werkzeuglandschaft, bevorzugt im Umfeld der Linux Foundation.
• CycloneDX (aus dem OWASP-Umfeld, inzwischen als ECMA-424 standardisiert). Für Security-Workflows gebaut, mit erstklassiger Unterstützung für Schwachstellenreferenzen, VEX, Services sowie Hardware- und ML-Komponenten. Wenn Ihr Hauptanwendungsfall die Schwachstellenbehandlung ist, beginnen Sie hier.

Beide serialisieren nach JSON. Beide lassen sich mit akzeptabler Genauigkeit ineinander konvertieren. Wählen Sie eines, erzeugen Sie es konsequent, und lassen Sie keine Formatdebatte die Einführung verzögern.

Ein Wort zum Hype: SBOM ist derzeit das Lieblingswort jeder Compliance-Broschüre, und der Druck kommt zunehmend aus der Regulierung. In den USA hat Executive Order 14028 den Anfang gemacht. Für den DACH-Markt sind andere Texte entscheidend: Der EU Cyber Resilience Act verpflichtet praktisch jeden, der Produkte mit digitalen Elementen in der EU verkauft, zu SBOM-fähigen Prozessen, die NIS2-Umsetzung macht Lieferkettensicherheit für tausende Unternehmen zur gesetzlichen Pflicht, und das BSI hat mit der Technischen Richtlinie TR-03183 bereits formale Anforderungen an SBOMs formuliert, an denen sich Einkaufsabteilungen orientieren. Wer an Konzerne oder die öffentliche Hand verkauft, kennt die Sicherheitsfragebögen des Einkaufs. SBOM-Klauseln stehen dort entweder schon drin oder kommen mit der nächsten Vertragsrunde. Vorbereitung ist billiger als Nachrüstung unter Termindruck.

Zur Build-Zeit erzeugen, nicht auf Zuruf

Der häufigste Fehler in der Praxis: Einmal im Quartal wird per Quellcode-Scan eine SBOM erzeugt und der Haken gesetzt. Eine SBOM ohne Bezug zu einem konkreten Build-Artefakt ist eine Vermutung mit Dateiendung. Die Regeln, auf die es ankommt:

• Eine SBOM pro Artefakt, pro Build. Die SBOM für api:1.4.2 beschreibt exakt dieses Image, inklusive aufgelöstem Lockfile.
• Das Artefakt scannen, nicht nur den Quellcode. Ein Container-Image enthält OS-Pakete (apk, deb, rpm), Sprachabhängigkeiten und einzelne Binaries, die irgendwer hineinkopiert hat. Ein Quellcode-Scan sieht die erste Kategorie gar nicht und die dritte grundsätzlich nicht.
• SBOMs beim Release ablegen und abfragbar halten. Ihr Wert vervielfacht sich, sobald Sie über alle ausgerollten Versionen gleichzeitig suchen können.

Mit Syft ist jeder der beiden Erzeugungswege ein einziger Befehl:

# Quellverzeichnis, wertet Lockfiles aus
syft dir:. -o cyclonedx-json > sbom.cdx.json

# Gebautes Container-Image, inklusive OS-Paketen und Binaries
syft registry:ghcr.io/acme/api:1.4.2 -o cyclonedx-json > sbom-image.cdx.json

Hängen Sie die SBOM anschließend als signierte Attestierung an das Image, damit Abnehmer prüfen können, dass sie aus Ihrer Pipeline stammt und nachträglich nicht verändert wurde:

cosign attest --predicate sbom-image.cdx.json \
  --type cyclonedx ghcr.io/acme/api:1.4.2

Wo die Genauigkeit einer SBOM leise stirbt

Jeder Generator hat blinde Flecken. Kennen Sie Ihre:

• Vendored und kopierter Code. Eine Funktion aus einem Blogartikel oder eine direkt eingebettete Bibliothek hat keine Paketidentität. Sie taucht schlicht nicht auf.
• Statische Binaries. Go-Binaries betten Build-Informationen ein, die Werkzeuge auslesen können. Ein gestripptes C-Binary ist eine Blackbox mit Dateinamen.
• Gebündelter Frontend-Code. Nachdem webpack oder esbuild gelaufen sind, ist das Artefakt ein minifizierter Klumpen. Erzeugen Sie die SBOM vor dem Bundling aus dem Lockfile und liefern Sie beides aus.
• Shaded Jars in der JVM-Welt benennen Pakete intern um und hebeln naives Matching aus.

Eine SBOM, die eine Vollständigkeit behauptet, die sie nicht hat, ist schlimmer als gar keine, weil Menschen ihr vertrauen. Dokumentieren Sie präzise, was Ihr Erzeugungsschritt abdeckt und was er nicht sehen kann.

Vom Inventar zur Antwort

Der Ertrag kommt, wenn eine ernsthafte CVE einschlägt. Ohne SBOMs bauen und scannen Sie jeden Service neu, um herauszufinden, ob Sie betroffen sind. Das kostet Tage, die Sie nicht haben. Mit gespeicherten SBOMs fragen Sie Dokumente ab:

grype sbom:./sbom-image.cdx.json --fail-on high

Noch besser: Laden Sie jede Release-SBOM in einen Dependency-Track-Server. Er bewertet Ihr vorhandenes Inventar fortlaufend gegen neue Advisories. Wenn die nächste Lücke der Log4Shell-Klasse landet, haben Sie in Minuten eine Liste der betroffenen Services, ohne einen einzigen Build anzufassen. Dieser Geschwindigkeitsunterschied entscheidet den gesamten Vorfall, und er greift direkt in die Prozessarbeit aus unserem Incident-Response-Playbook. Die Uhr tickt dabei auch rechtlich: Fließen bei einem Lieferkettenvorfall personenbezogene Daten ab, bleiben Ihnen nach Art. 33 DSGVO 72 Stunden bis zur Meldung an die Aufsichtsbehörde. "Wir bauen erst alles neu und scannen dann" ist mit dieser Frist schlicht nicht vereinbar.

Ein Hinweis zum Betrieb: Dependency-Track ist Open Source und lässt sich problemlos selbst hosten. Das ist mehr als eine Geschmacksfrage. Ihre gesammelten SBOMs sind eine präzise Landkarte Ihrer gesamten Softwarelandschaft, inklusive jeder bekannten Schwachstelle. Ein solches Inventar gehört in Ihre eigene Infrastruktur oder zumindest auf europäische Server, nicht als Komfortfunktion in einen US-Clouddienst, dessen Unterauftragsverarbeiter niemand geprüft hat.

Rechnen Sie mit Rauschen. Ein Scanner, der gegen eine SBOM matcht, meldet verwundbare Versionen, deren Code Ihre Anwendung nie ausführt. Genau dafür gibt es VEX (Vulnerability Exploitability eXchange): eine maschinenlesbare Aussage, veröffentlicht neben der SBOM, die Ihre Analyse festhält:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [{
    "vulnerability": { "name": "CVE-2026-XXXXX" },
    "products": [{ "@id": "pkg:oci/api@sha256%3A3d1f..." }],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

Teams, die VEX auslassen, ertrinken in Findings, beginnen den Scanner zu ignorieren und stehen am Ende schlechter da als vor der Einführung. Triage ist kein optionaler Overhead. Triage ist das Produkt.

Was eine SBOM niemals erkennt

Seien Sie ehrlich zu den Grenzen, die Hersteller in ihren Broschüren gern verschweigen. Eine SBOM ist ein Inventar bekannter Komponenten. Gegen Folgendes richtet sie nichts aus:

• Bösartige Pakete ohne CVE. Ein Typosquat oder ein frisch mit einer Backdoor versehenes Release ist "sauber", bis es jemand entdeckt. Ihre SBOM listet es gewissenhaft auf und schlägt keinen Alarm.
• Kompromittierte Build-Systeme. SolarWinds hat vergiftete Builds aus einer sauberen Abhängigkeitsliste ausgeliefert. Die Schadsoftware kam während der Kompilierung hinein, unterhalb der Schicht, die eine SBOM überhaupt beschreibt.
• Übernommene Maintainer-Konten, die ein seriös wirkendes Patch-Release über den ganz normalen Kanal veröffentlichen.

Diese Lücken schließen Sie mit Provenance und Kontrollen am Eingang, nicht mit noch mehr Inventar.

Verlangen Sie Provenance. Kryptografische Belege dafür, woher ein Artefakt stammt und welche Pipeline es gebaut hat. SLSA liefert das Reifegradmodell, Sigstore das Werkzeug. Konkret: Veröffentlichen Sie eigene Pakete mit npm publish --provenance, verifizieren Sie fremde Images per cosign verify gegen die CI-Identität des Herausgebers, und behandeln Sie unsignierte Artefakte kritischer Lieferanten als eskalationswürdige Findings.

Pinnen Sie über Inhalt, nicht über Namen. Namen und Tags sind verschiebbar. Digests nicht:

# GitHub Actions: auf einen Commit-SHA pinnen, nicht auf einen Tag, den jemand umbiegen kann
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

# Basis-Images per Digest pinnen
FROM node:22-slim@sha256:3d1f9a...

Verlangsamen Sie den Eingang. Die meisten bösartigen Paketversionen werden binnen Tagen nach Veröffentlichung entdeckt und zurückgezogen. Eine Karenzzeit macht die Erkennungsleistung der Community zu Ihrem Schutz:

{
  "extends": ["config:recommended"],
  "minimumReleaseAge": "7 days",
  "internalChecksFilter": "strict"
}

Diese Renovate-Konfiguration bedeutet: Ein gekapertes Release muss eine Woche öffentliche Prüfung überstehen, bevor Ihre Bots es überhaupt vorschlagen. Der Preis sind geringfügig ältere Abhängigkeiten. Der Gewinn ist, dass Sie nicht mehr das frühe Opfer sind, das die Kompromittierung für alle anderen entdeckt.

Neutralisieren Sie Install-Skripte. npm ci --ignore-scripts in der CI entfernt das häufigste Ausführungsprimitiv, um den Preis, gelegentlich ein Paket freizugeben, das wirklich einen Build-Schritt braucht. Nach unserer Erfahrung lohnt sich dieser Tausch überall, Entwickler-Notebooks eingeschlossen.

Ein 30-Tage-Rollout, der wirklich hält

Die Reihenfolge ist entscheidend. Inventar vor Gates, Gates vor Signaturen. Teams, die mit Signaturen beginnen und Lockfiles überspringen, bauen eine Kathedrale auf Sand.

1. Tag 1 bis 3: Lockfile-Disziplin. Jedes Repository committet Lockfiles. Die CI installiert mit npm ci, pip install --require-hashes oder dem Äquivalent des jeweiligen Ökosystems und schlägt bei Abweichungen fehl.
2. Tag 4 bis 7: SBOMs in der CI erzeugen. Ergänzen Sie Syft in den Pipelines Ihrer fünf kritischsten Services. CycloneDX JSON, eine SBOM pro gebautem Artefakt, abgelegt beim Release.
3. Tag 8 bis 12: Dependency-Track aufsetzen. Jede SBOM automatisch einspeisen. Alerts in den Kanal leiten, den Ihre Rufbereitschaft tatsächlich liest.
4. Tag 13 bis 17: Baseline und Triage. Der erste Scan wird unangenehm. Klassifizieren Sie jedes Finding: jetzt ausnutzbar, geplantes Upgrade nötig, oder nicht betroffen (das VEX-Statement schreiben Sie, solange die Analyse frisch ist).
5. Tag 18 bis 22: die Pipeline absichern. Builds bei neuen kritischen Schwachstellen mit bekannten Exploits fehlschlagen lassen. Gaten Sie nicht auf den historischen Rückstand, sonst umgeht das Team das Gate innerhalb eines Monats.
6. Tag 23 bis 26: pinnen und verifizieren. CI-Actions per SHA und Basis-Images per Digest fixieren. Provenance-Verifikation für Ihre kritischsten Lieferanten aktivieren.
7. Tag 27 bis 30: die Karenzzeit ergänzen. Renovate oder Dependabot mit Mindestalter für Releases, plus --ignore-scripts in jedem CI-Job.

All das lebt in Ihrer Delivery-Pipeline, weshalb es in dasselbe Gespräch gehört wie der Rest Ihrer Kontrollen. Unsere Leitfäden zur DevSecOps-Pipeline und zu CI/CD-Pipelines, denen Teams vertrauen behandeln die umgebende Maschinerie.

Wie viel Strenge brauchen Sie wirklich?

Nicht jedes Team braucht SLSA Level 3. Das Raster, das wir mit Kunden anwenden:

• Sie verkaufen Software oder APIs an Konzerne, die öffentliche Hand oder regulierte Abnehmer. Volles Programm: SBOMs pro Release, Dependency-Track, VEX, signierte Provenance. Der Einkauf wird die Dokumente bald verbindlich fordern, und "die können wir nächstes Quartal erzeugen" kostet Aufträge.
• Sie betreiben SaaS für kleinere Kunden. SBOM-Erzeugung, kontinuierliches Scannen, Lockfile- und Karenzzeit-Disziplin. VEX verschieben Sie, bis das Scanner-Rauschen zu messbaren Kosten wird.
• Interne Tools, kleines Team. Lockfiles, osv-scanner in der CI, SHA-gepinnte Actions. Rund eine Stunde Aufwand kauft den Großteil der erreichbaren Risikoreduktion.
• Sie mergen viel KI-generierten Code. Setzen Sie ein menschliches Gate speziell auf die Einführung neuer Abhängigkeiten. LLMs halluzinieren plausible Paketnamen, Squatter registrieren genau diese Namen, und Slopsquatting ist inzwischen ein realer Angriffsweg am Eingang.

Der rote Faden: Kontrollen am Eingang sind günstig und dauerhaft. Analyse im Nachhinein ist teuer und kommt immer zu spät. Vertrauen in Ihren Abhängigkeitsbaum muss durch Belege verdient werden, nie vorausgesetzt. Es ist dasselbe Prinzip, das Zero Trust auf der Netzwerkschicht anwendet.

Wie Innovation T helfen kann

Innovation T baut und betreibt genau diese Maschinerie für Teams in ganz Europa und Nordafrika: SBOM-Erzeugung fest in der CI verdrahtet, Dependency-Track-Installationen, die den Kontakt mit realem Alert-Aufkommen überleben, signierte Provenance und Eingangsrichtlinien, die Entwickler schnell halten und Angreifer langsam machen. Den obigen 30-Tage-Rollout führen wir als Projekt mit festem Umfang durch und übergeben Ihnen anschließend eine Pipeline, die Ihr Team wirklich selbst pflegt.

Wenn ein Kunde Sie gerade nach einer SBOM gefragt hat, oder wenn Sie die Frage "Läuft bei uns die betroffene Version?" nicht innerhalb einer Stunde beantworten können, sprechen Sie mit uns. Entdecken Sie unsere Services oder nehmen Sie Kontakt auf für ein Supply-Chain-Readiness-Assessment.