SBOM und der Cyber Resilience Act
- Sarah Berger
- Regulatorische Anforderungen
- 9. April 2025
Inhaltsverzeichnis
Der Cyber Resilience Act ist die erste europäische Verordnung, die ein Mindestmaß an Cybersicherheit für alle vernetzten Produkte festlegt, die auf dem EU-Markt erhältlich sind. Damit sind nicht nur IoT-Produkte gemeint, sondern auch SaaS-Produkte oder Smartphone Apps. Das bedeutet, dass sich so gut wie alle Softwarehersteller mit dem Thema Cyber Resilience Act beschäftigen müssen. Der Cyber Resilience Act hat verschiedene Anforderungen, unter anderem die Erstellung und Archivierung einer SBOM für das jeweilige Softwareprodukt.
In diesem Blogartikel möchte ich aufzeigen, was der Cyber Resilience Act zum Thema SBOM konkret verlangt und warum es sich lohnt, sich bereits jetzt mit dem Thema zu beschäftigen.
Was ist eine SBOM – und warum ist sie so wichtig?
Eine SBOM kann als digitale Stückliste für Softwarekomponenten bezeichnet werden. Der Begriff Stückliste ist bereits seit langem aus der Hardwareproduktentwicklung bekannt. Die SBOM wird von mir häufig auch als Zutatenliste bezeichnet, wie du es bereits vom Lebensmitteleinkauf gut kennst. Es geht darum, dem Kunden oder auch Endverbraucher aufzuzeigen, welche Softwarekomponenten bei der Entwicklung der Software genutzt worden sind. Das gilt für proprietäre Komponenten sowie vor allem für Open-Source-Software Komponenten.
Inhalt einer SBOM
Eine SBOM beschreibt innerhalb des Kontexts einer Komponente (das kann auch ein Produkt sein), welche Softwarekomponenten genutzt worden sind und wie diese in Abhängigkeit zueinander stehen. Das bedeutet, dass die SBOM weitaus mehr Komponenten enthält, als du als Softwareentwickler vielleicht auf den ersten Blick denkst. Das liegt daran, dass nicht nur die direkten Abhängigkeiten in der SBOM enthalten sind, sondern auch die transitiven. Da diese jedoch zwingend erforderlich sind, um die direkten Komponenten nutzen zu können, sind sie ebenfalls Teil des Produktes.
Innerhalb der SBOM werden dann die verwendeten Komponenten detailliert beschrieben. So finden sich häufig der Name, die Version, die Download-URL, die Lizenz, ein Hash-Wert, die PURL oder CPE und auch das Copyright zu der entsprechenden Komponente in der SBOM. Die beiden SBOM-Standards SPDX und CycloneDX erlauben jedoch noch viel mehr Attribute zur Beschreibung. Hierbei muss bedacht werden, dass diese Informationen ermittelt, dokumentiert und gepflegt werden müssen. Da die SBOM hoffentlich nicht manuell, sondern automatisiert erstellt wird, muss der jeweilige Scanner erstmal alle Informationen zu der jeweiligen Komponente haben, um diese zu dokumentieren.
Aus der Praxis gesprochen kann das sehr schwer sein. Während der Name, die Version und die PURL noch leicht zu finden sind, ist das Auffinden des Copyrights oder der Autoren schon schwieriger und muss teilweise manuell kuratiert werden.
Warum der CRA die Sichtbarkeit von Drittanbieter-Komponenten fordert
Der Cyber Resilience Act verfolgt das Ziel, das Sicherheitsniveau von digitalen Produkten zu erhöhen. Das schützt vor allem Verbraucher, die aktuell keine Transparenz über die Sicherheit eines entsprechenden Produktes haben. Es schützt jedoch auch die Unternehmen, die bereits heute durch die Zunahme von diversen Sicherheitsangriffen gefährdet sind.
Durch die vermehrte Nutzung von Drittanbieter-Komponenten und damit in der Regel Open-Source-Komponenten erhöht sich auch die Anzahl an potenziellen Schwachstellen. Diese Schwachstellen können bereits vor Produktrelease bekannt sein oder auch nach Produktrelease erst auftreten. Durch eine gut gepflegte und aktuelle SBOM haben die Unternehmen, aber auch theoretisch die Endverbraucher die Möglichkeit zu analysieren, ob es neue Schwachstellen für die genutzten Softwarekomponenten gibt. Täglich werden die Schwachstellendatenbanken diesbezüglich aktualisiert. In der Praxis wird das wohl kaum ein Endverbraucher tun.
Die Unternehmen hingegen haben die Möglichkeit, über die SBOM und ein entsprechendes SCA-Tool auch zugekaufte Software hinsichtlich Schwachstellen zu beobachten, und können schneller reagieren als vorher.
CRA Gap-Analyse
Gemeinsam mit Dir analysieren wir systematisch, wo Dein Unternehmen heute steht. Wir gleichen bestehende Prozesse, technische Maßnahmen und Dokumentationen mit den Anforderungen des Cyber Resilience Act ab. So erkennst Du sofort, welche Pflichten bereits erfüllt sind und an welchen Stellen Du nachbessern musst.
Was der Cyber Resilience Act zur SBOM verlangt
Der Cyber Resilience Act sagt sehr klar und eindeutig, dass eine SBOM für jede Softwareversion verpflichtend zu erstellen ist. Die Verordnung gibt auch an, welches Minimum an Information in der SBOM zu finden sein muss. Ein sehr interessanter Aspekt ist, dass es explizit verboten ist Informationen über die jeweiligen Schwachstellen der gefundenen Komponenten in der SBOM zu dokumentieren. Dies erlaubt der SBOM CycloneDX Standard und es wird auch je nach SCA Tool bei der SBOM hinzugefügt. Die Trennung zwischen SBOM und Schwachstelleninformationen, den sogenannten Vulnerability Exploitability eXchange (VEX) wird damit begründet, dass die Informationen innerhalb der SBOM statisch sind und Informationen zu Schwachstellen dynamisch.
Formate und Spezifikationen
Eine SBOM kann in einem JSON- oder XML-Format vorliegen. Es kann entweder der Spezifikation CycloneDX mit der Version 1.5 oder höher oder dem Software Package Data eXchange (SPDX) mit der Version 2.2.1 oder höher vorliegen. Die meisten SCA-Tools unterstützen beide Formate. Die SPDX-Spezifikation hat ihren Ursprung bei der Linux Foundation und legt den Schwerpunkt auf Lizenz- und Compliance-Informationen. Sie ist sehr ausführlich und gibt sehr viele Möglichkeiten Lizenzinformationen konkret abzubilden. Es gibt ebenfalls die Möglichkeit, zwischen dynamisch und statisch gelinkten Komponenten zu unterscheiden, was vor allem im Linuxbereich notwendig ist. Die CycloneDX-Spezifikation stammt ursprünglich vom OWASP. Die Spezifikation ist schlanker gestaltet und hat den Fokus auf Security-Analysen wie CVE-Tracking und Schwachstellenmanagement.
In der Praxis wird CycloneDX oft im DevSecOps-Bereich bevorzugt, während SPDX bei dem Thema Lizenzmanagement und Open Source-Compliance dominiert. Es ist allerdings möglich die Standardinformationen mit beiden Standards abzubilden. Aus meinen praktischen Erfahrungen heraus empfehle ich es, sich für einen Standard zu entscheiden und diesen intern als auch extern vorzugeben. Die wichtigsten Informationen können von beiden Spezifikationen abgebildet werden.
Notwendige Informationen in der SBOM
Bei den notwendigen Informationen wird zwischen der SBOM selbst und zwischen den jeweiligen Komponenten unterschieden. Die untenstehende Tabelle gibt die verpflichtenden Informationen an:
Verpflichtende Datenfelder
| Datenfeld | Beschreibung |
|---|---|
| SBOM Creator | E-Mail oder URL des Erstellers des SBOM (z. B. Projektseite oder Unternehmen). |
| Timestamp | Zeitpunkt der SBOM-Erstellung, im Format gemäß RFC 3339. |
| Component Creator | E-Mail oder URL des Erstellers oder Betreuers der jeweiligen Komponente. |
| Component Name | Vom Ersteller vergebener Name oder – falls nicht vorhanden – der Dateiname. |
| Component Version | Version der Komponente (bevorzugt SemVer oder CalVer), sonst Erstellungsdatum. |
| Filename | Der tatsächliche Dateiname der Komponente (nicht der Pfad). |
| Dependencies | Liste aller Komponenten, von denen diese Komponente direkt abhängt. |
| Associated Licenses | Lizenz(en), unter denen die Komponente verwendet werden darf. |
| Hash Value | Kryptographisch sicherer SHA-512-Hash der bereitstellbaren (deployable) Datei. |
| Executable Property | Gibt an, ob die Komponente ausführbar ist (executable oder non-executable). |
| Archive Property | Gibt an, ob es sich um ein Archiv handelt (archive oder no archive). |
| Structured Property | Gibt an, ob die Komponente strukturiert ist (structured oder unstructured). |
Da ich selbst sehr viel mit CycloneDX arbeite, habe ich ein Mapping erstellt zwischen den geforderten Datenfeldern aus dem CRA und den entsprechenden Feldern in der CycloneDX-Spezifikationen.
Verpflichtende Datenfelder gemappt auf CycloneDX
| BSI Data Field | Beschreibung (Deutsch) | CycloneDX Field | Hinweise |
|---|---|---|---|
| Creator of the SBOM | Kontaktinformationen des Erstellers des SBOM (E-Mail oder URL). | metadata.tools / author | Erfasst das Tool oder die Person, die das SBOM erstellt hat. |
| Timestamp | Datum und Uhrzeit der SBOM-Erstellung (z. B. gemäß RFC 3339). | metadata.timestamp | Vollständig unterstützt. |
| Component Creator | Kontaktinformationen des Erstellers der Komponente. | author | Repräsentiert den Autor der Komponente. |
| Component Name | Vom Ersteller vergebener Name der Komponente. | name | Vollständig unterstützt. |
| Component Version | Versionskennung (z. B. semantische Versionierung). | version | Vollständig unterstützt. |
| Filename | Tatsächlicher Dateiname der Komponente. | name (kontextabhängig) | Kann über name erfasst werden, wenn relevant. |
| Dependencies | Liste aller Komponenten, von denen diese Komponente direkt abhängt. | dependencies | CycloneDX unterstützt hierarchische Abhängigkeitsbeziehungen vollständig. |
| Associated Licenses | Anwendbare Lizenzbedingungen für die Komponente. | licenses | Detaillierte Lizenzangaben möglich. |
| Hash Value | Kryptografischer Hash (z. B. SHA-512) der bereitstellbaren Komponente. | hashes | Vollständig unterstützt zur Integritätsprüfung. |
| Executable Property | Gibt an, ob die Komponente ausführbar ist. | type | Kann als application markiert werden. |
| Archive Property | Gibt an, ob die Komponente ein Archiv ist. | type | Das Feld type kann Archivstatus widerspiegeln (z. B. file, library). |
| Structured Property | Gibt an, ob die Komponente strukturiert ist (z. B. JSON, XML). | type | type kann strukturierte Formate reflektieren, sofern anwendbar. |
| Component Description | Textbeschreibung der Komponente. | description | Optional, aber unterstützt für mehr Klarheit. |
| Supplier Information | Informationen über den Lieferanten oder Herausgeber der Komponente. | supplier | Wird im Feld supplier der Komponente erfasst. |
| Release Notes | Informationen zu Änderungen oder Updates der Komponente. | releaseNotes | Optional, aber unterstützt zur besseren Dokumentation. |
| External References | Verweise auf externe Ressourcen zur Komponente. | externalReferences | Vollständig unterstützt für weiterführende Informationen. |
Der Standard empfiehlt noch eine Reihe an weiteren Informationen, wenn diese Daten vorhanden sind. Diese Informationen erhöhen die Transparenz und die Rückverfolgbarkeit der genutzten Komponenten. Anbei die Tabelle mit den zusätzlichen Informationen, die empfohlen jedoch nicht verpflichtend sind:
| Datenfeld | Beschreibung |
|---|---|
| SBOM URI | Eindeutiger URI des SBOMs zur Referenzierung (z. B. für automatisierte Tools). |
| Source Code URI | URI zum Quellcode der Komponente oder Repository (z. B. GitHub-Link). |
| URI of the deployable form | Direktlink zur bereitstellbaren (deploybaren) Version der Komponente. |
| Other unique identifiers | Weitere eindeutige IDs (z. B. CPE, purl), hilfreich für CVE- und Lizenzabgleich. |
| Concluded Licenses | Lizenzen, die vom Produktanbieter tatsächlich gewählt/genutzt werden. |
Lizenzinformationen
Wie bereits in der Tabelle erwähnt gibt der Cyber Resilience Act vor, das die entsprechenden Lizenzen für die Komponenten angegeben werden müssen. Dabei ist zu beachten, dass die Lizenzen mit den standardisierten SPDX-Lizenzerkennungen oder gültigen SPDX-Lizenzausdrücken angegeben werden. Das ist wichtig, um eine automatisierte Weiterverarbeitung zu gewährleisten, aber auch um die Kommunikationen zwischen den verschiedenen Parteien (intern oder extern) zu vereinfachen und standardisieren. Falls keine passende SPDX-Kennung möglich ist, dürfen alternative Quellen wie die ScanCode License DB genutzt werden (z. B. LicenseRef-scancode-). Kombinierte Lizenzen, Optionen oder auch Ausnahmen müssen mit den SPDX-Operationen AND, OR, oder WITH dargestellt werden.
Fazit
Der Cyber Resilience Act ist zwar bereits in Kraft getreten, allerdings haben die Unternehmen noch teilweise bis 2027 Zeit, die Anforderungen komplett umzusetzen. Das klingt nach einer langen Zeit, ist es aber nicht! Die Erstellung, Verwaltung und Archivierung einer SBOM sollte bereits jetzt im Unternehmen angestoßen werden. Noch dazu solltest du mit deinen Softwarelieferanten besprechen (am besten vertraglich), dass zum Liefergegenstand zukünftig auch eine SBOM gehört, inklusive der oben genannten Datenfelder. Eine SBOM zu erstellen ist erstmal keine große Arbeit. Jedoch ist für ein gewisses Maß an Datenqualität und Vollständigkeit leider noch einiges an oft manueller Arbeit notwendig. Aber es lohnt sich! Ganz unabhängig vom Cyber Resilience Act kann eine SBOM die Möglichkeit geben mehr Transparenz zu haben. Diese Transparenz sorgt für mehr echte Softwaresicherheit und Einhaltung von Lizenzanforderungen.
Solltest du weitere Fragen zum Thema SBOM oder Cyber Resilience Act, kannst du dich gerne bei uns melden.
Du möchtest mehr zum Thema erfahren?
Vereinbare einen kostenlosen Gesprächstermin mit uns oder sende uns deine Anfrage über unser Kontaktformular.
