Die mindestens erforderlichen Elemente für eine Software-Stückliste (SBOM)

Die Entwicklung sicherer Softwareprodukte oder -anwendungen in diesem Zeitalter erfordert umfassende Kenntnisse der genauen Komponenten der Anwendung, die Sie erstellen. Die Abhängigkeiten, Lizenzen, Dateien und anderen Vermögenswerte, aus denen Ihr Softwarepaket besteht, stellen potenzielle Schwachstellen dar, über die böswillige Akteure einen Angriff auf Ihre Software und andere Anwendungen entlang der Lieferkette starten können.

Im Rahmen der Bemühungen zur Bekämpfung der jüngsten Zunahme der Häufigkeit und Auswirkung von Angriffe auf SoftwarelieferkettenDie Bundesregierung hat in Abstimmung mit der NTIA eine Durchführungsverordnung erlassen, in der verschiedene Maßnahmen zur Verbesserung der Cybersicherheit und zur Gewährleistung der Integrität von in Softwarepaketen verwendeten Komponenten Dritter detailliert aufgeführt sind. Eine solche Maßnahme ist die Software-Stückliste. 

Hierbei handelt es sich um ein formelles Dokument, das alle Komponenten eines Softwarepakets und die Lieferkettenbeziehungen zwischen diesen Komponenten enthält. Die Erstellung einer umfassenden Software-Stückliste ist nicht nur gängige Praxis, sondern auch gesetzlich vorgeschrieben. Dieser Beitrag definiert den Umfang der Software-Stückliste und der minimale Elemente Dies muss in einer umfassenden Stückliste enthalten sein.

Was bieten die Mindestkomponenten einer SBOM von NTIA?

Die SBOM dient als formeller Leitfaden für Unternehmen, die Software entwickeln, kaufen oder betreiben, und stellt alle Informationen bereit, die sie benötigen, um ihr Verständnis der Software-Lieferkette zu verbessern. Es hilft auch, neu auftretende Schwachstellen leicht aufzuspüren, falls sie auftreten Reduzieren Sie Risiken in der Software-Lieferkette. Damit die SBOM jedoch den festgelegten Anforderungen der Bundesregierung gerecht wird, sollten einige grundlegende Elemente darin enthalten sein. Diese Elemente werden häufig in drei Kategorien eingeteilt:

•  Datenfelder: Von einer SBOM wird erwartet, dass sie wichtige Daten über Softwarekomponenten bereitstellt, beispielsweise den Namen der Komponente, den Namen des Lieferanten, die Softwareversion und andere eindeutige Kennungen. Es sollte auch die Beziehungen zwischen Abhängigkeiten detailliert beschreiben. Diese Daten ermöglichen es, alle Softwarekomponenten genau zu identifizieren und sie entlang der Software-Lieferkette aufzuspüren.
• Automatisierungsunterstützung: Die Software-Stückliste sollte maschinenlesbar und auch automatisch erzeugbar sein. Dies ermöglicht eine kontinuierliche Verfolgung der in der SBOM enthaltenen Daten. Normalerweise liegen diese Dokumente in Standardformaten wie SPDX, CycloneDX und SWID-Tags vor und sind daher auch für Menschen lesbar.
• Praktiken und Prozesse: Von der SBOM-Dokumentation wird außerdem erwartet, dass sie die Standardpraktiken und -prozesse für die Erstellung und Aktualisierung der SBOM detailliert beschreibt. Es sollte auch Praktiken für die Verteilung und den Zugriff auf die SBOM sowie Maßnahmen für den Umgang mit zufälligen Fehlern umfassen.

Die von NTIA mindestens erforderlichen Elemente der SBOM-Dokumentation bieten ein klares Kriterium dafür, was in einer SBOM-Richtlinie für die grundlegenden Anwendungsfälle Ihrer Software-Stückliste erwartet wird, wie z. B. die Verwaltung von Schwachstellen, die Bestandsaufnahme von Softwarekomponenten und die Verwaltung von Softwarelizenzen. Das Framework wird aktualisiert und kann in naher Zukunft zusätzliche Elemente enthalten, die seine Benutzerfreundlichkeit erweitern. In den folgenden Abschnitten dieser Seite werden wir diese Schlüsselkomponenten Ihrer Software-Stückliste ausführlicher erläutern. Zu den mindestens erforderlichen Elementen einer Software-Stückliste gehören sieben Datenfelder, wie unten angegeben.

Datenfelder: Mindestanforderungen

