← Sichere Softwarebereitstellung
SBOM und Dependency Management
Transparenz über Komponenten schaffen – und daraus steuerbare Entscheidungen machen.
Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis von Softwarekomponenten und ihren Beziehungen. Sie schafft Transparenz, aber keine automatische Sicherheit: Erst verlässliche Erzeugung, ausreichende Datenqualität, der Abgleich mit Schwachstelleninformationen und geregelte Verantwortlichkeiten machen sie nutzbar. SBOM und Dependency Management gehören daher in Build-, Freigabe- und Betriebsprozesse – nicht nur in eine einmalige Lieferdokumentation.
Ausgangslage
Eigene Anwendungen enthalten direkte und transitive Open-Source-, Drittanbieter- und interne Komponenten. Ohne belastbaren Überblick bleiben Fragen nach betroffenen Produkten bei einer neuen Schwachstelle manuell, langsam und fehleranfällig. Gleichzeitig entstehen Inventare oft außerhalb des Builds, sind nicht einer konkreten Release-Version zugeordnet oder enthalten unklare Namen und Versionen.
Fachliche Einordnung
Eine SBOM dokumentiert Komponenten eines konkreten Softwareartefakts sowie ihre Lieferkettenbeziehungen. Sie ist kein Schwachstellenscan, kein Herkunftsnachweis und kein Freigabeentscheid. CISA ordnet SBOMs als Baustein der Supply-Chain-Sicherheit ein; SPDX und CycloneDX veröffentlichen ihre Spezifikationen offiziell. Welches Format geeignet ist, folgt aus Empfängern, Toolkette und Anwendungsfall; entscheidend sind eindeutige Kennungen, Versionen, Beziehungen und Aktualität.
Der CRA verlangt in seinem Anwendungsbereich die Identifikation und Dokumentation von Komponenten einschließlich einer SBOM. Daraus folgt weder ein allgemeines Signierungsgebot noch pauschal, dass eine SBOM öffentlich an Kunden bereitzustellen ist. Ob und gegenüber wem Informationen bereitzustellen sind, hängt von Produkt, Rolle und konkreter Pflicht ab und ist rechtlich zu prüfen.
Was Unternehmen konkret klären müssen
- Welche Artefakte erhalten eine SBOM: Quellpaket, Container, Installer oder ausgeliefertes Produkt?
- Wann wird sie automatisiert erzeugt und eindeutig dem Build, Commit und Release zugeordnet?
- Welche Mindestdaten sind verpflichtend und wie werden fehlende oder widersprüchliche Angaben behandelt?
- Wer bewertet Treffer aus CVE-, Hersteller- oder VEX-Informationen nach tatsächlicher Betroffenheit?
- Wie werden Lizenzen, Ausnahmen, Updates und die Bereitstellung an Kunden oder Prüfinstanzen gesteuert?
Datenqualität entscheidet über den Nutzen
Eine nutzbare SBOM ist einem konkreten Release zugeordnet und umfasst direkte wie transitive Abhängigkeiten, eindeutige Kennungen und nachvollziehbare Beziehungen. Zu prüfen sind außerdem Tool- und Runtime-Komponenten, Aktualität sowie Zugriff und Verteilung. PURL oder CPE können bei der Identifikation helfen, sind aber keine universelle Pflicht. Ein VEX (Vulnerability Exploitability eXchange) kann ergänzend festhalten, ob und warum eine bekannte Schwachstelle für ein Produkt tatsächlich betroffen oder nicht betroffen ist.
Von der Anforderung zur Umsetzung
Komponenten transparent halten
Risiko: Unbekannte Abhängigkeiten
Organisatorische Maßnahme: Verantwortliche je Produkt festlegen
Technische Umsetzung: SBOM im Build erzeugen
Möglicher Nachweis: SBOM je Release
Daten nutzbar machen
Risiko: Falschzuordnung von CVEs
Organisatorische Maßnahme: Qualitätskriterien und Ausnahmeprozess
Technische Umsetzung: Kennungen, Hashes und Beziehungen prüfen
Möglicher Nachweis: Qualitätsreport
Schwachstellen behandeln
Risiko: Untätige oder falsche Reaktion
Organisatorische Maßnahme: Triage, Fristen und Eskalation definieren
Technische Umsetzung: Abgleich mit Advisories und VEX
Möglicher Nachweis: Ticket- und Entscheidungsverlauf
Pflege sichern
Risiko: Veraltetes Inventar
Organisatorische Maßnahme: Release- und Betriebsprozess verbinden
Technische Umsetzung: Neu erzeugen bei jedem Release
Möglicher Nachweis: Versionshistorie
Vorgehen mit ADIUMENTO
ADIUMENTO kann im Rahmen von Beratung und Umsetzung dabei unterstützen, SBOM- und Dependency-Prozesse zu strukturieren und mit vorhandenen Build-/Betriebsabläufen zu verbinden. Eine eigenständige Zertifizierungsleistung oder Konformitätsgarantie ist damit nicht verbunden. Technologie- und Leistungsbezüge finden Sie auf Technologien, Leistungen und Lösungen.
Typische Arbeitsergebnisse
- SBOM-Zielbild mit Artefakt-, Format- und Empfängermodell;
- Qualitätsregeln sowie Verantwortlichkeiten für Abhängigkeiten;
- Prozess für Schwachstellenbewertung, Remediation und Ausnahmen;
- Roadmap für automatisierte Erzeugung, Ablage und Betriebsübergabe.
Grenzen und Abhängigkeiten
Eine vollständige SBOM beweist weder, dass ein Artefakt schadfrei ist, noch dass jede gemeldete Schwachstelle ausnutzbar ist. Scanner, Datenquellen, Paketmanager und proprietäre Bestandteile begrenzen die Aussagekraft. Signaturen können Integrität und Herkunft eines Artefakts unterstützen, ersetzen aber weder SBOM noch Schadcodeprüfung; dazu siehe Code Signing und Artifact Signing. ADIUMENTO erbringt keine Rechtsberatung und keine Konformitätsgarantie.
Weiterführende offizielle Quellen
- CISA: SBOM – CISA
- SPDX-Spezifikationen – SPDX
- CycloneDX-Spezifikation – OWASP CycloneDX
- Verordnung (EU) 2024/2847 – EUR-Lex
Orientierung
Häufige Fragen
Reicht eine SBOM für ein sicheres Release?
Nein. Sie zeigt, welche Komponenten dokumentiert wurden. Sichere Releases benötigen zusätzlich sichere Build- und Freigabeprozesse, Schwachstellenmanagement, Tests und einen geregelten Betrieb.
Sollten wir CycloneDX oder SPDX verwenden?
Beide sind etablierte, maschinenlesbare Formate. Die Wahl richtet sich nach Toolunterstützung und Austauschpartnern. Ein Pilot mit repräsentativen Artefakten zeigt, ob Beziehungen, Kennungen und Übergaben in der eigenen Kette funktionieren.
Wie hilft eine SBOM bei Incidents?
Sie beschleunigt die Ermittlung, welche ausgelieferten Versionen eine betroffene Komponente enthalten könnten. Die tatsächliche Betroffenheit und Priorität müssen dennoch technisch bewertet und im Incident-Prozess bearbeitet werden; siehe Monitoring und Incident Response.
Nächster sinnvoller Schritt
Lassen Sie ein repräsentatives Produkt und seinen Release-Prozess abgrenzen. Daraus lassen sich Datenlücken, Automatisierungspotenziale und ein belastbarer Einstieg für Governance und Betrieb ableiten.