Open-Source-Tools für Software-Lieferketten: SBOM & SLSA

Ein modernes Deployment besteht aus Quellcode, Abhängigkeiten, Containern, CI/CD und einem Haufen Metadaten. Genau hier entstehen die typischen Lieferkettenprobleme: veraltete Libraries, unklare Herkunft eines Images oder Builds, die sich nicht reproduzieren lassen. Zwei Konzepte helfen, Ordnung in diese Komplexität zu bringen: Eine Stückliste aller Komponenten und ein nachweisbarer Build-Prozess.

In der Praxis fallen dabei zwei Begriffe besonders häufig: SBOM (Software Bill of Materials) und SLSA (Supply-chain Levels for Software Artifacts). Beides sind keine „Tools“, sondern Rahmenwerke bzw. Datenmodelle, die durch Werkzeuge und Prozesse erst wirksam werden. Der Mehrwert liegt weniger in einem einzelnen Scan als in einer Kette aus wiederholbaren Schritten: erzeugen, prüfen, signieren, veröffentlichen, nachverfolgen.

Welche Probleme SBOM und SLSA in Teams wirklich lösen

Transparenz über Abhängigkeiten statt Bauchgefühl

Abhängigkeiten sind häufig indirekt: Eine Bibliothek zieht Dutzende weitere Pakete nach. Ohne Stückliste bleibt unklar, welche Versionen tatsächlich im Artefakt landen. Eine SBOM bildet diese Information maschinenlesbar ab. Das erleichtert Patch-Entscheidungen, Incident Response und interne Freigabeprozesse (z. B. „Welche Komponenten sind in Release X enthalten?“).

Nachvollziehbare Builds statt „works on my machine“

SLSA adressiert die Frage, ob ein Artefakt aus dem erwarteten Quellcode stammt und unter kontrollierten Bedingungen gebaut wurde. Im Kern geht es um Provenance (Herkunftsnachweis): Welche Quellen, welche Build-Umgebung, welche Schritte, welche Identitäten. Für Organisationen bedeutet das: weniger Blindflug bei Artefakten aus CI/CD und ein besserer Ausgangspunkt für Audit-Anforderungen.

Pragmatische Erwartung: Sicherheit wird messbarer, nicht magisch

Wichtig ist die Einordnung: SBOM und SLSA verhindern keine Schwachstellen „automatisch“. Sie schaffen überprüfbare Daten, auf deren Basis Entscheidungen getroffen werden können. Der Qualitätsgewinn entsteht durch saubere Integration in Pipelines, klare Verantwortlichkeiten und gelebte Pflege.

Wie SBOMs praktisch erzeugt werden: Formate, Tiefe, Grenzen

Formate und Interoperabilität (SPDX, CycloneDX)

In der Open-Source-Welt haben sich vor allem SPDX und CycloneDX als Austauschformate etabliert. Beide sind darauf ausgelegt, Komponenten, Versionen, Lizenzen und Beziehungen zwischen Abhängigkeiten zu beschreiben. Relevant ist weniger „das beste Format“, sondern die Anschlussfähigkeit an die eigene Toolchain (Scanner, CI, Dependency-Management, Ticketing).

Welche „Tiefe“ eine SBOM haben sollte

SBOMs unterscheiden sich stark darin, was sie abdecken. Typische Varianten:

• SBOM für Build-Artefakte (z. B. Container-Image): zeigt, was tatsächlich ausgeliefert wird.
• SBOM für Source-Dependencies: zeigt, was im Projekt deklariert ist, aber nicht zwingend im finalen Artefakt landet.
• Mehrere SBOMs pro Produkt: etwa getrennt für Backend, Frontend und Base-Image.

Für Teams ist oft ein gestufter Einstieg sinnvoll: erst Artefakt-SBOMs (Container/Packages), danach feinere Auflösung für Quellcode und Build-Inputs.

Typische Fallstricke bei der SBOM-Nutzung

