Software Supply Chain Security mit einer SBOM — Kenne die Bestandteile deiner Anwendung

Ein Paket zu installieren fühlt sich oft so alltäglich an, wie eine Zutat aus dem Supermarktregal zu nehmen. Ein einziger Befehl bringt Tausende Codezeilen in eine Anwendung, und wir entwickeln weiter, ohne die Autoren zu kennen oder jede Datei zu prüfen. Dieser Komfort ist wertvoll, bedeutet aber auch, dass unsere Software aus einer Supply Chain besteht, die wir möglicherweise kaum sehen.

Software Supply Chain Security bezeichnet den Schutz dieser gesamten Kette: Source Code, Third-Party Libraries, Build Tools, Package Registries, CI/CD-Workflows und schließlich ausgelieferte Artefakte. Eine Software Bill of Materials, meist SBOM genannt, liefert ein Inventar dieser Zutaten. Sie macht eine Anwendung nicht automatisch sicher, verwandelt aber einen unsichtbaren Dependency Tree in Informationen, die ein Team prüfen, vergleichen und bearbeiten kann.

Die Supply Chain ist größer als die Dependency-Liste

Entwickler verstehen unter Dependencies häufig die Einträge in package-lock.json, composer.lock oder einer anderen Lockfile. Diese Dateien sind wichtig, doch die Supply Chain beginnt früher und endet später. Dazu gehören das Maintainer-Konto, das ein Paket veröffentlicht, die Registry, die es ausliefert, eine beim Build verwendete Action, das Base Image eines Containers und der Server, der ein Release signiert.

Ein Angreifer muss nicht immer die Eingangstür einer Anwendung aufbrechen. Ein kompromittiertes vertrauenswürdiges Tool kann einen Seiteneingang in jedes Projekt öffnen, das dieses Tool nutzt. Typosquatting-Pakete imitieren bekannte Namen. Gestohlene Maintainer-Zugangsdaten können ein legitimes Update in Malware verwandeln. Ein veränderliches Container-Tag kann morgen unbemerkt auf andere Bytes zeigen. Gefährlich wird es, wenn Vertrauen Grenzen ohne ausreichende Prüfung überschreitet.

Man kann sich ein kleines Restaurant vorstellen. Lebensmittelsicherheit hängt nicht nur davon ab, dass der Koch seine Hände wäscht, sondern ebenso von Lieferanten, Kühlung, Transportbedingungen und dem Wissen, welche Gerichte eine zurückgerufene Zutat enthalten. Software funktioniert ähnlich. Sicherer Code kann Risiken von einer Upstream-Komponente erben, während ein klares Inventar die Suche nach betroffenen Systemen erheblich beschleunigt.

Was eine SBOM tatsächlich enthält

Eine SBOM ist ein maschinenlesbarer Datensatz, der die Komponenten in einem Softwareartefakt beschreibt. Verbreitete Formate sind SPDX und CycloneDX. Ein nützliches Dokument kann Paketnamen, Versionen, Lieferanten, Lizenzen, kryptografische Hashes, Dependency-Beziehungen und Package URLs enthalten. Es kann ein Anwendungs-Repository, ein Container Image, Firmware oder ein veröffentlichtes Binary beschreiben.

Der Unterschied zwischen Lockfile und SBOM ist wichtig. Eine Lockfile hilft in erster Linie einem Package Manager, eine Installation zu reproduzieren. Eine SBOM soll die Zusammensetzung über Tools und Organisationen hinweg kommunizieren. Sie kann Betriebssystempakete und erzeugte Artefakte erfassen, die eine sprachspezifische Lockfile übersieht. Beide ergänzen einander, statt miteinander zu konkurrieren.

Eine SBOM ist außerdem eine Momentaufnahme und kein aktuelles Sicherheitsurteil. Dass openssl oder eine JavaScript Library im Dokument erscheint, sagt nicht, ob sie im eigenen Kontext ausnutzbar ist. Es zeigt, dass die Komponente vorhanden ist, welche Version beobachtet wurde und häufig, wie sie mit dem Rest der Anwendung zusammenhängt. Diese Evidenz unterstützt die anschließende Untersuchung.

