SBOM-Strategie und Attestierung für OSS-Projekte: Ein Best-Practices-Leitfaden für 2026
| Jason Smith — CEO, ShiftLeftCyber
Das Open-Source-Ökosystem steht vor einem beispiellosen regulatorischen und operativen Wandel. Open-Source-Maintainer tragen heute dieselbe Verantwortung für Lieferketten-Anforderungen wie kommerzielle Anbieter. Zwischen der Durchsetzung des EU Cyber Resilience Act (CRA), den Premarket-Vorgaben der US-amerikanischen FDA und NIS2 gilt die Grundannahme, dass Software nicht ausgeliefert werden kann ohne eine gepflegte Software Bill of Materials (SBOM) und einen überprüfbaren Nachweis darüber, wie sie erstellt wurde.
Für ein OSS-Projekt hängt das Erreichen dieser Messlatte von zwei Dingen ab: einer klaren SBOM-Strategie (was Sie produzieren, in welchem Format und wie) und einem widerstandsfähigen Attestierungsmodell (wie Abnehmer dem vertrauen können, was Sie produziert haben). Wenn ein nachgelagerter Hersteller globale Vorschriften erfüllen muss, gibt er diese Anforderungen an die vorgelagerte Ebene weiter. Liefert Ihr Projekt eine hochwertige SBOM, bleiben Sie in dessen Stückliste. Wenn nicht, werden Sie zu der Sicherheitslücke, um die herum konstruiert werden muss.
Dieser Leitfaden beschreibt das übergeordnete SBOM-Framework und die Praktiken, die den Compliance-Standards von Unternehmen im Jahr 2026 standhalten.
✅ TL;DR: Eine Checkliste für SBOM und Attestierung in OSS-Projekten
Ein SBOM-Format wählen (CycloneDX oder SPDX)
SBOMs in CI-Pipelines generieren (bei jedem Build/Release)
Das Trust-Modell aufbauen (Provenance + Signaturen)
Dort verteilen, wo Abnehmer sie tatsächlich finden
Mit dynamischen VEX-Informationen anreichern
Den langfristigen Lebenszyklus und die Aufbewahrung planen
📄 Schritt 1: Ein SBOM-Format wählen und sich darauf festlegen
Der Formatkrieg ist die falsche Sache, über die man sich den Kopf zerbrechen sollte. Beide großen Formate (CycloneDX und SPDX) sind global anerkannte Standards, breit akzeptiert und werden rasch modernisiert. Wählen Sie eines als Ihr kanonisches Ausgabeformat und konvertieren Sie bei Bedarf, wenn ein Abnehmer das andere benötigt. Vollständigkeit und Automatisierung sind weitaus wichtiger als die Wahl des Formats.
Merkmal | CycloneDX | SPDX |
|---|---|---|
Primäre Stärke | Application Security, VEX, definierter Signaturstandard | Lizenz-Compliance, juristische Prüfung, Standardisierung auf ISO-Ebene |
Standard | ECMA-424 | ISO/IEC 5962 |
Neueste Version | 1.7 | 3.0 |
Verbreitetes Ökosystem | AppSec und automatisierte Lieferketten-Tools | Juristische Compliance in Unternehmen und regulierte Branchen |
Unterstützte Formate | JSON / XML / Protobuf Hinweis: Es wird erwartet, dass CycloneDX in Version 2.0 – die voraussichtlich später im Jahr 2026 erscheint – ausschließlich auf JSON umstellt. | JSON-LD, XML, RDF |
🛠️ Schritt 2: Ihre SBOMs automatisch in der CI bei jedem Build generieren
Eine handgefertigte oder manuell erstellte SBOM ist in dem Moment veraltet, in dem sich Ihr Abhängigkeitsbaum ändert. Die einzige dauerhafte Praxis besteht darin, die SBOM als zentrales Build-Artefakt zu behandeln.
Die Pipeline automatisieren: Führen Sie die SBOM-Generierung als nativen CI-Schritt aus (GitHub Actions, GitLab CI usw.), gebunden an Ihren Release-Tag oder Commit. Schlägt die SBOM-Generierung fehl, schlägt der Build fehl.
Aus dem Artefakt generieren, nicht nur aus dem Manifest: Manifeste und Lock-Dateien übersehen häufig transitive, vorübergehende oder zur Build-Zeit vorhandene Komponenten. Das gilt besonders für komplexe Setups wie C/C++, bei denen die SBOM aus dem tatsächlichen Build-Prozess abgeleitet werden muss und nicht aus einem statischen Paketmanager.
Strikte Versionsabstimmung: Eine Release-SBOM muss explizit versioniert, getaggt und zusammen mit der genauen Build-Version, die sie repräsentiert, nachverfolgt werden (z. B. v1.4.2-sbom.json passend zu v1.4.2.tar.gz).
🛡️ Schritt 3: Das Trust-Modell aufbauen
Eine SBOM sagt Abnehmern, was enthalten ist. Eine Attestierung sagt ihnen, dass sie es glauben können. Dies ist der entscheidende Schritt, den die meisten Projekte überspringen – und genau das, was Regulierungsbehörden zunehmend verlangen.
Ein Attestierungsmodell für ein OSS-Projekt besteht aus drei Schichten:
Provenance: Eine Aussage darüber, wie die Artefakte und SBOMs erstellt wurden. Die Frameworks in-toto / SLSA definieren dies. Viele CI-Systeme können SLSA-Provenance nativ ausgeben.
Signierung: Signieren Sie die SBOM und die Provenance, sodass Manipulationen erkennbar und der Unterzeichner überprüfbar sind.
Selbstattestierung: Für Projekte, die in US-amerikanische föderale Lieferketten einfließen, ist das Secure Software Development Attestation Form die standardisierte Methode, um die Konformität mit sicheren Entwicklungspraktiken zu bestätigen.
Zusammen verwandeln diese „hier ist eine JSON-Datei" in „hier ist ein signierter, überprüfbarer Nachweis dessen, was wir ausgeliefert haben und wie" – genau das, wonach die Frameworks CRA, FDA und NIS2 suchen.
📦 Schritt 4: Dort verteilen, wo Abnehmer sie tatsächlich finden
Der häufigste Fehler ist nicht das Generieren einer SBOM, sondern ihr Verlust. Das Anhängen einer losen JSON-Datei an eine GitHub-Release-Seite macht sie für automatisierte Unternehmensscanner und Sicherheitstools unsichtbar. GitHub-Releases sind der Ort, an dem SBOMs sterben.
Bessere Praktiken für die Verteilung:
Hängen Sie die signierte SBOM direkt an die Artefakt-Registry an (z. B. als OCI-/Registry-Attestierung oder Paket-Metadaten), damit sie mit der Software mitwandert.
Verwenden Sie eine stabile, vorhersehbare URL oder API pro Release.
Halten Sie historische SBOMs verfügbar. Abnehmer, die eine alte Version prüfen, benötigen die SBOM, die zu diesem Build passt.
✨ Schritt 5: Mit dynamischen VEX-Informationen anreichern
Eine SBOM ist ein statisches Inventar. Die Bestandteile eines bestimmten Releases werden sich nie ändern. Schwachstellendaten sind jedoch hochdynamisch. Eine Komponente, die heute als völlig sicher gilt, könnte morgen einen kritischen Zero-Day aufweisen.
Der Abgleich einer rohen SBOM mit einer Schwachstellendatenbank kann eine Flut von Fehlalarmen erzeugen. Um dies zu lösen, ergänzen Sie Ihre Strategie um VEX (Vulnerability Exploitability eXchange). Mit VEX können Sie pro Schwachstelle angeben, ob Ihr Produkt tatsächlich betroffen ist, und verwandeln die SBOM so von einem Lärmerzeuger in ein Entscheidungswerkzeug für diejenigen, die sie nutzen.
Einen kontinuierlichen Rhythmus etablieren: Pflegen Sie eine lebendige, dynamische VEX-Begleitdatei oder einen entsprechenden Endpunkt. Führen Sie automatisierte tägliche oder Commit-bezogene Schwachstellenscans gegen aktive Branches durch und aktualisieren Sie Ihre VEX-Daten, damit Abnehmer einen echten, umsetzbaren Ausnutzbarkeitsstatus sehen statt rohem CVE-Lärm.
🔁 Schritt 6: Den langfristigen Lebenszyklus und die Aufbewahrung planen
Das Generieren einer SBOM ist eine zeitpunktbezogene Handlung, doch ihre Verwaltung ist eine mehrjährige Verpflichtung. Unter globalen Frameworks wie dem EU Cyber Resilience Act (CRA) unterliegen Softwarehersteller einer strikten zehnjährigen Datenaufbewahrungspflicht nach dem Ende des Produktlebenszyklus. Ihre Artefakte müssen sich von temporären Pipeline-Ausgaben in ein dauerhaftes Compliance-Archiv verwandeln.
Historische SBOMs müssen stabil, vorhersehbar und adressierbar bleiben. Wenn ein Abnehmer in einem Jahrzehnt eine alte Version prüfen muss, muss genau die passende SBOM abrufbar sein.
Wie Interlynk hilft
Interlynk automatisiert diesen gesamten Lebenszyklus für OSS- und Produktteams: Generierung über Ökosysteme hinweg (einschließlich schwieriger Fälle wie C/C++), Formatkonvertierung, Signierung und Attestierung, VEX sowie Versionierung pro Release. So läuft die obige Strategie in der CI statt von Hand. Kostenlos starten oder eine Demo buchen.
Weiterführende Literatur
ShiftLeftCyber, ein stolzer Partner von Interlynk, bietet mit seiner Lösung SecureSBOM die digitale Signierung und Verifizierung von SBOMs. Weitere Einblicke von ShiftLeftCyber finden Sie im ShiftLeftCyber-Blog, oder folgen Sie Jason auf LinkedIn für regelmäßige Updates zur Sicherheit der Software-Lieferkette.