SBOMs verstehen

In den letzten Jahren ist der Einsatz von Open-Source-Software in der Entwicklung sprunghaft angestiegen und umfasst nun bis zu 90% der entwickelten Produkte. Die Beliebtheit bei Unternehmen weltweit ist auf Kosteneinsparungen und eine schnellere Markteinführung von Produkten zurückzuführen. Bei der Integration von Open-Source-Softwarekomponenten ist jedoch ein entscheidender Aspekt zu beachten. Synopsys berichtet dass 84 % der kommerziellen und proprietären Codebasen mindestens eine bekannte Open-Source-Schwachstelle enthalten. Dies zeigt, wie wichtig es ist, die Sicherheit der von Ihnen verwendeten Open-Source-Komponenten zu gewährleisten. Und genau hier kommt eine Software Bill of Materials (SBOM) ins Spiel.

Was ist ein SBOM?

Open-Source-Komponenten und der Code von Drittanbietern können komplex sein und aus vielen Schichten bestehen. Wie russische Schachtelpuppen passen diese Teile ineinander, und jede Schicht kann ihre eigenen Regeln haben. Um sicherzustellen, dass ihre Software sicher ist, müssen Unternehmen genau wissen, was in ihr steckt.

Eine SBOM liefert detaillierte Informationen über jede Komponente. Es ist wie ein Etikett für Software, das alle Teile und ihre Beziehungen auflistet - wie eine Mischung aus Open-Source-Teilen, Teilen von Drittanbietern und dem eigenen Code des Unternehmens. Sie enthält technische Details zu jeder Komponente, einschließlich Name, Version und Lizenz. SBOMs können auch Informationen über Sicherheitsprobleme, transitive Abhängigkeiten, die Herkunft der Komponenten und andere Informationen enthalten.

In der Automobilindustrie beispielsweise erstellen die Hersteller detaillierte Spezifikationen für jedes Fahrzeug, einschließlich der Teile, die sie selbst hergestellt haben, und derjenigen, die von externen Zulieferern stammen. Wenn sich ein Teil als fehlerhaft erweist, weiß der Hersteller schnell, welche Fahrzeuge betroffen sind. Auf diese Weise können sie die Besitzer über notwendige Reparaturen oder den Austausch von Teilen informieren. Diese Art der klaren Aufzeichnung ist wichtig, um herauszufinden, woher die Mängel kommen und wie sie effektiv behoben werden können.

Mindestdatenanforderungen 

In den USA übernehmen Softwareentwickler zunehmend die Software Bill of Materials (SBOM), beeinflusst durch neue staatliche Informationssicherheitsrichtlinien, die strengere Software-Sicherheitsmaßnahmen vorschreiben.

Die Präsidialverordnung Verordnung Nr. 14028die am 12. Mai 2021 zur "Verbesserung der Cybersicherheit der Nation" erlassen wurde, legt spezifische Standards für Informationssysteme des Bundes fest. Ein wichtiger Aspekt dieser Anordnung, der in Abschnitt 4 näher erläutert wird, ist die Formulierung von Richtlinien für sichere Softwareentwicklung und Beschaffungspraktiken. In dem Dokument wird SBOM als entscheidendes Element zur Gewährleistung der Softwareintegrität und zur Bewältigung der mit der Softwarelieferkette verbundenen Risiken anerkannt.

Im Einklang mit der Executive Order Nr. 14028 haben das US-Handelsministerium und die National Telecommunications and Information Administration (NTIA) Mindestdatenanforderungen für Softwarekomponenten festgelegt, die in drei Hauptgruppen eingeteilt sind:

1. Datenfelder enthalten wichtige Informationen über jede Softwarekomponente, wie z. B.:

• • Name des Lieferanten: Der Name einer Einheit, die Komponenten erstellt, definiert und identifiziert.
  • Name der Komponente: Bezeichnung, die einer vom ursprünglichen Anbieter definierten Softwareeinheit zugewiesen wird.
  • Version der Komponente: Kennung, die vom Lieferanten verwendet wird, um eine Änderung der Software gegenüber einer zuvor identifizierten Version anzugeben.

• Andere eindeutige Bezeichner: Andere Identifikatoren, die zur Identifizierung einer Komponente verwendet werden oder als Nachschlageschlüssel für relevante Datenbanken dienen.

• Abhängigkeitsverhältnis: Kennzeichnet die Beziehung zwischen einer vorgelagerten Komponente X und einer Software Y.
• Autor von SBOM Data: Der Name der Entität, die die SBOM-Daten für diese Komponente erstellt.
• Zeitstempel: Aufzeichnung von Datum und Uhrzeit der SBOM-Datenmontage.

1. Unterstützung der Automatisierung erleichtert die automatische Generierung von SBOMs und die Maschinenlesbarkeit, um eine Skalierung über das Software-Ökosystem hinweg zu ermöglichen. Außerdem sollten SBOMs in einem der folgenden drei Formate erstellt werden:

• Softwarepaketdatenaustausch (SPDX)
• CycloneDX
• Software-Identifikations-Tags (SWID)

Softwarepaketdatenaustausch (SPDX)

Dieses Format wird häufig für die Dokumentation von Informationen über Softwarelizenzen und -komponenten verwendet. SPDX wurde von der Linux Foundation entwickelt und standardisiert die Art und Weise, wie Unternehmen die in ihren Produkten verwendeten Softwarekomponenten und -lizenzen kommunizieren, und vereinfacht so die Einhaltung von Vorschriften.