Eine SBOM für das tatsächlich ausgelieferte Artefakt erzeugen

Mehrere Open-Source-Tools können eine SBOM erzeugen, darunter Syft, Trivy und sprachspezifische Plugins. Am nützlichsten ist ein Scan des Artefakts, das in die Produktion gelangt, denn ein Repository-Scan sieht möglicherweise keine Pakete aus einem Container Base Image oder Build-Prozess. Das folgende Beispiel erzeugt mit Syft ein CycloneDX-JSON-Dokument aus einem lokalen Container Image:

syft myapp:1.4.0 -o cyclonedx-json=sbom.cdx.json
sha256sum sbom.cdx.json > sbom.cdx.json.sha256

Das Ergebnis lässt sich prüfen und neben dem zugehörigen Release-Artefakt aufbewahren. Jedes Release sollte eine feste Version oder einen Digest bekommen, statt nur ein Tag wie latest zu verwenden. Die Checksum erkennt unbeabsichtigte Änderungen am Dokument, während der Artefakt-Digest eine präzise Verbindung zwischen dem gescannten und dem ausgelieferten Objekt schafft.

Die Erzeugung sollte nach dem finalen Build in CI/CD automatisiert werden und nicht kurz vor einem Audit aus dem Gedächtnis erfolgen. Die SBOM kann als Pipeline-Artefakt gespeichert oder einem Release angehängt werden. Sie sollte nicht unbedacht veröffentlicht werden, wenn sie private Paketnamen oder interne Architektur offenlegt; der Zugriff muss zur Sensibilität der Software und zu den Anforderungen von Kunden oder Betreibern passen.

Das Inventar scannen und Funde anschließend untersuchen

Sobald eine SBOM existiert, kann ein Vulnerability Scanner ihre Komponenten mit Advisory-Datenbanken vergleichen. Grype akzeptiert beispielsweise direkt eine SBOM:

grype sbom:sbom.cdx.json --only-fixed

Die Ausgabe ist eine erste Warteschlange und kein automatisches Urteil. Vulnerability-Daten können False Positives, unvollständige Versionszuordnungen oder Probleme enthalten, die in der Anwendung nicht erreichbar sind. Umgekehrt beweist „no vulnerabilities found“ keine Sicherheit: Datenbanken hinken Entdeckungen hinterher, und Supply-Chain-Angriffe können bösartiges Verhalten ohne veröffentlichte CVE umfassen.

Funde sollten anhand von Severity, Exposure, Exploitability und geschäftlichen Auswirkungen priorisiert werden. Ein kritischer Fehler in einer ungenutzten Build-Time-Komponente kann eine andere Reaktion verlangen als ein High-Severity-Fehler, der aus dem öffentlichen Internet erreichbar ist. Es sollte dokumentiert werden, warum ein Fund akzeptiert, mitigiert oder eingeplant wurde. So beginnt derselbe Alert nächste Woche nicht wieder dieselbe Diskussion.

Vertrauen reduzieren, bevor weitere Scanner hinzukommen

Inventar und Scanning sind nützlich, doch Prävention beginnt mit weniger unnötigem Vertrauen. Dependencies und CI Actions sollten an unveränderliche Versionen oder Commit Hashes gebunden werden. Änderungen an Lockfiles brauchen ein Review. Registry- und Source-Control-Konten sollten durch starke Authentifizierung geschützt sein. CI Tokens benötigen nur die tatsächlich notwendigen Rechte und Laufzeiten, während Signing Keys nicht in gewöhnliche Build Logs gehören.

Auch der Dependency Tree sollte klein bleiben. Jedes Paket ist eine weitere Beziehung, die überwacht werden muss, ähnlich wie ein zusätzlicher Schlüsselinhaber in einem Gebäude. Eine kleine Utility mit Dutzenden transitiven Dependencies kann mehr Sicherheitsaufwand verursachen, als zehn klare Zeilen lokal zu schreiben. Das bedeutet nicht „niemals Libraries verwenden“; ihr Komfort sollte das hinzugefügte Vertrauen rechtfertigen.

