Die sichere Software Supply Chain

Wo Code geschrieben wird, passieren Fehler. Diese Fehler in einer Software können zu Schwachstellen führen und diese schließlich zu Sicherheitsvorfällen. Die Softwareentwicklung reagiert darauf schon lange mit etablierten Verfahren: Code-Reviews, Unittests, statische Analysen oder auch Penetrationstests gehören zum Standardrepertoire moderner Entwicklungsteams.

Moderne Softwareprodukte bestehen allerdings nicht mehr nur aus selbstgeschriebener Software, der Anteil externer Komponenten nimmt stetig zu. Kaum ein Projekt kommt noch ohne Open Source Code aus, wie unter anderem der jährliche Open Source Security and Risk Analysis Report der Firma Black Duck nahelegt. Dabei decken die externen Komponenten alles Erdenkliche ab, von einfachsten Board Support Packages über kryptographische Bibliotheken und Webframeworks bis zu Betriebssystemen.

Verantwortung des Herstellers

Die Hersteller tragen die volle Verantwortung für die Gesamtsicherheit ihrer Produkte – auch für Bausteine, die sie nicht selbst entwickelt haben. Doch alle eingesetzten Fremdkomponenten mit den genannten Verfahren genauso gründlich zu prüfen wie den eigenen Code, ist für ein einzelnes Unternehmen unmöglich beziehungsweise höchst unwirtschaftlich. Wie lässt sich also sicherstellen, dass alle enthaltenen Komponenten frei von bekannten Schwachstellen sind, ohne jede einzelne Codezeile selbst zu analysieren? Und wie können Kunden dies nachvollziehen, wenn sie ein Produkt wiederum als Komponente in ihren eigenen Lösungen einsetzen?

Im Fall eines elektronischen Sicherungsautomaten, wie dem ‚REX12‘ von E-T-A, kann die Stückliste manuell gepflegt werden. © E-T-A

Immer wieder neue Berichte über Sicherheitslücken, die ganze Lieferketten betreffen, zeigen, wie wichtig es ist, Drittkomponenten auf dem neuesten Stand zu halten. Trotzdem enthalten laut Black Duck noch immer mehr als 60 % der Codebases im Automatisierungsumfeld schwerwiegende Sicherheitslücken, in anderen Industriebereichen teils deutlich mehr.

Die Europäische Union hat mit dem Cyber Resilience Act (CRA) eine gesetzliche Grundlage geschaffen, die ab 2026 verbindlich wird. Ein zentrales Element darin ist die Software Bill of Materials (SBOM), eine Art Stückliste für Software, die alle enthaltenen Komponenten dokumentiert und die Grundlage für die Überwachung auf Schwachstellen darstellt.

Der Lebenszyklus einer Schwachstelle

Um die Bedeutung der SBOM einzuordnen, ist es hilfreich, den Lebenszyklus einer Schwachstelle nachzuvollziehen. Schwachstellen entstehen durch unsauberes Software-Design, fehlerhafte Implementierungen oder auch falsche Konfigurationen. Kritisch werden sie dann, wenn Angreifer durch sogenannte Exploits die Verfügbarkeit, Integrität oder Vertraulichkeit von Daten und Systemen kompromittieren können.

Die Entdeckung einer Schwachstelle kann durch gezielte Code-Analysen, Scans laufender Systeme oder auch zufällig im alltäglichen Betrieb erfolgen. Die Entdeckung erfolgt durch Hersteller, Sicherheitsforscher oder auch Anwender und im schlimmsten Fall durch böswillige Akteure selbst. Idealerweise erfolgt die Meldung einer Schwachstelle an den Hersteller vertraulich und zeitnah. Geschieht dies nicht, droht die Veröffentlichung erst nach einem erfolgreichen Angriff.

Für Produkte wie den Buscontroller ‚CPC12‘ von E-T-A mit einem Webserver, der auf modernen Frameworks aufbaut, unterstützen Tools beim Erstellen der SBOM. © E-T-A

Nach der Meldung bewertet der Hersteller das Risiko der Schwachstelle systematisch mit dem Common Vulnerability Scoring System (CVSS), das anhand einer Kennzahl zwischen 0 und 10 die Schwere und Ausnutzbarkeit klassifiziert.

Für mehr Transparenz erfolgt anschließend die Veröffentlichung der Schwachstellen mit einer eindeutigen Kennung. Diese sogenannten Common Vulnerabilities and Exposures (CVE-IDs) werden von autorisierten CVE Numbering Authorities (CNAs) vergeben und dienen der standardisierten Referenz. Die CVE-Berichte werden in zentralen Schwachstellendatenbanken gesammelt, allen voran in der National Vulnerability Database (NVD). Dort lässt sich nachvollziehen, welche Komponenten betroffen sind und in welchen Versionen die Schwachstellen auftreten. Parallel arbeitet auch die Europäische Union an einer eigenen Lösung, der EU Vulnerability Database (EUVD). Damit soll die Abhängigkeit von US-amerikanischen Strukturen reduziert werden.