• Unvollständige Erkennung durch exotische Build-Schritte (z. B. selbst kompilierte Binaries ohne Paketmanager).
• Fehlende Normalisierung von Paketnamen (Mapping zwischen Ökosystemen und Identifikatoren).
• SBOM wird generiert, aber nicht versioniert, nicht signiert und nicht an Releases gekoppelt.

SLSA in der Umsetzung: Provenance, Signaturen und CI/CD

Provenance als Kernartefakt

Damit SLSA greift, muss Provenance als erstklassiges Artefakt behandelt werden: gemeinsam mit dem Build-Output erzeugen, speichern, referenzieren und gegen Veränderungen schützen. Provenance beantwortet Fragen wie: Welcher Commit wurde gebaut? Welche Pipeline lief? Welche Inputs wurden verwendet? Ohne diese Daten bleibt SLSA reine Absichtserklärung.

Signieren und verifizieren: der Kontrollpunkt in der Pipeline

Ein robuster Lieferkettenprozess setzt auf kryptografische Signaturen, damit Artefakte und Metadaten (SBOM/Provenance) nicht unbemerkt ausgetauscht werden. In der Praxis geht es um verifizierbare Aussagen: „Dieses Image stammt aus dieser Pipeline“ und „diese SBOM gehört zu genau diesem Image“. Das stärkt interne Freigaben und reduziert Risiken bei Artefakt-Promotion (Dev → Staging → Prod).

Realistische Einführung: nicht alles auf einmal

SLSA wird häufig über CI/CD umgesetzt. Der Einstieg gelingt, wenn zuerst die Pipeline „geschlossen“ wird: Build nur in CI, klare Identitäten für Runner, minimale Rechte, keine manuellen Uploads in Registries. Danach lohnen sich Provenance-Generierung und verpflichtende Verifikation vor Deployments.

Bewährte Open-Source-Werkzeuge für SBOM und Lieferkette

SBOM-Generatoren und Scanner

In vielen Setups haben sich folgende Open-Source-Werkzeuge etabliert:

• Syft: erzeugt SBOMs aus Container-Images und Dateisystemen; gut für Artefakt-Sicht.
• Trivy: kombiniert Vulnerability-Scanning mit SBOM-Erstellung; verbreitet in CI für Container-Workloads.
• OWASP Dependency-Check: fokussiert auf Dependency-Erkennung und Schwachstellenabgleich, vor allem im Application-Kontext.

Entscheidend ist nicht die Tool-Liste, sondern der Ort im Prozess: Generierung beim Build, Speicherung beim Release, Verknüpfung mit dem Artefakt und regelmäßige Aktualisierung.

Signieren und Metadaten binden

Für Signaturen und das Binden von Metadaten an Artefakte werden oft eingesetzt:

• Sigstore (u. a. cosign): Signieren und Verifizieren von Container-Images und zugehörigen Metadaten.
• in-toto: Modell und Tools, um Schritte in der Lieferkette attestierbar zu machen.
• GPG-basierte Signaturen: verbreitet, aber in CI/CD häufig schwerer konsistent zu betreiben als moderne Workflows.

Wo interne Prozesse wichtiger sind als Tools

Auch das beste Werkzeug scheitert an unklaren Zuständigkeiten. Wer erzeugt SBOMs? Wer entscheidet über Policy-Verstöße? Wer pflegt Ausnahmen? In reifen Setups gibt es definierte Owners (z. B. Platform/DevSecOps) und verbindliche Qualitätsgates in CI.

Lizenz- und Compliance-Aspekte: SBOM als Nebenprodukt mit Wirkung

Lizenzinformationen in SBOMs richtig einordnen

SBOMs enthalten häufig Lizenzhinweise. Das ist nützlich, ersetzt aber keine saubere Lizenzprüfung: Erkennung kann unvollständig sein, und tatsächliche Pflichten hängen von Nutzung, Distribution und Kombination der Komponenten ab. Besonders in Unternehmen ist es sinnvoll, SBOM-Daten in bestehende Compliance-Prozesse einzuspeisen, statt ein Parallel-System aufzubauen.