Der Zweck der Software-Stückliste besteht darin, Informationen bereitzustellen, die Benutzern und anderen Beteiligten dabei helfen, Softwarekomponenten leicht zu identifizieren. Eines der ersten und wichtigsten Elemente der SBOM sind voraussichtlich die Daten, die für jede im Dokument aufgeführte Komponente enthalten sein sollten. Die Daten helfen nicht nur bei der Identifizierung einzelner Komponenten, sondern erleichtern auch die Nachverfolgung der Komponenten an den verschiedenen Stellen in der Software-Lieferkette, an denen sie verwendet werden.

• Name des Anbieters: Der Lieferant ist der Urheber bzw. Hersteller der betreffenden Softwarekomponente. Dies ist der Name der Person oder Organisation, die die Softwarekomponenten erstellt, definiert und identifiziert.
• Komponentenname: Dies bezieht sich auf den der Software zugewiesenen Namen, wie er vom ursprünglichen Lieferanten oder Hersteller definiert wurde. In Fällen, in denen es mehrere Namen und Aliase für die Software gibt, können diese ebenfalls vermerkt werden.
• Komponentenversion: Die SBOM sollte die vom Lieferanten oder Hersteller angegebene Versionsnummer oder Kategorienummer enthalten. Die Versionsdaten dienen als Kennung, die jede Änderung der Software gegenüber einer zuvor identifizierten Version der nachfolgenden Version der Software angibt.
• Andere eindeutige Identifikatoren: Dies bezieht sich auf zusätzliche Identifikatoren neben dem Komponentennamen und der Version. Diese zusätzlichen Kennungen stellen eine zusätzliche Identifikationsebene für die Komponente dar und können auch als Suchschlüssel zum Auffinden der Komponente in relevanten Datenbanken verwendet werden.
• Abhängigkeitsbeziehung: Dies ist eine der wichtigsten Datenkomponenten einer Software-Stückliste, da die SBOM genau beschreiben soll, wie Softwarekomponenten zusammenpassen. Die Abhängigkeitsbeziehung gibt die Beziehung zwischen der in Ihrer Anwendung verwendeten Software X und ihren Upstream-Komponenten an.
• Autor der SBOM-Daten: Dies bezieht sich auf die Person, die die SBOM-Daten erstellt hat. Manchmal fungiert der Softwarelieferant auch gleichzeitig als Autor. In vielen Fällen ist der Autor jedoch eine andere Einzelperson oder Gruppe.

Automatisierungsunterstützung: Mindestanforderungen

Der Einsatz der Software Bill of Materials geht oft über Unternehmensgrenzen hinweg. Dies bedeutet, dass die in der SBOM enthaltenen Daten häufig von mehreren Abteilungen innerhalb einer Organisation und auch von mehreren Organisationen verwendet werden. Um die Benutzerfreundlichkeit dieser Dokumentation zu gewährleisten, empfiehlt die NTIA, dass die SBOM in einem Format vorliegen sollte, das sowohl maschinenlesbar als auch für Menschen lesbar ist. Die Vorbereitung und Übermittlung der SBOM in automatisierten Standardformaten wie diesem verbessert die Interoperabilität dieses Dokuments für seine verschiedenen beabsichtigten Zwecke.

Die NTIA kennt drei Lieferformate für die Generierung und Übermittlung von SBOMs. Ihre Software-Stückliste sollte einem dieser Formate entsprechen, um den darin festgelegten Standards zu entsprechen Cybersicherheitsverordnung der Regierung. Zu diesen Standardformaten gehören:

• Softwarepaket-Datenaustausch (SPDX)
• Software-Identifikations-Tags (SWID).
• CycloneDX

Softwarepaket-Datenaustausch (SPDX)

Der SPDX ist ein offener Standard für die Bereitstellung von SBOM-Daten. Es erfasst wichtige Informationen über die Software, einschließlich ihrer Komponenten, Herkunft, Lizenzen und Urheberrechte. Es enthält auch Sicherheitshinweise. Der SPDX Version 2.2 ist die aktuellste Version und unterstützt den Dateityp YAML 1.2, JavaScript Object Notation und Resource Description Framework (RDF/XML). Tag: Wert-Flachtextdatei und XLS-Tabellen

Software-Identifikations-Tags (SWID).

SWID-Tags sollen dabei helfen, die Komponenten eines Softwareprodukts zu identifizieren und zu kontextualisieren. Das Software Identification Tags-Projekt (SWID Tags) ist eine Reihe von Tools zum Generieren und Validieren der Identifikations-Tags einer Software. Diese Java-basierten Tools unterstützen XML-SWID-Tags, die auf dem standardisierten Format gemäß ISO/IEC 19770-2:2015 und Concise Binary Object Representation (CBOR) basieren. Der NIST hat eine Website mit einer Liste hilfreicher Ressourcen für:

• Erstellen von SWID- und CoSWID-Tags
• Validierung von SWID- und CoSWID-Tags basierend auf spezifischen Schemaanforderungen und Best-Practice-Richtlinien
• Eine Web-App, die einen SWID-Tag-Validierungsdienst bereitstellt, der auf einem Java-Anwendungsserver bereitgestellt werden kann
• SWID-Repo-Client zum Posten von Tags in der National Vulnerability Database

CycloneDX

CycloneDX behauptet, ein „leichtgewichtiger Software Bill of Materials (SBOM)-Standard“ zu sein. Es ist nützlich für die Analyse von Lieferkettenkomponenten und die Anwendungssicherheit. Unternehmen, die CycloneDX einführen, können die SBOM-Mindestanforderungen nahtlos erfüllen und sich im Laufe der Zeit zu anspruchsvolleren Anwendungsfällen der SBOM-Dokumentation entwickeln.

CycloneDX-SBOMs werden normalerweise in den Formaten XML, JSON oder Protocol Buffers dargestellt. Die Spezifikation umfasst häufig diese fünf Felder:

• Die Stücklisten-Metadaten: Dazu gehören allgemeine Informationen über die Anwendung oder das Softwareprodukt selbst.
• Komponenten: Hierbei handelt es sich um ein umfassendes Inventar, das alle proprietären und Open-Source-Komponenten der Software abdeckt.
• Dienstinformationen: Hier werden alle externen APIs aufgeführt, die die Anwendung während ihres Betriebs wahrscheinlich aufrufen wird. Es umfasst alle Endpunkt-URLs, Authentifizierungsanforderungen und Vertrauensgrenzenüberschreitungen.
• Abhängigkeiten: Die Dokumentation beschreibt außerdem alle Komponenten und Dienste im Softwarepaket. Dies umfasst sowohl direkte als auch transitive Beziehungen.
• Zusammensetzungen: Damit ist die Vollständigkeit aller Bestandteile einschließlich der einzelnen Komponenten, Dienste und Abhängigkeitsbeziehungen gemeint. Jede Komposition wird typischerweise danach beschrieben, ob sie vollständig, unvollständig, unvollständig, nur für Erstanbieter, unvollständig, nur für Dritte oder völlig unbekannt ist.

Praktiken und Prozesse: Mindestanforderungen

Das letzte Element Ihrer Software-Stückliste konzentriert sich auf die Mechanismen der SBOM-Nutzung selbst. Die Praktiken und Prozesse decken die betrieblichen Details der Erstellung und Nutzung der SBOM ab und müssen in jede Richtlinie oder jeden Vertrag aufgenommen werden, der dies verlangt. Im Folgenden sind die wichtigsten Anforderungen aufgeführt, die im Abschnitt „Praktiken und Prozesse“ Ihrer Software-Stückliste detailliert beschrieben werden müssen:

• Frequenz: In diesem Abschnitt wird detailliert beschrieben, wie oft eine Organisation eine neue Softwarerechnung für Materialien erstellen muss. Im Allgemeinen empfiehlt die NTIA, dass Sie immer dann eine neue SBOM erstellen, wenn Ihre Softwarekomponente aktualisiert oder eine neue Version veröffentlicht wird. Von den Lieferanten wird außerdem erwartet, dass sie immer dann neue SBOMs erstellen, wenn sie einen Fehler in der Originalversion finden oder neue Details über die Komponenten ihrer Software erfahren, die nicht in der ursprünglichen Dokumentation enthalten waren.
• Tiefe: Die Tiefe Ihrer SBOM hängt davon ab, was im Dokument enthalten ist. Um konform zu sein, wird erwartet, dass Ihre SBOM alle Komponenten der obersten Ebene und alle transitiven Abhängigkeiten enthält. In Situationen, in denen der Autor nicht in der Lage ist, alle transitiven Abhängigkeiten einzubeziehen, sollte das Dokument den Verbraucher darüber informieren, wo er sie finden kann.
• Es gibt Fälle, in denen der SBOM-Autor aus dem einen oder anderen Grund kein vollständiges Abhängigkeitsdiagramm bereitstellen kann. Dies kann daran liegen, dass die Komponente keine weiteren Abhängigkeiten hat oder sie nicht wissen, ob diese Abhängigkeiten existieren oder nicht. Der SBOM-Autor muss diesen Grund angeben.
• Vertrieb und Lieferung: Das Ziel dieser Anforderung besteht darin, sicherzustellen, dass SBOMs schnell und in einem leicht verständlichen Format bereitgestellt werden. Obwohl diese Anforderung nicht die Anzahl der Tage oder Wochen angibt, in denen SBOMs geliefert werden sollen, sollten sie so schnell wie möglich eingereicht werden. Außerdem sollten für die SBOM bei der Auslieferung entsprechende Rollen und Zugriffsberechtigungen festgelegt sein. Schließlich legt die Anforderung fest, dass die SBOM entweder mit jeder Instanz des Produkts verteilt oder auf andere leicht zugängliche Weise, beispielsweise über eine öffentliche Website, verfügbar gemacht werden kann.
• Zugangskontrolle: In Fällen, in denen der Lieferant beschließt, den Zugriff auf die SBOM-Daten auf bestimmte Benutzer oder Kunden zu beschränken, muss der Autor die Bedingungen der Zugriffskontrolle festlegen. Es besteht auch die Notwendigkeit, Verbrauchern, die die SBOM-Daten in ihre eigenen Sicherheitstools integrieren möchten, spezifische Möglichkeiten anzubieten.
• Kompensation von Fehlern: SBOM kann dazu beitragen, die Softwaresicherheit zu verbessern und Risikomanagement in der Software-Lieferkette. Allerdings ist es noch lange nicht perfekt. Daher müssen Verbraucher gegenüber gelegentlichen unbeabsichtigten Fehlern oder Auslassungen, die bei der Erstellung von SBOMs auftreten können, tolerant sein. 