SBOM als Sicherheitsgrundlage

Während in üblichen Stücklisten (Bill of Materials - BOM) einer mechanischen oder elektronischen Baugruppe die Bauteile und deren Anzahl aufgelistet werden, listet eine BOM die Softwareabhängigkeiten auf. Für jede Komponente werden deren Ursprung, Version, Lizenz und jeweilige Subkomponenten erfasst, wobei nicht nur Bibliotheken, sondern auch Tools wie Compiler oder sogar KI-Modelle benannt werden können. Für den Austausch von SBOM haben sich die zwei maschinenlesbaren Standards CycloneDX und SPDX etabliert. Während SPDX ursprünglich hauptsächlich für den Austausch von Lizenzinformationen gedacht war, wurde CycloneDX von Beginn an mit einem Fokus auf Software Security entworfen.

Die SBOM können von verschiedenen Scan-Tools weiterverarbeitet werden, die die Stücklisten mit Schwachstellendatenbanken abgleichen und betroffene Komponenten automatisch an die Entwicklungsteams melden. Open Source Plattformen wie Dependency-Track greifen dafür beispielsweise auf die NVD zurück und zeigen gefundene Schwachstellen in Dashboards an. Kommerzielle Scanner gehen noch weiter und bieten detaillierte Berichte sowie Lösungsvorschläge an. Eine aktuelle und vollständige SBOM bildet die Grundlage für eine automatisierte und möglichst vollständige Schwachstellensuche in eingesetzten Softwarekomponenten. Doch wie lässt sich diese erstellen?

Für einfache Anwendungen mit bekannten Abhängigkeiten kann die Stückliste manuell gepflegt werden. Im Fall eines elektronischen Sicherungsautomaten wie dem ‚REX12‘ von E-T-A beispielsweise fällt die Liste eher kurz aus: ein Echtzeit-Betriebssystem (RTOS), ein Protokollstack und ein Board Support Package. Hier ist eine manuelle Pflege möglich. Für umfangreichere Produkte wie beispielsweise den Buscontroller ‚CPC12‘ von E-T-A mit einem Webserver, der auf moderne Frameworks aufbaut, wäre der manuelle Aufwand zu groß. Hier unterstützen Tools beim Erstellen der SBOM, die die Abhängigkeiten der Software erkennen und auflisten können. Die Herausforderung ist also nicht, eine SBOM zu erstellen, sondern das geeignete Tool dafür zu finden.

Maximilian Werner ist Produktentwickler bei E-T-A Elektrotechnische Apparate in Altdorf bei Nürnberg. © E-T-A

Besonders effektiv wird das Verfahren, wenn die SBOM- Erstellung und -Analyse automatisiert in die Continuous-Integration-Pipeline eingebunden wird. So kann keine Version eines Produkts erstellt werden, ohne dass dessen Abhängigkeiten dokumentiert und geprüft sind.

Abhängigkeiten besser verstehen

Die Pflege einer SBOM ist mehr als nur die Pflichterfüllung aus dem Cyber Resilience Act - richtig eingesetzt hilft sie, die Abhängigkeiten der eigenen Software besser zu verstehen. Mit den richtigen Tools unterstützt sie zudem dabei, nicht gegen die Lizenzbedingungen der eingesetzten Komponenten zu verstoßen.

Unternehmen müssen bei der Entwicklung von Produkten auf die neuen Anforderungen reagieren, beispielsweise mit der Implementierung eines Produktenwicklungsprozesses nach IEC 62443-4-1, internationaler Standard für sichere Entwicklungsprozesse in der industriellen Automatisierung. E-T-A belegt mit dieser angestrebten Zertifizierung der Entwicklungsprozesse den verantwortungsvollen Umgang mit Schwachstellen in der Software Supply Chain. Bereits seit mehreren Jahren setzt das Unternehmen Dependency-Track ein und überprüft damit 24 Stunden am Tag die Software auf veröffentlichte Schwachstellen. Für die eigenen Produkte veröffentlicht E-T-A die aktuellen SBOM im Format CycloneDX auf der eigenen Homepage, so dass Kunden sie direkt in ihre Schwachstellenscans einbinden können. Damit erfüllt E-T-A schon heute diese zentrale Forderung des Cyber Resilience Act.