SPDX-Identifiers und klare Lizenztexte

In Projekten hilft konsistente Lizenzkennzeichnung (z. B. mit SPDX-Kennungen in Dateiköpfen oder Manifesten), damit SBOMs und Scans verlässlicher werden. Das reduziert Rückfragen in Audits und beschleunigt Freigaben. Für eine grundsätzliche Einordnung von Lizenzfamilien lohnt sich der Überblick unter Open-Source-Lizenzen: MIT, Apache oder GPL wählen.

Woran sich Projektreife und Nachhaltigkeit in der Lieferkette zeigen

Community- und Wartungssignale

Bei Open-Source-Werkzeugen für die Lieferkette ist Nachhaltigkeit entscheidend: Ein nicht gepflegter SBOM-Generator wird schnell zum Risiko. Relevante Signale sind nachvollziehbar, ohne in Metrik-Fetischismus zu verfallen: dokumentierte Releases, aktive Issue-Triage, transparente Roadmaps, reproduzierbare Builds, klare Security-Policies.

Governance und Verantwortlichkeiten

Gerade sicherheitsnahe Infrastruktur profitiert von klarer Governance (Wer entscheidet über Breaking Changes? Wie werden Maintainer ergänzt? Gibt es ein Security-Disclosure-Verfahren?). Für den Einsatz in regulierten Umfeldern sind nachvollziehbare Release-Prozesse und signierte Artefakte oft wichtiger als eine besonders große Feature-Liste.

Ein praxisnaher Einstieg, der in zwei Sprints funktioniert

Schritte, die sich in bestehenden Pipelines bewähren

• Pro Release ein Artefakt (z. B. Container) als „Source of Truth“ festlegen und daran SBOM + Provenance koppeln.
• SBOM bei jedem Build erzeugen und mit Versionsbezug speichern (Release-Tag/Build-Nummer).
• Signaturen für Artefakte einführen und Verifikation vor Deployments verpflichtend machen.
• Policy definieren: Welche Schweregrade blockieren? Welche Ausnahmen sind zulässig, wer genehmigt sie?
• Pflege organisieren: Ownership im Team klären, regelmäßige Review-Termine und Backlog für Tool-Updates.

Wer zusätzliche Grundlagen zu offener Entwicklung und Verantwortung in Projekten benötigt, findet eine allgemeine Einordnung unter Open Source.

Vergleich: SBOM-Pflicht vs. SLSA-Ansatz – was bringt zuerst Nutzen?

Häufige Fragen aus der Praxis rund um Lieferkettentransparenz

Muss eine SBOM öffentlich sein?

Nein. Viele Organisationen behandeln SBOMs als interne Artefakte, weil sie Systemdetails enthalten können. Für Austausch mit Kund:innen oder Partnern lassen sich redigierte Varianten nutzen. Wichtig ist, dass SBOMs auffindbar, versioniert und eindeutig einem Release zugeordnet sind.

Ersetzt SBOM ein Vulnerability-Scanning?

Nein. SBOM liefert die Stückliste; das Schwachstellenmanagement braucht zusätzlich Datenquellen und Prozesse (Bewertung, Priorisierung, Patch-Rollout). Der Vorteil: Mit SBOM wird klar, ob eine betroffene Komponente tatsächlich im eigenen Artefakt steckt.

Welche Lizenz passt zu internen Tools in der Pipeline?

Für intern genutzte Pipeline-Tools sind die Pflichten oft überschaubar, solange keine Distribution erfolgt. Dennoch sollten Lizenzen bewusst geprüft werden, insbesondere bei Weitergabe an Kund:innen, bei SaaS-Offering oder beim Einbetten von Komponenten. Relevant sind dabei auch Abhängigkeiten der Tools selbst.