Software wird heute selten komplett neu entwickelt. Vielmehr setzen Anbieter auf einen Mix aus eigenem Code, Open Source und kommerziellen Softwarekomponenten. Den vollständigen Inhalt des fertigen Softwaresystems kennen die Auftraggeber in der Regel nicht. Diese mangelnde Transparenz bringt eine Reihe von Problemen aus den Bereichen Security, Compliance und Wartbarkeit mit sich.

Zu deren Beseitigung hat die Softwareindustrie einen Blick über den Tellerrand zur fertigenden Industrie geworfen. Diese setzt schon seit Jahrzehnten in der Produktion auf Stücklisten (englisch: Bill of Materials oder BOM). Stücklisten dienen dazu, Teile eines Produkts zu identifizieren und zu verfolgen. So entstand die Idee einer "Software Bill of Materials", kurz: SBOM.

SBOMs lösen zahlreiche Probleme bei komponentenbasierter Software:

Die Minimalanforderungen an den Inhalt eines SBOM sind in der Executive Order 14028 der amerikanischen National Telecommunications and Information Administration (NTIA) definiert. Jeder SBOM-Typ umfasst mindestens die folgenden Elemente: Name, Version und Anbieter der Softwarekomponente, Lizenz-Informationen und Abhängigkeiten von anderen Softwarekomponenten.

Während bei vielen kommerziellen Produkten aus Wettbewerbs- oder Sicherheitsgründen ein vollständiges SBOM selten veröffentlicht wird, gewähren Open-Source-Projekte sehr oft Einblick in ihre Inhalte. Firefox oder Libreoffice dienen als Modellbeispiele, um das Prinzip eines SBOMs zu verstehen. Auf Plattformen wie Github gibt es zudem Beispiele (wie das CycloneDX-SBOM-Beispiel-Repository), die das Format und den Inhalt eines SBOMs veranschaulichen.

In der EU regelt der Cyber Resilience Act (CRA) seit Anfang 2024 den Einsatz von SBOMs. Er verpflichtet Softwareentwickler und Hardwarehersteller, transparente Sicherheitsmassnahmen zur Nachverfolgbarkeit von Software-Komponenten zu ergreifen. Technische Richtlinien wie die TR-03183-2 des BSI geben zusätzlich formelle und fachliche Vorgaben. Unternehmen haben bis 2027 Zeit, ihre Produkte anzupassen.

Die Schweiz hat derzeit keine spezifischen gesetzlichen Regelungen und Fristen zur Nutzung von SBOMs. Es wird stattdessen empfohlen, sich auf internationale Best Practices zu stützen. Dazu gehören:

Es gibt eine Vielzahl von Tools zur Erstellung und Verwaltung von SBOMs. Zu den bekanntesten gehören kommerziellen Lösungen wie Scribe Security, Mend, Anchore, Snyk und JFrog. Daneben gibt es auch Open-Source-Tools wie Syft, CycloneDX Generator (cdxgen) und Microsoft SBOM Tool. Alle nutzen jeweils die Formate SPDX und CycloneDX.

Eine der grössten Herausforderungen ist die Datenqualität. Ein SBOM ist nur dann nützlich, wenn es alle relevanten Komponenten korrekt erfasst. Fehlerhafte Daten führen schnell zu falschen Sicherheitsbewertungen. Zudem müssen SBOMs regelmässig aktualisiert werden. Bei komplexen Projekten mit vielen Abhängigkeiten wird das schnell aufwendig. Ein weiteres Problem ist die fehlende Standardisierung. Zwar existieren Formate wie SPDX, CycloneDX und SWID, doch eine einheitliche Norm fehlt, was die Interoperabilität erschwert.

Neben diesen technischen und organisatorischen Herausforderungen gibt es auch rechtliche und sicherheitsrelevante Aspekte. Insbesondere gesetzliche Vorgaben wie der EU Cyber Resilience Act und die Executive Order 14028 erfordern die Einführung von SBOMs. Doch die Vielzahl unterschiedlicher Vorschriften macht die Umsetzung kompliziert. Hinzu kommen Sicherheitsbedenken: Die detaillierten Informationen, die in SBOMs offengelegt werden, können bei unzureichendem Datenschutz von Angreifern ausgenutzt werden. Datenschutz und Zugriffskontrollen sind daher unerlässlich, um diese Risiken zu minimieren.

Die Nutzung von SBOMs nimmt in vielen Branchen zu. Etwa 60% der Unternehmen, die kritische Infrastruktur-Software entwickeln oder beschaffen, setzen SBOMs bereits verpflichtend ein. Dazu gehören Systeme, deren Ausfall gravierende Auswirkungen auf Gesellschaft, Wirtschaft und Sicherheit haben. Beispiele hierfür sind:

Um die Sicherheit dieser und weitere kritischer Anwendungen zu erhöhen, wird der Einsatz von SBOMs immer wichtiger.

SBOMs sind heute unerlässlich, um die Transparenz, Sicherheit und Wartbarkeit von Software zu gewährleisten. Sie erhöhen zwar die Aufwände in der Entwicklung und Pflege, doch die verfügbaren Tools zur Unterstützung und Automatisierung machen den Prozess effizienter. Für Unternehmen, die auf kritische Software angewiesen sind, sind SBOMs kein "Nice-to-have", sondern ein "Must-have". Sie helfen, Risiken zu minimieren und gesetzlichen Anforderungen zu entsprechen. Letztlich bilden sie die Grundlage für eine robuste und zukunftssichere (Security-)Software-Architektur.