CycloneDX

CycloneDX ist ein leichtgewichtiges SBOM-Format, das in erster Linie auf die Sicherheit ausgerichtet ist und für den Einsatz im Kontext der Anwendungssicherheit und der Analyse von Komponenten in der Lieferkette entwickelt wurde. Es bietet eine Standardmethode zur Darstellung der Komponenten, Bibliotheken und Module in einer Anwendung, zusammen mit den damit verbundenen Sicherheitsrisiken und der Lizenzierung.

Software-Identifikations-Tags (SWID)

SWID-Tags wurden von der Internationalen Organisation für Normung (ISO) entwickelt und sind XML-Strukturen, die eine eindeutige Identifizierung von Softwareprodukten ermöglichen. Sie helfen bei der Verwaltung des Softwarebestands und der Einhaltung von Lizenzen. SWID-Tags sind besonders nützlich für die Verwaltung von Softwarebeständen und für Zwecke der Cybersicherheit.

• Praktiken und Prozesse die befolgt werden müssen, um SBOM in den Lebenszyklus der sicheren Entwicklung zu integrieren. Dazu gehören die Festlegung einer Häufigkeit für SBOM-Aktualisierungen, die Definition der Tiefe von Abhängigkeitsstrukturen, der Umgang mit SBOM-Elementen mit unsicheren oder unvollständigen Abhängigkeitsinformationen und die Festlegung von Richtlinien für die Verteilung, Bereitstellung und Zugriffskontrolle.

SBOM Anwendungsfälle

SBOM-Anwendungsfälle lassen sich grob in drei Hauptkategorien einteilen:

• Erkennung und Verwaltung von Schwachstellen: SBOM hilft dabei, den Überblick über alle Code-Komponenten zu behalten. Wenn eine kritische Schwachstelle gefunden wird, können Sicherheitsteams das SBOM schnell nutzen, um das Problem im Code zu lokalisieren, seine Auswirkungen zu verstehen und Prioritäten für die Behebung zu setzen. Zum Beispiel, TuxCare's SecureChain für Java eine detaillierte SBOM für jedes Java-Paket, das der Service überprüft und gepatcht hat, was eine vollständige Transparenz für fundierte Entscheidungen gewährleistet.
• Software-Lizenzverwaltung: Mit einem SBOM können Unternehmen leicht den Überblick über die Lizenzen für Drittanbieter- und Open-Source-Software behalten. Da sich Lizenzen häufig ändern, sind regelmäßige Überprüfungen erforderlich. So kann das Unternehmen sicherstellen, dass es keine Lizenzvereinbarungen oder Rechte an geistigem Eigentum verletzt und rechtliche Probleme und finanzielle Risiken vermeidet.
• Verbesserung des Lebenszyklus der Softwareentwicklung (SDLC): SBOM macht den gesamten Prozess der Erstellung, Bereitstellung und Wartung von Software effizienter. Beispielsweise listen die Entwickler beim Schreiben des Codes alle Software-Abhängigkeiten in einer ersten SBOM auf. Diese SBOM wird während der Test- und Bereitstellungsphase aktualisiert, wenn neue Schwachstellen und Abhängigkeiten gefunden werden. Außerdem werden die Entwickler auf Probleme aufmerksam gemacht, die nach dem Einsatz der Software auftreten, so dass kontinuierliche Aktualisierungen und Verbesserungen gewährleistet sind.

Die Zukunft der SBOM

SBOM ist besonders wichtig für Unternehmen, die Software an staatliche Stellen liefern, vor allem in Bereichen wie Verteidigung und Luft- und Raumfahrt. Ihre Bedeutung erstreckt sich jedoch auch auf andere Unternehmen.

Die jüngste Zunahme von Angriffen auf die Lieferkette, bei denen häufig Open-Source-Schwachstellen ausgenutzt werden, unterstreicht, wie wichtig es ist, Open-Source-Komponenten, -Bibliotheken und -Frameworks von Drittanbietern gründlich zu prüfen. Diese Angriffe können es böswilligen Akteuren ermöglichen, die vollständige Kontrolle über die Systeme eines Unternehmens zu übernehmen, die Produktfunktionalität zu stören, Malware einzuschleusen und sogar Viren an Kunden und andere interagierende Organisationen zu verbreiten. Die unvorhersehbaren und potenziell weitreichenden Auswirkungen solcher Angriffe machen sie zu einer erheblichen Bedrohung.

Gartner prognostiziert dass bis 2025 60 % der Unternehmen SBOM in ihre Sicherheitssysteme einbauen werden. SBOM ist zwar nützlich, aber kein Allheilmittel für die Herausforderungen der Software-Lieferkette und der Software-Sicherheit, wie die NTIA anerkennt. Es ist eines von vielen Instrumenten, keine allumfassende Lösung. Die Effektivität von SBOMs hängt von der weit verbreiteten Annahme ab, die noch im Gange ist, da sich die Standards und Anforderungen weiterentwickeln. Angesichts der Vielzahl von Tools und Standards, die derzeit entwickelt werden, wird es einige Zeit dauern, bis sie allgemein eingesetzt werden.

Zusammenfassung

Artikel Name

SBOMs verstehen

Beschreibung

In unserem Leitfaden erfahren Sie mehr über die Rolle von SBOM bei der Verbesserung der Softwaresicherheit, die Übereinstimmung mit der US-Politik, wichtige Anwendungsfälle und zukünftige Trends.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers