Ein SBOM (Software Bill of Materials) ist die „Zutatenliste" Ihrer Software: das vollständige Verzeichnis von Paketen, Bibliotheken, Versionen und Abhängigkeiten, die ein Image enthält. Wie ein Nährwertetikett sagt es genau, was drin ist.
Sein Wert wird am Tag einer kritischen Schwachstelle offensichtlich: Statt Dutzende Images von Hand zu durchforsten, fragen Sie das SBOM ab und wissen in Sekunden, welche Images die betroffene Komponente enthalten und in welcher Version.
Warum es für Ihre Images zählt
- Schnelle CVE-Reaktion: Sie erkennen sofort, ob eine neue Schwachstelle Sie betrifft.
- Sicherheit der Lieferkette: Sie wissen, woher jede Komponente stammt.
- Compliance: Immer mehr Rahmenwerke und Kunden verlangen es als Nachweis.
- Transparenz: Wenn Sie Images veröffentlichen, schafft ein SBOM Vertrauen bei den Nutzern.
Standardformate
| Format | Herkunft | Anmerkungen |
|---|---|---|
| SPDX | Linux Foundation / ISO | ISO-Standard, in Compliance weit verbreitet |
| CycloneDX | OWASP | Sicherheitsorientiert, reichhaltig für Schwachstellenanalyse |
Die beiden dominierenden SBOM-Formate; viele Werkzeuge exportieren in beide.
So erzeugen Sie ein Image-SBOM Schritt für Schritt
- Werkzeug wählen: Syft von Anchore ist ein De-facto-Standard, um SBOMs von Images und Dateisystemen zu erzeugen; es gibt auch cloud-native Optionen.
- In der Pipeline erzeugen: Beim AMI-Build das Dateisystem scannen und das SBOM ausgeben, etwa in CycloneDX und SPDX.
- Schwachstellen analysieren: Das SBOM durch Grype oder Trivy schicken, um es mit CVE-Datenbanken abzugleichen.
- Signieren und archivieren: Das SBOM signieren —etwa mit cosign— und als Artefakt zur Image-Version ablegen.
- Bei Bedarf abfragen: Taucht ein neues CVE auf, prüfen Sie Ihre archivierten SBOMs, um die Reichweite zu bestimmen.
Der regulatorische Kontext 2026
SBOMs gewinnen seit Jahren als gute Praxis für Lieferkettensicherheit an Gewicht. Das regulatorische Bild ist allerdings differenziert: In den USA hat die Verwaltung 2026 die geerbten Software-Attestierungsvorgaben hin zu einem stärker risikobasierten Ansatz überarbeitet, während in der Europäischen Union Regelwerke wie der Cyber Resilience Act Softwaretransparenz und Komponenteninventare vorantreiben. Praktisches Fazit: Unabhängig vom regulatorischen Hin und Her sind SBOMs ein defensiver und kommerzieller Vorteil, den man sich zulegen sollte.
Bewährte Praktiken
- Erzeugen Sie das SBOM automatisch bei jedem Build, nicht von Hand.
- Bewahren Sie es versioniert neben dem zugehörigen Image auf.
- Kombinieren Sie es mit Schwachstellen-Scans, damit es handlungsleitend wird.
- Signieren Sie es, um Integrität und Herkunft zu garantieren.
Häufig gestellte Fragen
Ist ein SBOM dasselbe wie ein Schwachstellen-Scan?
Nein. Das SBOM ist das Komponenteninventar; der Scan gleicht dieses Inventar mit CVE-Datenbanken ab, um Schwachstellen zu finden. Sie ergänzen sich: Zuerst wissen Sie, was Sie haben, dann, ob es verwundbar ist.
SPDX oder CycloneDX?
SPDX ist ein ISO-Standard, der in der Compliance viel genutzt wird; CycloneDX ist stärker sicherheitsorientiert. Viele Werkzeuge exportieren in beide, Sie müssen sich also nicht festlegen.
Brauche ich ein SBOM, wenn ich nur fremde Images nutze?
Ja. Das SBOM der genutzten Images anzufordern oder zu erzeugen erlaubt es, deren Risiko zu bewerten und schnell auf Schwachstellen zu reagieren, auch wenn Sie sie nicht gebaut haben.
Bei imaxe.cloud setzen wir auf Nachverfolgbarkeit: Die Software unserer Images zu inventarisieren und zu dokumentieren gehört dazu, sie gut zu bauen.
