Publiziert:

SBOM (Software Bill of Materials)

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Inventarliste aller Komponenten, Bibliotheken und Abhängigkeiten einer Software, inklusive ihrer Versionen und Lizenzen. Sie ist das Fundament der Supply-Chain-Security: Nur wer weiss, was in seiner Software steckt, kann bekannte Schwachstellen (CVEs) gezielt beheben.

Ohne SBOM ist die eigene Angriffsfläche unbekannt. Das Log4Shell-Ereignis 2021 hat vielen Unternehmen schmerzhaft gezeigt, wie viele ihrer Systeme eine bestimmte Bibliothek enthielten, ohne dass irgendjemand davon wusste.

Was eine SBOM enthält

  • Komponenten: Alle direkten und transitiven Abhängigkeiten (Libraries, Frameworks, Packages).
  • Versionen: Exakte Versionsnummern für Vulnerability-Matching.
  • Lizenzen: SPDX-Lizenzkennzeichnungen für Compliance-Checks.
  • Herkunft (Provenance): Woher kommt eine Komponente? Welchem Source-Repo entspricht sie?
  • Hashes: Kryptografische Prüfsummen zur Integritätssicherung.

Formate und Standards

  • SPDX: ISO/IEC 5962, das standardisierte Format für SBOMs. spdx.dev
  • CycloneDX: Weitverbreitetes, sicherheitsorientiertes Format. cyclonedx.org
  • SWID Tags: Software-Identifikations-Tags nach ISO/IEC 19770-2, im Unternehmensumfeld verbreitet.

Generierung und Integration

  1. Build-Zeit-Generierung: Tools wie Syft, cdxgen oder Trivy erzeugen SBOMs automatisch im CI/CD-Prozess.
  2. Dependency-Tracking: Die SBOM wird bei jedem Build aktualisiert und im Artefakt-Repository gespeichert.
  3. Vulnerability-Scanning: Die SBOM wird gegen CVE-Datenbanken (NVD, OSV) gematcht.
  4. License-Compliance: Automatische Prüfung auf Lizenz-Konflikte (zum Beispiel GPL in proprietären Projekten).

Der Fokus: Reaktionsfähigkeit bei Zero-Days

Wenn eine neue kritische Schwachstelle bekannt wird, kann die SBOM in Minuten beantworten, welche Systeme betroffen sind.

Austausch über Organisationsgrenzen hinweg

Eine SBOM entsteht nicht nur intern. Sie wird zunehmend zwischen Organisationen ausgetauscht, weil Software heute aus zugekauften und quelloffenen Bausteinen zusammengesetzt ist.

  • Beschaffung: Auftraggeber fordern von Lieferanten eine SBOM, um vor dem Betrieb zu prüfen, welche Komponenten in einer zugekauften Software stecken. In sicherheitskritischen und öffentlichen Ausschreibungen ist dieser Transparenznachweis oft verpflichtend.
  • Technische Prüfung: Bei Übernahmen und Audits macht eine SBOM die technologische Qualität und das Schwachstellen-Risiko einer fremden Codebasis sichtbar, ohne dass der Quellcode offengelegt werden muss.
  • Laufendes Monitoring: Eine empfangene SBOM wird in eine Management-Plattform importiert und weiter gegen neue CVEs geprüft. Das bleibt wichtig, weil Schwachstellen oft erst Jahre nach der Auslieferung bekannt werden.

Regulatorische Treiber

SBOMs sind vielerorts nicht mehr freiwillig, sondern vorgeschrieben. Die CISA Minimum Elements legen fest, welche Angaben eine SBOM mindestens enthalten muss. Die US Executive Order 14028 verlangt eine SBOM für Software, die an US-Bundesbehörden geliefert wird. Der EU Cyber Resilience Act macht eine Stückliste der Komponenten zur Pflicht für vernetzte Produkte auf dem europäischen Markt.

Quellen