TR-03183-2 für SBOM Stücklisten für Software werden verpflichtend

Anbieter zum Thema

AixpertSoft GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

Software-Stücklisten gehören zu den zentralen Forderungen des europäischen Cyber Resilience Act (CRA). Demnächst dürften sie in Gesetzesform gegossen werden. Sie geben Auskunft über den beim Entwicklungsprozess benutzten Code. Was bedeutet das für Hersteller und Anwender?

Bereits im Sommer hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) Teil 2 der Technischen Richtlinie TR-03183 „Cyber-Resilienz-Anforderungen“ veröffentlicht. Er definiert formelle und fachliche Vorgaben für elektronischen Stück- / Teileliste von Software, so genannten „Software Bill of Materials“ (SBOMs). Sie dienen vorrangig der Erhöhung der Sicherheit in der Software-Lieferkette. Was aber ist bei deren Erstellung zu beachten?

Nun, SBOMs inventarisieren die Codebasis und offerieren somit Informationen zu allen verwendeten Komponenten einer Software. Diese Informationen können in unterschiedlicher Breite und Tiefe dargestellt sein und reichen von einer groben Struktur bis zu einer feingranularen Aufschlüsselung von Produkten und Software-Komponenten.

Eine SBOM dokumentiert auch, welche kommerziellen und freien Software-Bestandteile in Software-Produkten enthalten sind. Sie macht Abhängigkeiten zu Komponenten Dritter transparent und hilft damit Herstellern, Sicherheitsforschenden sowie professionellen Anwendern beim Monitoring von Schwachstellen.

Ein Code-Verzeichnis von Abhängigkeiten

Was ist SBOM - Software Bill of Materials?

Eine SBOM sollte bei jedem Software-Ersteller und -Anbieter vorhanden sein, um Software-Komplexität transparent darstellen zu können und um zu wissen, welche Bestandteile, zum Beispiel Bibliotheken eingesetzt werden. Schließlich wird in der Regel eine Vielzahl unterschiedlicher Quellen und Komponenten genutzt. Dieses Wissen ist für Software-Management-Prozesse, insbesondere für einen kontinuierlichen IT-Sicherheitsprozess und das Lebenszyklus-Management von Software unabdingbar und gilt als „Best Practice“ einer sicheren Software-Lieferkette.

„Zahlreiche Cyber-Sicherheitsvorfälle der letzten Jahre zeigen, dass von unerkannt installierter Gerätesoftware bzw. Firmware erhebliche Gefahren ausgehen. Viele dieser Schwachstellen sind auf unausgereifte Sicherheitspraktiken zurückzuführen. Eine Software Bill of Materials macht die Komponenten mit Schwachstellen sichtbar“, sagt Jan Wendenburg, CEO von Onekey.

Probleme und Einschränkungen

SBOMs werden helfen, sind aber nicht ganz problemlos: In der Regel verwendet ein Ersteller einer Software ein oder mehrere Komponenten Dritter. Er erzeugt und verwaltet die SBOMs der eigenen Software, zusätzlich nimmt er die Konsumentenrolle der SBOMs der eingebundenen Komponenten ein. Die Fülle an SBOM-Informationen und die möglichen Unterschiede in der Struktur von SBOMs bedeuten einen hohen Aufwand für jeden Ersteller - dem nur mit Automatisierung effektiv zu begegnen ist.

Und: Mit Hilfe von SBOM-Informationen kann zwar geprüft werden, ob ein Produkt potenziell von einer Schwachstelle betroffen ist, indem dessen Komponentenliste mit den in den Schwachstelleninformationen aufgeführten Software-Komponenten abgeglichen wird. Eine SBOM enthält jedoch keine Aussage zu Schwachstellen oder deren Ausnutzbarkeit.

Ob und in welchem Maße durch eine Schwachstelle einer verwendeten Software-Komponente ein Risiko für das Produkt besteht, das die SBOM beschreibt, geht aus ihr ebenfalls nicht hervor. Hierzu sind weitere Informationen über die konkrete Schwachstelle erforderlich, wie beispielsweise mittels Security Advisories oder VEX1 (Vulnerability Exploitability Exchange).

In den USA bereits verpflichtend

Für den Abgleich eines SBOMs mit Schwachstelleninformationen wie beispielsweise den CVE (Common Vulnerabilites and Exposures) oder Security Advisories der Komponentenersteller oder -anbieter ist zudem eine Analyse der Software selbst notwendig. Nur so kann festgestellt werden, wie deren potentiell betroffene Subkomponenten verwendet wurden, und ob und wie die eigene Software betroffen ist.

Diese ist im Rahmen des Schwachstellen-Managements für das Produkt durchzuführen. Das Ergebnis dieser Analyse wird den Nutzern der Software dann als Security Advisory oder VEX für das Produkt bereitgestellt.

Supply-chain Levels for Software Artifacts: „Eine feine Sache“

Suse-CTO Gerald Pfeifer zur Absicherung von Softwarelieferketten

Übrigens: Im US-amerikanischen Raum wird die SBOM durch die US Executive Order 14028 vom Mai 20213 bereits für Anwendungen im behördlichen Umfeld gefordert. Seitens der FDA (Food and Drug Administration) muss für Medizinprodukte bereits seit März 2023 eine SBOM bei der Zulassung zwingend vorgelegt werden.

„Anbieter und Anwender sollten sich mit SBOMs vertraut machen, da die Bereitstellung von SBOMs von Anbietern in vielen Marktbereichen bald verlangt werden wird. Anwender sollten von ihren Lieferanten bereits heute SBOMs fordern, auch wenn viele Anbieter derzeit noch nicht in der Lage sind, diese bereitzustellen“, kommentierte Oliver Dehning, Leiter der Kompetenzgruppe (KG) Sicherheit im Eco - Verband der Internetwirtschaft.

(ID:49836179)