SBOM für Firmware und Embedded Software in DevSecOps

Software-Stücklisten (SBOM) spielen eine immer wichtigere Rolle für die eingebettete Sicherheit. Bei Firmware und vernetzten Geräten bieten sie Ihnen Einblick in Komponenten, die oft nicht überprüft werden. In diesem Blog erfahren Sie mehr über die Herausforderungen von Firmware-SBOMs in den Bereichen Entwicklung, Sicherheit und Betrieb (DevSecOps) und wie Sie diese sicher angehen können.

Wichtige Erkenntnisse

• Firmware und eingebettete SBOMs sind schwieriger zu erstellen als herkömmliche Software-Inventare, da Teams häufig keinen Zugriff auf den Quellcode haben und in eng gekoppelten Hardwareumgebungen auf undokumentierte Komponenten von Drittanbietern angewiesen sind.
• DevSecOps-Teams benötigen sowohl SBOMs zur Erstellungszeit als auch zur Binärcodeanalyse, um Sichtbarkeitslücken bei Legacy-Geräten, Hersteller-Firmware und Multi-Toolchain-Ökosystemen zu schließen.
• SBOMs, die während der Build-Phase erstellt werden, bieten hohe Präzision und umfangreiche Lizenzmetadaten, setzen jedoch die Kontrolle über die Build-Umgebung voraus und können keine externe oder nach der Bereitstellung installierte Firmware abdecken.
• Die binärbasierte SBOM-Generierung ermöglicht die Überprüfung der Lieferkette, die Inspektion von Feldgeräten sowie die Reaktion auf Vorfälle, auch wenn Quellartefakte nicht verfügbar sind.
• Die Integration von SBOMs in CI/CD-Sicherheitsgates hilft dabei, unsichere Firmware-Builds zu blockieren, Richtlinienverstöße zu kennzeichnen und die Audit-Bereitschaft für Standards wie CRA, NIS2, SPDX und CycloneDX aufrechtzuerhalten.
• Automatisierung, einschließlich automatisierter Workflows für das Schwachstellenmanagement, ist unerlässlich, um SBOM-Daten mit schnellen Firmware-Release-Zyklen in Einklang zu halten und sicherzustellen, dass neu bekannt gewordene CVEs kontinuierlich mit eingebetteten Komponenten verknüpft werden.

Die häufigsten Herausforderungen bei Firmware-SBOMs in DevSecOps

Firmware unterscheidet sich von herkömmlicher Software. Man hat nicht immer Zugriff auf den Quellcode, und Komponenten sind oft nicht dokumentiert. Das erschwert die Erstellung einer zuverlässigen SBOM für Firmware im Vergleich zum typischen SBOM-DevSecOps-Kontext.

Außerdem sind Sie mit einer Fragmentierung über Toolchains, Formate und Hardwaretypen hinweg konfrontiert. Im Gegensatz zu Cloud-nativen Anwendungen basieren eingebettete Systeme auf eng gekoppelten Abhängigkeiten. Diese sind schwieriger nachzuverfolgen und entsprechen möglicherweise nicht den Standardpraktiken von DevSecOps.

Firmware wird häufig auch von Drittanbietern kompiliert. Dies erhöht die Komplexität bei der Überprüfung von Komponenten, Lizenzen oder bekannten Schwachstellen. Ohne Transparenz wird die Firmware zu einer Black Box in der DevSecOps-Pipeline.

Zwei Wege zur Firmware-SBOM – und warum Teams beides brauchen

Es gibt zwei praktische Möglichkeiten, eine SBOM für Firmware zu erstellen: entweder aus dem Build-Prozess oder aus der Binärdatei. Jede Methode deckt unterschiedliche Teile des Puzzles auf, je nachdem, ob Sie Zugriff auf den Quellcode oder nur auf die kompilierte Firmware haben. Die kombinierte Verwendung beider Methoden bietet eine umfassendere Abdeckung, höhere Genauigkeit und einen vollständigeren Überblick über die Produktsicherheit.

SBOM aus dem Build-Prozess

SBOMs können als Teil des Builds während der Softwarekompilierung generiert werden. Diese Methode liefert auf Komponentenebene aus der Quelle genaue Informationen. Sie ist ideal, wenn Sie die Kontrolle über die Firmware-Codebasis haben.

Zu den Vorteilen von SBOMs zur Erstellungszeit gehören:

• Hohe Präzision bei der Identifizierung von Komponenten
• Umfangreiche Metadaten zu Lizenzen, Versionen und Quellen
• Einfache Integration in CI/CD-Workflows

