Eine SBOM (Software Bill of Materials) ist eine Liste der Komponenten und Abhängigkeiten, aus denen sich ein bestimmtes Softwareprodukt zusammensetzt. Es umfasst alle Bibliotheken, Module, Frameworks und sonstigen externen Ressourcen, die für die Erstellung der Software erforderlich sind, sowie die Beziehungen zwischen diesen. Im Wesentlichen stellt eine SBOM die digitale Lieferkette eines Softwaresystems dar. Und dies gilt nun für alle Anbieter, die Software an die Bundesregierung verkaufen. Auch alle anderen, die Software entwickeln oder betreiben, können davon profitieren.
SBOMs sind bereits seit mehr als einem Jahrzehnt Teil der Open-Source-Community, haben jedoch in Kreisen der Cybersicherheit seit der Welle von Angriffen auf die Software-Lieferkette von US-Unternehmen und Regierungsbehörden in den Jahren 2020 und 2021 verstärkt Aufmerksamkeit auf sich gezogen.
Insbesondere der „ “-Hack bei SolarWinds – bei dem Bundesbehörden, darunter das Ministerium für Innere Sicherheit und das Finanzministerium, unwissentlich eine mit einem Trojaner infizierte Komponente eingesetzt hatten, die es den Angreifern ermöglichte, Zugriff auf die Computersysteme der Opfer zu erlangen – führte zu einer Anordnung des „ “ unter Mai 2021 , wonach jeder Anbieter, der Software an die Bundesregierung verkauft, seine Komponenten in einer SBOM detailliert auflisten muss.
Aufgrund der Komplexität der Software-Lieferkette kann eine einzelne Softwarekomponente einen überproportional großen Einfluss auf deren Sicherheit haben. Die Nutzer haben jedoch nur sehr begrenzte Einblicke in die Komponenten, die in ihren geschäftskritischsten Anwendungen eingebettet sind. Eine Liste der „Bestandteile“ eines Produkts kann ihnen einen besseren Überblick über ihre Sicherheitsrisiken verschaffen und dient als Leitfaden, um Schwachstellen aufzuspüren, bevor diese zu einer Krise führen.
Wo liegt der Ursprung von SBOM?
Die neue Fokussierung auf SBOMs geht auf die von Präsident Biden im Rahmen der „ “ erlassene Executive Order (EO) 14028 zur Verbesserung der Cybersicherheit der Nation zurück, die das National Institute of Standards and Technology (NIST) und andere Bundesbehörden beauftragt, die Cybersicherheit durch eine Vielzahl von Initiativen im Zusammenhang mit der Sicherheit und Integrität der Software-Lieferkette zu verbessern, um die Netzwerke der Bundesregierung besser zu schützen.
Die Exekutivverordnung war im Wesentlichen eine Reaktion auf die Zunahme von Cyberangriffen auf US-Unternehmen und die US-Regierung in den Jahren 2020 und ’21. In diesem Zeitraum kam es zu häufigeren und schwerwiegenderen Angriffen, wobei zwei der verheerendsten – der SolarWinds-Angriff und der Ransomware-Angriff auf die Colonial Pipeline – den Anstoß für die EO gaben.
Beim SolarWinds-Angriff ermöglichte eine einzige mit einem Trojaner infizierte Komponente in der Orion-Software des in Texas ansässigen Unternehmens, die zur Überwachung und Verwaltung von IT-Netzwerken und -Infrastrukturen eingesetzt wird, Hackern den Zugriff auf die Systeme von Tausenden von Organisationen, darunter Fortune- 500 -Unternehmen, mehrere Bundesbehörden und sogar das US-amerikanische Cybersicherheitsunternehmen, das den Angriff schließlich aufdeckte. Bis zu 18 000 Opfer aus dem privaten und öffentlichen Sektor haben die infizierte Software heruntergeladen, wobei jedoch nur wenige davon anschließend kompromittiert wurden.
Der Ransomware-Angriff auf Colonial Pipeline richtete sich zwar gegen ein einzelnes Unternehmen, hatte jedoch weitreichende Auswirkungen auf die Infrastruktur des Landes. Als das Unternehmen, das etwa 45 Prozent des Kraftstoffs an der Ostküste liefert, den Angriff entdeckte, sah es sich gezwungen, wichtige Computersysteme vom Netz zu nehmen, um die Bedrohung einzudämmen, wodurch der Betrieb praktisch zum Erliegen kam. Die daraus resultierenden Kraftstoffengpässe führten zu einer Welle von Hamsterkäufen und einem sprunghaften Anstieg der Benzinpreise.
Die Durchführungsverordnung berücksichtigt die aus diesen und anderen Sicherheitsvorfällen gewonnenen Erkenntnisse und zielt darauf ab, die Zusammenarbeit zwischen dem öffentlichen und dem privaten Sektor zu fördern, um den immer raffinierteren Cyberangriffen entgegenzuwirken. Konkret werden darin mehrere Ziele dargelegt:
- Verbesserung des Informationsaustauschs –Die Exekutivverordnung sieht vor, dass alle vertraglichen Hindernisse für den Austausch von Informationen über Bedrohungen zwischen der Regierung und der Privatwirtschaft beseitigt werden, und verpflichtet IT-Dienstleister dazu, Informationen über Bedrohungen, Schwachstellen und Vorfälle weiterzugeben, die möglicherweise Auswirkungen auf die Bundesregierung haben könnten.
- Modernisierung der Cybersicherheit in der Regierung –Die Exekutivverordnung beauftragt die Bundesregierung mit der Einführung strengerer Cybersicherheitsstandards und bewährter Verfahren. Dazu gehören die Einführung sicherer Cloud-Dienste, die Anwendung eines Zero-Trust-Sicherheitsmodells sowie die Implementierung von Multi-Faktor-Authentifizierung (MFA) und Verschlüsselungsverfahren.
- Stärkung der Sicherheit in der Software-Lieferkette –Die Regierung beabsichtigt, grundlegende Sicherheitsstandards für die Softwareentwicklung festzulegen, die für die von Auftragnehmern beschaffte Software gelten sollen. Das Handelsministerium und die Nationale Telekommunikations- und Informationsbehörde (NTIA) müssen Elemente für eine Software-Stückliste veröffentlichen, in der die einzelnen Komponenten, aus denen sich ein Softwareprodukt zusammensetzt, aufgeführt und detailliert beschrieben werden.
- Einrichtung eines Ausschusses zur Überprüfung der Cybersicherheit –Die Regierung wird einen Ausschuss zur Überprüfung der Cybersicherheit ( ) einrichten, dessen Vorsitz Experten aus Regierung und Privatwirtschaft gemeinsam innehaben werden. Dieser Ausschuss wird nach einem schwerwiegenden Cybersicherheitsvorfall zusammentreten, um den Vorfall zu analysieren und Empfehlungen für Sicherheitsverbesserungen auszusprechen.
[Lesen Sie auch: Der Aktionsplan der US-Regierung zur Stärkung der Lieferketten]
- Erstellen Sie ein Handbuch für die Reaktion auf Sicherheitsvorfälle –. IT-Verantwortliche in der öffentlichen Verwaltung müssen ein einheitliches Handbuch für die Reaktion auf Sicherheitsvorfälle ( ) entwickeln, um sicherzustellen, dass alle Bundesbehörden effektiv auf Cyberangriffe reagieren und deren Schäden beheben können.
- Verbesserung der Erkennung von Vorfällen –Die EO schreibt vor, dass ein regierungsweites Endpunkt-Erkennungs- und Reaktionssystem (EDR) nach dem „ “-Prinzip eingeführt und der Informationsaustausch innerhalb der Bundesregierung verbessert werden muss, um Cybersicherheitsvorfälle besser erkennen zu können.
- Verbesserung der Untersuchung und Behebung –Die Regierung wird für alle Bundesbehörden Anforderungen an die Protokollierung von Cybersicherheitsvorfällen festlegen, um die Untersuchung und Behebung von Cybersicherheitsvorfällen in den Netzwerken der Bundesregierung zu verbessern.
Die Durchführungsverordnung legte unmittelbare Ziele fest, die von mehreren Regierungsbehörden zu erreichen sind, doch sie hat weitreichende Auswirkungen auf die gesamte Lieferkette im Bereich der Bundesaufträge. Konkret betrifft die EO drei Gruppen:
- Bundesbehörden –Die obersten Regierungsbehörden sind damit beauftragt, ihre IT-Umgebung und ihre Sicherheitsmaßnahmen zu modernisieren.
- Auftragnehmer der Bundesregierung –Auftragnehmer, die mit der US-Regierung zusammenarbeiten, darunter auch Anbieter von handelsüblicher Software (Commercial-off-the-Shelf, COTS), müssen damit rechnen, dass neue Cybersicherheitsstandards in die Vertragsbedingungen aufgenommen werden. Zudem sind sie verpflichtet, mehr Informationen über Cybervorfälle weiterzugeben.
- Privatunternehmen –Privatunternehmen unterliegen künftig neuen Gesetzen zur Cybersicherheit sowie einer strengeren Durchsetzung bestehender Gesetze und Richtlinien, wobei der Schwerpunkt verstärkt auf der Sicherheit der Lieferkette für „ “-Software sowie der Meldung von Cybervorfällen gemäß dem „ “ liegt. Zudem wird durch die vorgeschlagene Kennzeichnung von Software und Geräten des Internets der Dinge (IoT) im Hinblick auf die Verbrauchersicherheit ein stärkerer Schwerpunkt auf Transparenz gelegt, was zu neuen Sicherheitsanforderungen und Bewertungsstandards für diese Anbieter führt.
Warum sind SBOMs heutzutage wichtig?
SBOMs sind wichtig, da sie Unternehmen dabei helfen können, etwaige Schwachstellen in ihrer Software und deren Abhängigkeiten zu identifizieren und zu beheben. Moderne Anwendungen werden unter Verwendung einer Lieferkette aus Softwarekomponenten entwickelt, die ebenso komplex ist wie die von Herstellern physischer Güter. Eine typische App besteht aus Dutzenden von Komponenten, die aus einer Mischung aus firmeneigenem Code und wiederverwendbaren Komponenten von Drittanbietern zusammengesetzt sind. Zwar kann ein Entwickler den von ihm geschriebenen Code auf Fehler und Unstimmigkeiten überprüfen, doch hat er weniger Einblick in den Code von Drittanbietern. Angreifer sind sich dessen bewusst und nutzen dies aus, indem sie Komponenten von Drittanbietern ins Visier nehmen, da sie wissen, dass sie dadurch wahrscheinlich unentdeckt bleiben.
“„Wenn eine Sicherheitslücke entdeckt oder bekannt gegeben wird, können SBOMs dabei helfen, festzustellen, wo diese Softwareversion innerhalb des Unternehmens eingesetzt wird.“
Neben dem mittlerweile berüchtigten SolarWinds-Vorfall hat eine Reihe von Angriffen auf die Lieferkette in den letzten Jahren deutlich gemacht, welche verheerenden Auswirkungen ein solches Szenario haben kann. Angreifer nutzten eine kritische Sicherheitslücke in der Open-Source-Software „Apache Log4j “ aus, einer nahezu allgegenwärtigen Protokollierungsbibliothek, die Aktivitäten in Millionen von Java-basierten Anwendungen aufzeichnet. Hacker nutzten zudem vier separate Zero-Day-Sicherheitslücken vom Typ „ “ in Microsoft Exchange Server aus, um sich Zugang zu den Netzwerken von 30 000 US-amerikanischen Organisationen zu verschaffen.
Eine SBOM kann einem Unternehmen dabei helfen, sich besser vor solchen Angriffen auf die Lieferkette zu schützen und Prioritäten im Risikomanagement zu setzen. So kann das Unternehmen beispielsweise mithilfe von SBOMs zunächst die Verwendung von Bibliotheken mit bekannten Sicherheitslücken ausschließen und anschließend sicherstellen, dass stets die aktuellste Version jeder Open-Source-Bibliothek verwendet wird. Wird eine Sicherheitslücke entdeckt oder bekannt gegeben, können SBOMs dabei helfen, festzustellen, an welchen Stellen innerhalb des Unternehmens diese Softwareversion zum Einsatz kommt. Allgemeiner ausgedrückt ermöglichen SBOMs es Unternehmen, fundiertere Entscheidungen über die von ihnen genutzte Software zu treffen, und regen Softwareanbieter dazu an, sicherere Produkte zu entwickeln.
Aus welchen Komponenten besteht eine SBOM?
Unter Juli 2021 veröffentlichte die NTIA das Dokument „The Minimum Elements For a Software Bill of Materials“, in dem die Anforderungen der Bundesregierung im Rahmen des „ “ an eine SBOM dargelegt werden. Es unterteilt die Basiskomponenten einer SBOM in drei Kategorien: Datenfelder, Automatisierungsunterstützung sowie Vorgehensweisen und Prozesse. Hier sehen Sie die einzelnen Punkte im Detail.
Datenfelder
Die Datenfelder sollten jede Komponente eindeutig identifizieren, damit diese über die gesamte Software-Lieferkette hinweg nachverfolgt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen werden kann. Die NTIA legt sieben Datenfelder fest:
- Name des Lieferanten: Der Name der Organisation, die die Komponente erstellt und identifiziert.
- Komponentenname: Der Name, den der ursprüngliche Lieferant einer Softwareeinheit zugewiesen hat.
- Version der Komponente: Die Build- und Versionsangaben der in einem Softwareprodukt verwendeten Komponente.
- Weitere eindeutige Identifikatoren: Suchschlüssel und sonstige Informationen, wie beispielsweise ein Identifikator aus dem CPE-Wörterbuch des NIST unter , die zur Identifizierung einer Komponente verwendet werden können.
- Abhängigkeitsbeziehung: Eine Beschreibung der Abhängigkeiten zwischen der Komponente und anderer Software. Beispielsweise ist die Komponente A in der Software B enthalten.
- Urheber der SBOM-Daten: Der Name der Organisation, die die SBOM-Daten der Komponente erstellt hat.
- Zeitstempel: Datum und Uhrzeit, zu denen die SBOM-Daten zusammengestellt wurden.
Unterstützung der Automatisierung
Da es für Sicherheitsexperten nicht machbar ist, jede SBOM manuell nach kompromittierten Komponenten zu durchsuchen, schreibt die NTIA vor, dass jede SBOM die Automatisierung durch eines von drei maschinenlesbaren Formaten unterstützen muss:
- Cyclone DX
- Software Package Data Exchange (SPDX)
- Software-Identifikations-Tags (SWID)
[Read also: Here’s your security automation playbook for 2023]
Verfahren und Prozesse
Verfahren und Prozesse gewährleisten die Richtigkeit eines SBOM-Dokuments über den gesamten Lebenszyklus eines Softwareprodukts hinweg. Die NTIA nennt mehrere Mindestanforderungen, die berücksichtigt werden müssen, darunter:
- Häufigkeit: Immer wenn eine Softwarekomponente durch einen neuen Build oder eine neue Version aktualisiert wird, muss eine neue SBOM erstellt werden, um die neue Version der Software widerzuspiegeln. Dazu gehören Software-Builds zur Integration einer aktualisierten Komponente oder Abhängigkeit. Ebenso sollte der Lieferant, falls er einen Fehler korrigieren oder Informationen in den bestehenden SBOM-Daten aktualisieren möchte, eine neue, überarbeitete SBOM erstellen.
- Weiterführende Informationen: Eine SBOM sollte alle Komponenten der obersten Ebene enthalten und deren Abhängigkeiten auflisten.
- Bekannte Unbekannte: Manchmal erkennen Entwickler, dass sie nicht alle Abhängigkeitsbeziehungen einer Komponente kennen. In diesen Fällen sollte aus der SBOM hervorgehen, dass die Daten unvollständig sind, und es sollte erläutert werden, wo möglicherweise Zusammenhänge bestehen.
- Verteilung und Bereitstellung: SBOMs sollten denjenigen, die sie benötigen, zeitnah zur Verfügung stehen, sofern diese über die entsprechenden Zugriffsberechtigungen und Rollen verfügen.
- Zugriffskontrolle: Organisationen, die SBOM-Daten vertraulich behandeln möchten, müssen die Bedingungen festlegen, einschließlich der Ausnahmeregelungen und Anpassungen, die es den Nutzern ermöglichen, SBOM-Daten in ihre Sicherheitstools zu integrieren.
- Umgang mit Fehlern: Da sich die Verwaltung von SBOM-Daten noch in der Entwicklung befindet, sollten Anwender gegenüber gelegentlichen Fehlern tolerant sein. Lieferanten sollten aktualisierte Daten bereitstellen, sobald Probleme in früheren SBOMs festgestellt werden, und Anwender sollten diese Aktualisierungen und Korrekturen ohne Nachteile begrüßen, um eine kontinuierliche Verbesserung zu fördern.
Die Anforderungen an die SBOM werden voraussichtlich weiter zunehmen und sich weiterentwickeln. Mit aktualisierten Richtlinien könnten weitere Datenfelder sowie Sicherheitsbewertungen, Schwachstellenlisten und andere Informationen hinzukommen. Zwar sind Unternehmen lediglich verpflichtet, die Mindestanforderungen an eine SBOM zu erfüllen, doch zeugt die Aufnahme weiterer relevanter Informationen zu einem Softwareprodukt von einem starken Engagement für Transparenz und Sicherheit.
Wie sieht der Entwicklungslebenszyklus einer SBOM aus?
Im Idealfall sollten SBOMs bei jeder Bereitstellung von Software automatisch generiert werden und eine möglichst vollständige Bestandsaufnahme enthalten. Der SBOM-Lebenszyklus trägt dazu bei, indem er einen Prozess zur Identifizierung von Anwendungen, zur Erstellung von SBOMs und zu deren Bereitstellung für Endnutzer bereitstellt.
“„SBOMs sollten bei jeder Bereitstellung von Software automatisch erstellt werden und eine möglichst vollständige Bestandsaufnahme enthalten.“
Es besteht aus den folgenden fünf Phasen:
- Ermittlung der Assets –Der erste Schritt besteht darin, die Anwendung zu ermitteln, für die Sie eine SBOM bereitstellen müssen. Es wird empfohlen, ein Tool zur Erfassung von Ressourcen von zu verwenden, um einen vollständigen Überblick über alle Ihre Anwendungen zu gewährleisten.
- Anwendungsdatenanalyse –Die für die SBOM erforderlichen Anwendungsdaten werden erfasst.
- Erstellung der SBOM –Die SBOM-Datei wird erstellt und enthält alle relevanten Anwendungsdaten. Dies sollte bei jeder neuen Version der App erfolgen, um sicherzustellen, dass die SBOM stets dem aktuellen Stand der Software entspricht.
- SBOM-Speicherung –SBOMs müssen zentral und sicher unter Verwendung von Verschlüsselung gespeichert werden.
- Durchsuchbarkeit der SBOM –Der letzte Schritt besteht darin, die Suchfunktion für die SBOM sicherzustellen, damit der Endnutzer nach möglichen Schwachstellen suchen kann.
Welche SBOM-Standards gibt es?
Ein SBOM-Standard ist ein Schema zur detaillierten Darstellung der Zusammensetzung von Software in einer maschinenlesbaren Datei, die von anderen Tools wie Schwachstellenscannern und Softwarelizenz-Trackern verarbeitet werden kann. Derzeit gibt es drei wichtige Standards für die Erstellung von SBOMs und deren Weitergabe an Endnutzer:
- SPDX – „“ Der von der Linux Foundation entwickelte SPDX-Standard (Software Package Data Exchange) ist ein weit verbreitetes Format für die Übermittlung von SBOM-Daten – wie beispielsweise die Komponenten, Lizenzen, Urheberrechte und Sicherheitsinformationen einer Anwendung – in verschiedenen Dateiformaten.
- CycloneDX –CycloneDX ist ein weiterer offener Standard, der von der OWASP-Community entwickelt wurde. Es basiert auf dem SPDX-Standard, wurde jedoch im Hinblick auf eine einfachere Implementierung und Nutzung optimiert.
- SWID –SWID, die Abkürzung für „Software Identification Tags“, sind eine Art von Metadaten, die von vielen Anwendungen automatisch generiert werden können, um die Komponenten der Software zu beschreiben und in einen Kontext zu setzen.
Die NTIA hat diese drei SBOM-Standards als akzeptabel eingestuft, da sie nicht nur für Menschen lesbar, sondern auch maschinenlesbar sind und die Automatisierung unterstützen, wodurch es Endnutzern erleichtert wird, SBOMs in ihrem gesamten Unternehmen zu nutzen und zu skalieren.
[Lesen Sie auch: Die Zukunft des Risikomanagements liegt in der Automatisierung]
Welche Herausforderungen ergeben sich bei der Erstellung und Nutzung einer SBOM?
Wie bei jedem neuen System ist auch die Erstellung und Nutzung einer SBOM mit einigen Herausforderungen verbunden.
Ein wesentliches Hindernis ist die mangelnde Standardisierung. SBOMs sind wahrscheinlich am effektivsten, wenn die gesamte Lieferkette dieselben Standards, Prozesse und Werkzeuge einhält. In dieser Anfangsphase herrscht jedoch zu keinem dieser Punkte ein Konsens, und Uneinheitlichkeiten zwischen Softwareanbietern und Endnutzern sind unvermeidlich. Dies kann dazu führen, dass zusätzlicher Zeitaufwand für die Analyse und Anpassung von SBOMs an die jeweiligen Anforderungen entsteht.
“SBOMs sind wahrscheinlich am effektivsten, wenn die gesamte Lieferkette dieselben Standards, Prozesse und Werkzeuge einhält. In dieser Anfangsphase herrscht jedoch zu keinem dieser Punkte nennenswerter Konsens.”
Eine weitere Herausforderung besteht darin, dass SBOMs kontinuierlich angepasst werden müssen. Bei jeder neuen Version einer App muss eine neue SBOM enthalten sein, die den aktuellen Stand der App widerspiegelt. Daher ist es von entscheidender Bedeutung, SBOM-Management-Tools einzusetzen, die die Erstellung von SBOMs in den Lebenszyklus der Softwareentwicklung integrieren können.
Die Skalierung von SBOMs bei der Einbindung weiterer Lieferkettenpartner kann ebenfalls zu einem Problem werden, wenn Sie zur Erstellung dieser Listen herkömmliche Methoden wie Tabellenkalkulationen und E-Mail verwenden. Zudem sind diese manuellen Verfahren zeitaufwendig, fehleranfällig und können die Nachverfolgung hierarchischer Beziehungen zwischen Komponenten erschweren.
Welche bewährten Vorgehensweisen gibt es für die Erstellung einer effektiven SBOM?
Die folgenden bewährten Vorgehensweisen können Ihnen dabei helfen, aussagekräftige SBOMs zu erstellen:
- Verwenden Sie ein einheitliches Format –. Es ist wichtig, bei der Strukturierung von SBOM-Daten ein Standardformat einzuhalten. SPDX, CycloneDX und SWID sind die gängigsten Formate, doch letztendlich ist die Wahl des Formats weniger wichtig als dessen konsequente Verwendung.
- Automatisieren Sie die Erstellung von SBOMs –Die automatische Generierung von SBOMs als Teil Ihrer Software-Bereitstellungspipeline bietet zahlreiche Vorteile. In erster Linie wird dies den Entwicklern Zeit sparen, da sie nicht jede SBOM manuell erstellen müssen. Außerdem erhöht sich dadurch die Wahrscheinlichkeit, dass SBOMs zu einem festen Bestandteil Ihres Software-Bereitstellungszyklus werden. Schließlich ermöglicht es Ihnen, die in der Verordnung von Präsident Biden festgelegten Anforderungen für die Bereitstellung von IT-Dienstleistungen für die Bundesregierung zu erfüllen.
- Aktualisieren Sie die SBOMs bei jeder Veröffentlichung –Eine SBOM muss für jede Softwareversion spezifisch sein, auch wenn eine Anwendung aktualisiert wird. Automatisierung ist hier entscheidend; wenn Entwickler ihre SBOM bei jedem App-Update manuell aktualisieren müssen, ist es weitaus unwahrscheinlicher, dass dies tatsächlich geschieht.
- Fügen Sie vollständige Metadaten hinzu –Auch wenn es keine universellen SBOM-Standards gibt, sollten Sie es sich zur Gewohnheit machen, in jede SBOM so viele Metadaten wie möglich aufzunehmen. Dadurch wird der Umfang der Informationen reduziert, die Ihre Endnutzer manuell nachschlagen müssen, und Sie unterstreichen Ihr Engagement für Sicherheit und Transparenz. Außerdem erleichtert dies die Aktualisierung.
