Zutatenliste: BSI stellt Regeln zum Absichern der Software-Lieferkette auf

Das BSI hat eine Richtlinie fĂĽr Software Bills of Materials (SBOM) herausgegeben. Solche Ăśbersichtslisten sollen Sicherheitsdebakeln wie Log4J entgegenwirken.

In Pocket speichern vorlesen Druckansicht 80 Kommentare lesen

(Bild: SWstock / Shutterstock.com)

Lesezeit: 4 Min.
Inhaltsverzeichnis

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) will Unternehmen und die öffentliche Verwaltung dabei unterstützen, Software-Lieferketten besser abzusichern und die Auswirkungen von Sicherheitsdebakeln wie Log4j abzumildern. Die Bonner Behörde hat dazu am Freitag eine Technische Richtlinie (TR) zur Cyber-Resilienz veröffentlicht, in der sie formelle und fachliche Vorgaben für das Konzept Software Bill of Materials (SBOM) aufstellt. Dabei handelt es sich um ein maschinenlesbares Dokument, das eine elektronische Stück- beziehungsweise Teileliste sowie deren Code-Abhängigkeiten enthält.

SBOM listen die Bestandteile eines Softwareprojekts möglichst vollständig auf. Dazu gehören neben dem direkten Quelltext interne und externe Verweise etwa zu genutzten Open-Source-Paketen. Da letztere ihrerseits häufig wiederum von anderen Projekten abhängen, müssen diese in der Software Bill of Materials ebenfalls aufgeführt werden. Die Informationen einer Software-Inventardatenbank "können in unterschiedlicher Breite und Tiefe dargestellt sein", schreibt das BSI in der neuen TR-03183. Sie reichten von einer groben Struktur bis zu einer feingranularen Aufschlüsselung von Produkten und Komponenten. Zur Darstellung und Übertragung einer SBOM existierten zudem unterschiedliche Formate, zu deren Einsatz die Verfasser des Dokuments Hinweise und Anweisungen geben.

Eine SBOM sollte laut dem BSI bei jedem Software-Ersteller und -Anbieter vorhanden sein, um die Komplexität genutzter Programme transparent darstellen zu können. Nur so sei leicht in Erfahrung zu bringen, welche Bestandteile wie Bibliotheken eingesetzt werden. Dieses Wissen sei für Managementprozesse unabdingbar, etwa zum Produkt-Lebenszyklus und insbesondere für einen kontinuierlichen IT-Sicherheitsprozess. Es gelte als bewährte Praxis einer sicheren Software-Lieferkette.

So mussten im Fall von Log4J viele Administratoren in kleineren IT-Abteilungen im Alleingang jede Anwendung durchforsten und in Konzernen im Eiltempo Tabellen zusammenstellen, in denen Verantwortliche einer Applikation eintragen sollten, ob in ihr die betroffene Bibliothek zum Einsatz kommt. SBOM hätten hier den Überblick vereinfacht.

Ein solches Zutatenverzeichnis könne öffentlich oder privat sein "und auf unterschiedlichen Verteilungswegen verbreitet werden", ist der TR zu entnehmen. In der Regel verwende ein Software-Entwickler eine oder mehrere Komponenten Dritter. Er erzeuge und verwalte die SBOM der eigenen Programme, nehme aber zugleich "die Konsumentenrolle" der Zutatenlisten der eingebundenen Bestandteile ein. Die Fülle an SBOM-Informationen und die möglichen Strukturunterschiede bedeuteten einen hohen Aufwand für jeden Ersteller, heißt es weiter, "dem nur mit Automatisierung effektiv zu begegnen ist".

Mithilfe eines einschlägigen Verzeichnisses lasse sich prüfen, "ob ein Produkt potenziell von einer Schwachstelle betroffen ist", führt das BSI aus. Enthalten seien jedoch keine Aussagen zu Sicherheitslücken und deren Ausnutzbarkeit. Es gelte daher, zusätzliche Sicherheitshinweise wie den CVE (Common Vulnerabilities and Exposures) der Komponentenanbieter einzubeziehen. Im Detail listet die Behörde in der TR etwa notwendige Datenfelder zur SBOM selbst wie eine URL nebst E-Mail-Adresse des Erstellers und Zeitstempel sowie erforderliche Angaben zu jeder Komponente, deren Version und Abhängigkeiten auf. Dazu kommt eine Übersicht zusätzlicher, möglichst ebenfalls anzugebender Datenfelder.

Open-Source-Werkzeuge wie Cilium enthalten bereits eine SBOM. Die Versionsverwaltungsplattform GitHub führte im März eine Funktion ein, mit der Verantwortliche eine solche Übersicht für ihr Projekt erstellen können. Zuvor hatte GitHub-Eigentümer Microsoft mit Salus im Juli 2022 ein eigenes Open-Source-Werkzeug veröffentlicht, das eine SBOM für Entwicklungsinitiativen produziert. Google bietet mit einer Programmierschnittstelle zum Abfragen der Daten von Open Source Insights seit April eine ähnliche Funktion. Zudem machte der Konzern parallel auf SBOM-Basis seinen Dienst Assured Open Source Software allgemein kostenfrei verfügbar.

Der Entwurf der EU-Kommission für einen Cyber Resilience Act enthalte eine Pflicht, eine SBOM anzufertigen, verweist das BSI auf ein aktuell laufendes Gesetzgebungsverfahren. Erfasst würden Produkte mit digitalen Elementen, für die ein Schwachstellenmanagement verbindlich werde. In den USA schreibe die Anordnung 14028 von US-Präsident Joe Biden zur Cybersicherheit vom Mai 2021 für Behörden das Führen einer Stückliste vor. Für Medizinprodukte gälten in den USA seit März ähnliche Regeln. Auch der EU-Rat rückte voriges Jahr die Sicherheit von IT-Lieferketten in den Fokus.

(tiw)