Über die Mindestanforderungen von NTIA hinaus denken

Bisher haben wir die Mindestelemente besprochen, die in Ihrer Software-Stückliste erforderlich sind. Diese Mindestelemente stellen die empfohlenen Anforderungen dar, insbesondere für die grundlegendsten Anwendungsfälle dieser Dokumentation. Obwohl sie eine gute Grundlage für Softwareherkunft und -sicherheit bilden, muss man über diese Anforderungen hinausblicken. Im Folgenden finden Sie einige Empfehlungen, die Sie für fortgeschrittenere SBOM-Anwendungsfälle berücksichtigen sollten.

Zusätzliche Datenfelder

Zusätzlich zu den im Mindestanforderungsdokument abgedeckten Datenfeldern gibt es weitere Datenfelder, die für Fälle empfohlen werden, in denen ein höheres Maß an Sicherheit erforderlich ist. Einige dieser zusätzlichen Datenfelder umfassen:

• Ein kryptografischer Hash der Softwarekomponenten
• Daten zur Software-Lebenszyklusphase
• Beziehungen zwischen anderen Komponenten
• Lizenzinformationen

Cloudbasierte Software und Software-as-a-Service

Ein weiterer potenzieller Bereich, in dem die SBOM-Anforderungen über die Grundlagen hinausgehen könnten, ist die Verwaltung von Software-as-a-Service-Produkten (SaaS). Diese Art von Softwareprodukten stellt hinsichtlich der SBOM-Daten besondere Herausforderungen dar. Zunächst einmal sind die Sicherheitsrisiken im Cloud-Kontext einzigartig. Auch die Verantwortung für den Umgang mit diesen Risiken liegt beim Dienstleister. Auch die Erstellung der SBOM-Dokumentation für cloudbasierte Software ist komplexer, da diese tendenziell einen kürzeren Veröffentlichungszyklus haben.

SBOM Integrität und Authentizität

Ein weiteres erwähnenswertes Problem ist der Prozess der Authentifizierung der Quelle der SBOM-Daten selbst. Derzeit sind Signaturen und Public-Key-Infrastrukturen die bevorzugten Lösungen zur Überprüfung der Integrität von Software in der heutigen digitalen Welt. Autoren und Lieferanten von SBOMs müssen möglicherweise diese vorhandenen Softwaresignaturen nutzen, um die Zuverlässigkeit der SBOM-Daten zu verbessern.

Sicherheitslücke und Ausnutzbarkeit in Abhängigkeiten

Obwohl der Zweck von SBOMs darin besteht, die Erkennung von Schwachstellen zu erleichtern, ist es wichtig zu beachten, dass nicht alle Schwachstellen in Abhängigkeiten große Risiken für Software darstellen, die auf ihnen basiert. Um Zeit- und Ressourcenverschwendung zu vermeiden, müssen Softwarelieferanten Maßnahmen ergreifen, um die potenziellen Auswirkungen einer Abhängigkeitsschwachstelle auf Software zu ermitteln, die nachgelagert verwendet wird, und den Benutzern des SBOM das Risikoniveau (oder in diesem Fall das Fehlen davon) mitzuteilen Daten nachgelagert.

Flexibilität vs. Einheitlichkeit in der Umsetzung

Wenn es um Softwaresicherheit geht, steht immer die Frage nach Flexibilität und Einheitlichkeit im Vordergrund. Dies gilt auch für fortgeschrittene Anwendungsfälle von SBOMs. Um SBOMs erfolgreich umzusetzen, sind umfassende Richtlinien erforderlich, die für alle Bereiche sowie für bestimmte Fälle gelten, in denen Flexibilität erforderlich ist.