Sicherheit und Compliance auf Codeebene – Was Sie über die Software-Bill-of-Materials (SBOM) wissen müssen

Rückverfolgbarkeit in der Software Supply Chain

Ein Ziel der SBOM ist es, den Weg jeder einzelnen der Komponenten entlang der Software Supply Chain lückenlos zurückverfolgen zu können und die komplexen Lieferketten in transparenter Art abzubilden. Neben den Basisinformationen müssen daher auch die Verbindungen sowie direkte und transitive Abhängigkeiten zwischen den Komponenten erfasst und dokumentiert werden. Welche Subkomponenten sind in einer Komponenten enthalten (Child/Parent Component)? Und von welchem Autor oder aus welcher Source Library stammen diese?

Bei Erstellen einer SBOM beginnen Softwareanbieter und Entwicklerteams daher oft mit einer  einfachen Liste der Top-Level-Komponenten, die sich dann weiter nach unten verzweigt und die jeweiligen Subkomponenten einschließlich ihrer Lizenzen und Schwachstellen aufführt. Dabei ist es nicht unbedingt entscheidend, ob eine Subkomponenten im vollen Umfang oder nur teilweise, das heißt für bestimmte Funktionalitäten in einer Anwendung, genutzt wird. Unabhängig von ihrer Rolle für die Software können auch ungenutzte Subkomponenten beispielsweise Sicherheitsschwachstellen enthalten, die sich auf die übergeordnete Komponente auswirken. In der Fertigung, aus der die Bill-of-Material ursprünglich stammt, werden solche mehrstufigen Stücklisten auch als Multi-Level BOM bezeichnet.

Standardformate für mehr Durchblick

Strukturierte Datenformate und Austauschprotokolle sind ein weiteres wichtiges Merkmal einer funktionalen SBOM. Einheitliche Formate bilden die Voraussetzung für Maschinenlesbarkeit von SBOMs und damit eine höhere Automatisierung bei der Analyse des Codes und der Aufdeckung von Sicherheits- und Compliance-Risiken. Die konsistente Notation von Informationen schafft nicht nur Transparenz und stärkt das Vertrauen in den Code, sie reduziert auch den Arbeitsaufwand für Entwicklerteams und vereinfach die Zusammenarbeit zwischen Anbietern. Den einen Standard für den formalen Aufbau einer Software-Stückliste, das von allen Entwicklern und Anbietern einheitlich verwendet wird, gibt es leider nicht. In den letzten Jahren haben sich in der Branche jedoch einige Formate besonders stark etabliert. Dazu gehören SPDX, CycloneDX und SWID.

• Das quelloffene, maschinenlesbare Standardformat Software Package Data Exchange (SPDX) wurde von einer Arbeitsgruppe der Linux Foundation im Rahmen des „Open Compliance Program“ entwickelt und 2011 eingeführt. Neben eindeutigen Informationen zum Softwarepaket sowie den Lizenz- und Urheberrechtsinformationen auf Paket- und Dateiebene liefert SPDX auch Metadaten über Verfasser des Codes und Zeitpunkt der Programmierung. Damit liegt der Fokus der SPDX auf dem Handling von OSS und dem Management von Lizenzen und Copyrights. Liegen beispielsweise für Top-Level und Subkomponenten unterschiedliche Lizenzen vor, können Entwickler diese Abweichungen einfacher erkennen und sämtliche Compliance-Vorgaben auf Dateiebene in einer einzigen Datei zusammenzufassen.

• CycloneDX ist eine Weiterentwicklung von SPDX und wurde 2017 von einer Arbeitsgruppe des Open Web Application Security Project (OWASP) vorgestellt. Ähnlich wie SPDX ist auch bei diesem Format das Ziel, Lizenzbestimmungen einfacher einsehen und einhalten zu können. Ein primärer Use Case von CycloneDX ist jedoch darüber hinaus die Identifizierung von Schwachstellen sowie die die Analyse veralteter Komponenten. Zusätzliche Funktionen wurden in späteren Versionen der Spezifikation hinzugefügt.

• SWIDs sind Software-Identifikations-Tags, die nach ISO/IEC 19770-2 definiert sind und in Form von XML-Dateien gemeinsam mit den jeweiligen Softwareprodukten ausgeliefert werden. Die Tags enthalten produktbezogene Metadaten (wie etwa Name, Version, Artefakte und Distributionsweg). Dank ihrer standardisierten Form lassen sich SWIDs von Inventory-Tools auslesen und für das IT-Asset-Managements sowie das Vulnerability Management nutzen. Doch auch im Rahmen der Software Composition Analysis (SCA) liefern sie wichtige Informationen.

Automatisierte Tools für konsolidierte Sicht

Softwareanbieter müssen je nach Anwendung und Produkt-Portfolio große Mengen an Daten zusammenziehen, um Software-Stücklisten zu erstellen und kontinuierlich anzupassen. Die Code-Komponenten beschränken sich dabei keineswegs nur auf intern erstellte SBOMs, sondern müssen vorgelagerte Upstream-Partner und Drittanbieter abdecken. Hinzu kommen Daten aus SCA-Scans, Open Source Software-Libraries und anderen Data Services.

Ohne automatisierte Tools ist das Sammeln, Erstellen und Managen von SBOM-Informationen eigentlich kaum noch möglich. Dafür ist die Software Supply Chain schlichtweg zu komplex und der Umfang an Softwarecode zu groß. Automatisierte SBOM-Lösungen aggregieren Daten ganzheitlich über unterschiedliche Quellen hinweg und unabhängig ihrer Formate, um sie anschließend abzugleichen, zu normalisieren und in eine Software-Stücklisten zu überführen. Idealerweise entsteht so eine konsolidierte Sicht auf den Code einer Anwendung, um potentielle Sicherheits- und Compliance-Risiken proaktiv zu verwalten.

Diese vollständige Transparenz wird für Sicherheitsteams, Rechtsabteilungen sowie die die nachgelagerten Lieferkettenpartner angesichts der wachsenden Anforderungen an Sicherheit und Compliance immer zentraler. Es ist letztendlich auch der Grund, warum viele Organisationen bei Verhandlungen mit Softwareanbietern die Software-Stückliste mittlerweile sogar vertraglich festsetzen. Behörden und Branchenverbände wie die FDA (The Food and Drug Administration) sowie die GENIVI Alliance und die Automotive Grade Linux (AGL) machen sich schon seit Jahren für eine bessere Dokumentation im Umgang mit Open Source stark. In der EU steckt die Open-Source-Software-Strategie 2020-2023 genau ab, unter welchen Voraussetzungen freie und offene Software zum Einsatz kommen darf. Und auch die US-Regierung nimmt seit einer Executive Order im Jahr 2021 Softwareanbieter und Entwickler stärker in die Verantwortung, was die Transparenz der Software Supply Chain angeht. In all diesen Fällen nimmt die Software-BOM einen zentralen Platz ein und schafft damit die Grundvoraussetzung für Anwendungssicherheit und Compliance.