Sie erhalten Transparenz während der Entwicklung und können Sicherheitsprüfungen automatisieren. Diese Methode setzt jedoch voraus, dass Sie die Build-Umgebung der Firmware besitzen oder verwalten. Ist dies nicht der Fall, entsteht eine erhebliche Lücke in der Transparenz.

SBOM aus Binary-/Firmware-Analyse

Die Binäranalyse ermöglicht Ihnen, eine SBOM durch das Reverse Engineering der kompilierten Firmware zu erstellen. Diese Technik ist unerlässlich, wenn der Quellcode nicht verfügbar ist. Damit können Sie Firmware von Drittanbietern oder älteren Produkten überprüfen.

Sie können Bibliotheken extrahieren, fest codierte Abhängigkeiten identifizieren und nach veralteten Komponenten suchen. Dies ist zwar weniger präzise als SBOMs zur Build-Zeit, schließt jedoch wichtige Lücken in der Transparenz. Dies ist besonders nützlich für Compliance-Teams und PSIRTs, die Lieferkettenrisiken verwalten.

Zu den wichtigsten Anwendungsfällen für binäre SBOMs gehören:

• Überprüfung von Drittanbieter-Firmware
• Analyse von Feldgeräten während der Reaktion auf Vorfälle
• Unterstützung bei Audits oder Untersuchungen nach der Veröffentlichung

Die Genauigkeit binärer SBOMs hängt von den verwendeten Tools ab. Sie benötigen leistungsstarke Funktionen zur Firmware-Extraktion, Dekompilierung und Mustererkennung. Durch die Kombination beider Methoden erhalten Sie ein vollständigeres Bild.

Wie passt Firmware-SBOM in einen DevSecOps-Flow?

Firmware-SBOMs können in Ihren gesamten DevSecOps-Lebenszyklus integriert werden. Sie bieten Sicherheitsteams Transparenz vom Entwurf bis zur Bereitstellung. Dies trägt zur Risikominderung und zur Verbesserung der Produktresilienz bei.

In der Entwicklung unterstützen SBOMs das sichere Codieren und die Schwachstellenprüfungen, während sie in CI/CD verwendet werden können, um unsichere Builds zu blockieren oder Richtlinienverstöße zu kennzeichnen. Nach der Veröffentlichung helfen sie PSIRTs dabei, Vorfälle zu verwalten und auf neue CVEs zu reagieren.

Wichtige Integrationspunkte für Firmware-SBOMs sind unter anderem:

• Entwurfsphase: Frühzeitige Identifizierung zugelassener Komponenten
• Entwicklungsphase: Automatische Generierung von SBOMs aus Code oder Binärdateien
• Testphase: Verwendung von SBOMs zur Durchführung von Sicherheits- und Lizenzprüfungen
• Bereitstellung: Archivierung von SBOMs zur Gewährleistung der Compliance und Rückverfolgbarkeit
• Post-release: Überwachung auf neu bekannt gewordene CVEs und Risiken

Durch die Integration von SBOMs in automatisierte Workflows für Schwachstellenmanagement-Lösungen können Sie Probleme frühzeitig erkennen. So wird sichergestellt, dass Schwachstellen im Zusammenhang mit Firmware-Komponenten zwischen den Releases nicht unbemerkt bleiben. Die Automatisierung reduziert menschliche Fehler und verbessert die Reaktionszeiten.

Konkreter Nutzen von Firmware-SBOMs in DevSecOps

SBOMs schaffen Mehrwert für alle Teams, nicht nur für die Sicherheit. Sie vereinfachen die Zusammenarbeit zwischen den Bereichen Technik, Compliance und Produktentwicklung. Jeder sieht, was in der Firmware enthalten ist, und was beachtet werden muss.

Zu den Vorteilen gehören:

• Verbesserte Erkennung von Schwachstellen: Teams können schneller reagieren, wenn neue CVEs auftreten.
• Optimierte Audits: SBOMs erleichtern den Nachweis der Einhaltung von NIS2, CRA und weiteren Vorschriften.
• Verkürzte Reaktionszeit bei Vorfällen: Wenn Sie wissen, was Ihre Firmware enthält, können Sie die Triage und die Fehlerbehebung beschleunigen.

Außerdem verbessern sie die Verantwortlichkeit. Die Einführung von SBOM-DevSecOps-Praktiken hilft, Lücken zwischen Entwicklung, Sicherheit und Compliance zu schließen. Mit klaren Komponentendaten können Sie Verantwortliche zuweisen, Risikoschwellen definieren und Governance durchsetzen. Hier kommt der Einsatz eines SBOM-Management-Tools ins Spiel.