Reproducible Builds, Provenance Attestations, signierte Releases und isolierte Build Runner schaffen stärkere Sicherheit, wenn ein Projekt reift. Beginnen sollte man mit Kontrollen, die das Team dauerhaft einhalten kann. Eine einfache und konsequent befolgte Review-Regel ist wertvoller als ein kompliziertes Framework, das bei einem eiligen Release jeder umgeht.

Einen praktischen Response-Workflow aufbauen

Während eines Incidents zeigt ein Inventar seinen Wert. Wird eine neue Schwachstelle oder ein kompromittiertes Paket bekannt, lassen sich alle gespeicherten SBOMs nach der betroffenen Komponente und Version durchsuchen. Danach wird ermittelt, welche Produkte und Umgebungen sie enthalten, ob die verwundbare Funktion verwendet wird und ob ein Patch, eine Mitigation oder ein Rebuild nötig ist. Ohne Inventar wird daraus eine Nachricht an alle Entwickler: „Verwenden wir das irgendwo?“

Die Zuständigkeit sollte vor dem Alarm feststehen. Es muss klar sein, wer Dependency Alerts prüft, wie dringende Funde eskaliert werden, wann Ausnahmen ablaufen und wie neu gebaute Artefakte die Produktion erreichen. Alte SBOMs sollten lange genug für Untersuchungen historischer Exposure aufbewahrt werden. Sind Kunden von der Software abhängig, braucht es einen sicheren Weg, relevante Informationen zur Zusammensetzung und Remediation mit ihnen zu teilen.

Der Workflow lässt sich mit einer harmlosen Übung testen. Dazu wählt man ein bekannt veraltetes Paket in einem Staging Image, findet es über die SBOM, erstellt ein Ticket, aktualisiert es, baut neu und bestätigt, dass die nächste SBOM die alte Version nicht mehr enthält. Eine solche Feuerwehrübung deckt fehlende Zuständigkeiten und kaputte Automation auf, solange es noch nicht wirklich brennt.

Eine kleine Checkliste für den Einstieg

Bei einer kleinen Anwendung genügen zunächst fünf wiederholbare Schritte: für jedes Release-Artefakt eine SBOM erzeugen, sie mit dem Artefakt-Digest aufbewahren, sie gegen aktuelle Advisories scannen, Dependency-Änderungen so sorgfältig wie Anwendungscode prüfen und die Reaktion auf eine verwundbare Komponente üben. Signing und Provenance folgen, sobald dieses Fundament zuverlässig funktioniert.

Gemessen werden sollten nützliche Ergebnisse statt die Anzahl der Dokumente. Kann das Team beantworten, welche ausgelieferten Releases ein bestimmtes Paket enthalten? Wie lange dauert die Antwort? Haben kritische Dependencies einen Owner und werden sie aktualisiert? Lässt sich ein Release aus geprüften Inputs neu bauen? Diese Fragen zeigen, ob das Programm Entscheidungen verbessert oder nur eine weitere JSON-Datei für das Archiv produziert.

Fazit: Die Zutaten vor dem Rückruf kennen

Moderne Software wird weiterhin von Code abhängen, den andere schreiben und verteilen. Ziel ist nicht, diese Zusammenarbeit abzuschaffen, sondern Vertrauen sichtbar und bewusst zu machen. Eine SBOM liefert die Zutatenliste; sichere Konten, fest gebundene Inputs, sorgfältige Reviews, Scanning und ein erprobter Response-Prozess liefern die Küchendisziplin darum herum.

Der Einstieg gelingt mit einer Anwendung und einer Release Pipeline. Erzeuge ihre SBOM, verbinde sie mit dem exakten Artefakt und übe, eine einfache Frage zu einer Dependency zu beantworten. Wenn du bereits SBOM-Tools nutzt oder einen Supply-Chain-Incident erlebt hast, teile in den Kommentaren, was funktioniert hat, damit andere Leser ihren eigenen Prozess stärken können.