SBOM-Beratung: Umsetzung der Software Bill of Materials
Eine Software Bill of Materials (SBOM) ist ein strukturiertes Verzeichnis der Softwarekomponenten eines Produkts, einschließlich Drittanbieter- und Open-Source-Abhängigkeiten. Sie hat sich von einer Best Practice zu einer regulatorischen Erwartung entwickelt: Der Cyber Resilience Act verpflichtet Hersteller, eine SBOM zu führen, die die Abhängigkeiten der obersten Ebene abdeckt, und auch OEMs fordern sie zunehmend als Teil des Lieferantennachweises. PRAETORIO unterstützt Hersteller eingebetteter und industrieller Systeme bei der Einführung der SBOM-Erstellung, der Wahl eines geeigneten Formats und dem Aufbau eines Prozesses, der die SBOM aktuell hält, während sich die Produkte weiterentwickeln.
Eine SBOM ist nur dann nützlich, wenn sie korrekt und gepflegt ist: ein einmaliger Export, der nach dem nächsten Firmware-Release veraltet, erfüllt den Sinn der Anforderung nicht, auch wenn er auf dem Papier gut aussieht.
Sprechen Sie mit uns über SBOM für Ihre ProduktlinieWas eine SBOM ist
Eine Software Bill of Materials ist ein formales, maschinenlesbares Verzeichnis der Softwarekomponenten eines Produkts: direkte Abhängigkeiten, transitive Abhängigkeiten, deren Versionen, Lizenzen und Herkunft. Bei eingebetteten und industriellen Produkten umfasst dies typischerweise Firmware, Betriebssystemkomponenten, Drittanbieterbibliotheken und Open-Source-Pakete, die in den Build einfließen.
Zwei SBOM-Formate sind gebräuchlich und beide werden von zahlreichen Tools unterstützt: SPDX (Software Package Data Exchange, standardisiert als ISO/IEC 5962) und CycloneDX, entwickelt unter OWASP mit einem ursprünglich stärkeren Fokus auf Sicherheitsanwendungsfälle. Regulatorische und kundenseitige Anforderungen akzeptieren in der Regel beide Formate, solange sie maschinenlesbar und vollständig genug sind, um Komponenten und Versionen zu identifizieren.
Eine SBOM unterstützt mehrere nachgelagerte Anwendungen über die reine Bestandsaufnahme hinaus: Schwachstellenmanagement (Abgleich von Komponenten mit veröffentlichten CVEs), Lizenz-Compliance und die Bewertung von Lieferkettenrisiken.
Warum eine SBOM wichtig ist
Es ist mittlerweile eine regulatorische Anforderung, nicht nur gute Praxis. Zu den grundlegenden Anforderungen des Cyber Resilience Act gehört die Pflege einer SBOM, die mindestens die Abhängigkeiten der obersten Ebene abdeckt, in einem gängigen, maschinenlesbaren Format, als Teil der technischen Dokumentation zum Nachweis der Konformität.
Sie ist die Grundlage für die Reaktion auf Schwachstellen. Wird eine neue CVE für eine weit verbreitete Bibliothek veröffentlicht, ermöglicht eine korrekte SBOM einem Hersteller, schnell zu bestimmen, welche Produkte betroffen sind: ohne sie wird dies zu einer manuellen, fehleranfälligen Suche.
Kunden und OEMs verlangen sie zunehmend. Lieferantenqualifizierungs- und Auditprozesse führen SBOM zunehmend als Standardnachweis ein, unabhängig von einem spezifischen regulatorischen Mandat.
Eingebettete und industrielle Produkte haben ein schwierigeres SBOM-Problem als typische Software. Cross-kompilierte Toolchains, eingebetteter Code, Board Support Packages und Firmware-Blobs von Halbleiterherstellern erschweren die Nachverfolgung von Abhängigkeiten gegenüber einer typischen, mit einem modernen Paketmanager erstellten Anwendung: generisches SBOM-Tooling muss dafür oft angepasst werden.
Eine veraltete SBOM ist eine Belastung, kein Vorteil. Eine SBOM, die bei Produktänderungen nicht neu erzeugt wird, erzeugt ein falsches Sicherheitsgefühl und kann die Reaktion auf Schwachstellen in die falsche Richtung lenken.
Unser Vorgehen
PRAETORIO setzt SBOM als nachhaltigen Engineering-Prozess um, nicht als einmalige Leistung:
- Build- und Abhängigkeitsinventur: Abbildung des tatsächlichen Build-Prozesses, der Toolchains und der Abhängigkeitsquellen (Paketmanager, eingebetteter Code, Board Support Packages, Drittanbieter-Binärdateien), um zu verstehen, was eine SBOM erfassen muss.
- Formatauswahl: Entscheidung zwischen SPDX und CycloneDX (oder Erzeugung beider) auf Basis von nachgelagertem Tooling, Kundenanforderungen und regulatorischen Erwartungen.
- Auswahl und Integration des Tooling: Auswahl geeigneter SBOM-Erstellungstools für das jeweilige Build-System und Integration in die Build- oder CI-Pipeline, sodass die SBOM-Erstellung automatisch statt manuell erfolgt.
- Erstellung der Basis-SBOM: Erstellung einer initialen, korrekten SBOM für die aktuelle Produktbasis, wobei Lücken geschlossen werden, in denen automatisiertes Tooling bestimmte Abhängigkeiten nicht erkennen kann (z. B. eingebettete oder reine Binärkomponenten).
- Integration des Schwachstellenabgleichs: Anbindung der SBOM an eine Schwachstellendatenbank oder ein Scan-Tool, damit neu veröffentlichte CVEs mit dem Komponentenverzeichnis abgeglichen werden können.
- Definition des Pflegeprozesses: Festlegung, wie die SBOM im Rahmen des Release-Prozesses neu erzeugt und überprüft wird, damit sie mit jeder Produktversion aktuell bleibt.
- Dokumentations- und Lieferformat: Aufbereitung der SBOM passend für die jeweilige Zielgruppe: regulatorische technische Dokumentation, Kundenlieferung oder internes Schwachstellenmanagement.
Leistungen
- Bericht zur Build- und Abhängigkeitsinventur
- Empfehlung zum SBOM-Format (SPDX / CycloneDX)
- Integriertes SBOM-Erstellungstooling in der Build- oder CI-Pipeline
- Basis-SBOM für das aktuelle Produkt-Release
- Einrichtung des Schwachstellenabgleichs anhand der SBOM
- Dokumentation des SBOM-Pflegeprozesses
Wie PRAETORIO Ihr Team unterstützen kann
- Erstmalige SBOM-Einführung, Aufbau von Tooling und Prozess für ein Produkt oder eine Produktlinie, die bisher noch keine SBOM erstellt hat.
- Integration von SBOM-Tooling, Ergänzung einer bestehenden Build- oder CI/CD-Pipeline um automatisierte SBOM-Erstellung.
- Schließen von Lücken bei eingebetteten Builds, zur Behandlung von eingebettetem Code, cross-kompilierten Toolchains und reinen Binärkomponenten, die generische SBOM-Tools häufig übersehen.
- Integration von SBOM in das Schwachstellenmanagement, Anbindung der SBOM-Ausgabe an einen Schwachstellen-Scan- oder Abgleichprozess.
- Formatmigration oder Erzeugung mehrerer Formate, Unterstützung von Herstellern, die sowohl SPDX als auch CycloneDX für unterschiedliche Kunden oder regulatorische Kontexte benötigen.
- Gestaltung des SBOM-Pflegeprozesses, um sicherzustellen, dass die SBOM im Rahmen des normalen Release-Prozesses neu erzeugt und überprüft wird, statt als einmaliges Artefakt behandelt zu werden.
Typische Anwendungsfälle
- Ein Hersteller, der SBOM erstmals einführt, um die Anforderungen an die technische Dokumentation des Cyber Resilience Act zu erfüllen.
- Ein Team für eingebettete Produkte, dessen bestehendes SBOM-Tooling (für typische Anwendungssoftware konzipiert) cross-kompilierte Firmware oder eingebetteten Code nicht korrekt verarbeitet.
- Ein Zulieferer, der von einem OEM- oder Tier-1-Kunden aufgefordert wird, eine SBOM als Teil einer Komponenten- oder Softwarelieferung bereitzustellen.
- Eine Organisation, die einmalig eine SBOM als Einzelmaßnahme erstellt hat und die Neuerstellung nun zu einem festen Bestandteil ihres Standard-Release-Prozesses machen muss.
- Ein Unternehmen, das seine SBOM mit einem Schwachstellenmanagementprozess verknüpfen muss, um schneller auf neu veröffentlichte CVEs bei Drittanbieterkomponenten reagieren zu können.
- Ein Hersteller, der zwischen SPDX und CycloneDX entscheiden muss oder beide für unterschiedliche nachgelagerte Anforderungen benötigt.
Warum PRAETORIO
- Der Hintergrund in eingebetteten Systemen bedeutet, dass wir die spezifischen SBOM-Herausforderungen von cross-kompilierten Toolchains, Board Support Packages und binären Komponenten von Zulieferern verstehen: nicht nur typische Abhängigkeitsbäume von Anwendungssoftware.
- Mehr als 15 Jahre Erfahrung in der Automobil- und eingebetteten Softwareentwicklung, einschließlich AUTOSAR-basierter Systeme, in denen Abhängigkeits- und Komponentenverfolgung bereits eine Kerndisziplin ist.
- Praktische Integrationserfahrung bei der Anbindung der SBOM-Erstellung an Build-Pipelines und Schwachstellenmanagementprozesse, nicht nur die Erstellung eines einmaligen Exports.
- Engineering-orientierte Umsetzung: Die SBOM-Implementierung ist darauf ausgelegt, das nächste Produkt-Release zu überstehen, nicht nur das nächste Audit.
Verwandte Leistungen
- Cyber Resilience Act Beratung: der regulatorische Treiber für SBOM-Anforderungen
- CRA-Compliance: SBOM als Teil des vollständigen Compliance-Programms
- Schwachstellenmanagement: Einsatz der SBOM für die Reaktion auf Schwachstellen
- PSIRT: Incident Response unterstützt durch ein genaues Komponentenverzeichnis
- Cybersecurity Engineering: die gesamte Cybersecurity-Engineering-Praxis
- Embedded Cybersecurity: umfassenderes Cybersecurity-Engineering für eingebettete und Automotive-Systeme
FAQ
Was ist eine Software Bill of Materials (SBOM)?
Eine SBOM ist ein formales, maschinenlesbares Verzeichnis der Softwarekomponenten eines Produkts, einschließlich direkter und transitiver Abhängigkeiten, deren Versionen, Lizenzen und Herkunft. Sie unterstützt Schwachstellenmanagement, Lizenz-Compliance und die regulatorische technische Dokumentation.
Welches SBOM-Format sollte ich verwenden, SPDX oder CycloneDX?
Beide sind weit verbreitete, maschinenlesbare Formate. SPDX (standardisiert als ISO/IEC 5962) hat eine breitere allgemeine Verbreitung, während CycloneDX ursprünglich mit einem stärkeren Fokus auf Sicherheitsanwendungsfälle entwickelt wurde. Die richtige Wahl hängt oft von Kunden- oder regulatorischen Anforderungen sowie vorhandenem Tooling ab; manche Organisationen erzeugen beide.
Verlangt der Cyber Resilience Act eine SBOM?
Ja. Zu den grundlegenden Anforderungen der CRA gehört die Pflege einer Software Bill of Materials, die mindestens die Abhängigkeiten der obersten Ebene eines Produkts abdeckt, in einem gängigen, maschinenlesbaren Format, als Teil der technischen Dokumentation zum Nachweis der Konformität.
Warum ist die SBOM-Erstellung für eingebettete und industrielle Produkte schwieriger?
Eingebettete Builds umfassen häufig cross-kompilierte Toolchains, direkt in den Quellcodebaum kopierten Code, Board Support Packages und reine Binärkomponenten von Halbleiterherstellern. Generisches SBOM-Tooling, das für typische Abhängigkeitsmanager von Anwendungssoftware entwickelt wurde, kann diese Komponenten oft ohne Anpassung nicht erkennen.
Wie oft sollte eine SBOM neu erzeugt werden?
Idealerweise bei jedem Release: Eine an eine bestimmte Produktversion gebundene SBOM ist nur für diese Version korrekt. Die Integration der SBOM-Erstellung in die Build- oder CI-Pipeline ist der zuverlässigste Weg, sie aktuell zu halten, ohne sich darauf zu verlassen, dass jemand an die manuelle Neuerstellung denkt.
Kann eine SBOM bei der Reaktion auf Schwachstellen helfen?
Ja. Wird eine neue Schwachstelle für eine weit verbreitete Bibliothek veröffentlicht, ermöglicht eine korrekte SBOM einem Hersteller, schnell zu bestimmen, welche Produkte die betroffene Komponente und Version enthalten, statt Build-Konfigurationen und Abhängigkeitslisten manuell zu durchsuchen.
Kann PRAETORIO helfen, wenn wir bereits eine unvollständige oder veraltete SBOM haben?
Ja. Projekte starten häufig mit einer bestehenden, aber unvollständigen oder veralteten SBOM und konzentrieren sich darauf, Lücken zu schließen (insbesondere bei eingebetteten oder binären Komponenten), die Erstellung in den Release-Prozess zu integrieren und die SBOM mit dem Schwachstellenmanagement zu verknüpfen.
Müssen Sie Ihren SBOM-Prozess einführen oder weiterentwickeln?
PRAETORIO kann Ihr Team von der ersten Abhängigkeitskartierung über die Tooling-Integration bis hin zur laufenden SBOM-Pflege unterstützen. Kontaktieren Sie uns, um die SBOM-Anforderungen Ihres Produkts zu besprechen.
Kontakt aufnehmen