Anforderungen an SBOM-Tools für Firmware/Embedded in DevSecOps

Um Firmware in DevSecOps zu unterstützen, benötigen Ihre SBOM-Tools spezielle Funktionen. Generische Lösungen erkennen häufig keine eingebetteten Komponenten oder verstehen keine nicht standardmäßigen Verpackungen. Sie benötigen Tools, die für Low-Level-Analysen entwickelt wurden.

Suchen Sie nach Tools, die Folgendes können:

• Analyse von Rohbinärdateien und Extraktion von Komponentendaten
• Unterstützung von SBOM-Formaten der Branche wie SPDX oder CycloneDX
• Integration mit CI/CD- und Ticketing-Tools wie Jenkins und Jira
• Erkennung von fest codierten Geheimnissen, veralteten Bibliotheken und Konfigurationsproblemen

Skalierbarkeit und Automatisierung sind ebenfalls wichtig. Manuelle Prozesse können mit den schnellen Firmware-Release-Zyklen nicht Schritt halten. Hier wird automatisiertes Schwachstellenmanagement zur Notwendigkeit und ist kein Luxus mehr.

Wichtig ist zudem die Integration eines CVE-Scanners, der firmwarespezifische Bedrohungen berücksichtigt. Herkömmliche Scanner übersehen häufig Risiken, die in Binärdateien verborgen liegen. Tools, die die Erstellung von SBOMs mit CVE-Analysen kombinieren, bieten einen umfassenderen Schutz.

Fazit

SBOMs sind ein Eckpfeiler der sicheren Firmware-Entwicklung. Sie helfen Teams dabei, zu verstehen, was in einem Gerät steckt und wie sich diese Komponenten im Laufe der Zeit verändern. Für DevSecOps-Teams, die mit eingebetteten Systemen arbeiten, schließen Firmware-SBOMs Sichtbarkeitslücken, die sonst unbemerkt bleiben würden.

Ihre Erstellung ist nicht immer einfach. Durch die Verwendung sowohl buildbasierter als auch binärer Methoden erhalten Sie jedoch die erforderliche Flexibilität. Mit den richtigen Tools und Strategien werden Firmware-SBOMs zu einem leistungsstarken Bestandteil Ihrer Sicherheits- und Compliance-Workflows.

Häufig gestellte Fragen zu SBOMs in DevSecOps (FAQ)

Wie unterscheidet sich eine SBOM von einem Dependency-Scan?

Ein Abhängigkeitsscan überprüft bekannte Bibliotheken im Quellcode oder in Paketen. Eine SBOM ist eine vollständige Bestandsaufnahme der Komponenten, einschließlich ihrer Versionen, Herkunft und Lizenzen. Sie ist umfassender und enthält Daten auf Binärcodeebene, wodurch sie für Firmware effektiver ist.

Welche SBOM-Standards sind für DevSecOps relevant (SPDX, CycloneDX)?

Die am häufigsten verwendeten Standards sind SPDX und CycloneDX. Beide werden von Open-Source-Tools unterstützt und können in Pipelines integriert werden. CycloneDX wird aufgrund seiner Unterstützung für Hardware-Metadaten häufig für den eingebetteten Einsatz bevorzugt.

Wie oft sollte eine SBOM aktualisiert werden?

Eine SBOM sollte bei jeder Firmware-Änderung aktualisiert werden. Dazu gehören Patches, Versionssprünge oder Aktualisierungen von Abhängigkeiten. Wenn Sie sie wie Quellcode behandeln, gewährleisten Sie Genauigkeit und Audit-Bereitschaft.

Ist SBOM-Management Pflicht für CRA oder NIS2?

Ja, sowohl die CRA als auch die NIS2 verlangen Transparenz hinsichtlich der Softwarekomponenten. SBOMs helfen Ihnen dabei, diese regulatorischen Anforderungen zu erfüllen. Außerdem verbessern sie Ihre Fähigkeit, auf Schwachstellen nach der Bereitstellung zu reagieren.

Wie automatisiert ONEKEY die SBOM-Erstellung?

ONEKEY unterstützt die SBOM-Generierung sowohl durch Build-Zeit- als auch durch Binärcode-Analyse. Es automatisiert die Extraktion, Formatierung und Verknüpfung von Schwachstellen. Dadurch können Teams genaue SBOMs für eingebettete Firmware generieren, ohne die Entwicklung zu verlangsamen.