Verwendung einer Software-Stückliste (SBOM) als Teil Ihres Risikomanagementprogramms für Drittanbieter

Eine Software-Stückliste (SBOM) ist eine strukturierte Liste von Komponenten und Abhängigkeiten, aus denen eine Softwareanwendung oder ein System besteht. SBOMs enthalten Informationen wie die Namen und Versionen aller Komponenten, die Beziehungen zwischen ihnen und ihre Lizenz- und Schwachstelleninformationen.

Die Entwicklung von SBOMs lässt sich auf die zunehmende Komplexität von Softwareanwendungen und die wachsenden Bedenken hinsichtlich der Sicherheit der Software-Lieferkette zurückführen. Da Softwareanwendungen immer komplexer werden und auf Komponenten von Drittanbietern angewiesen sind, wird es für Entwickler und Sicherheitsteams immer schwieriger, die Abhängigkeiten zwischen den Komponenten zu verfolgen und zu verwalten.

Mehrere öffentlichkeitswirksame Sicherheitsvorfälle, wie der SolarWinds-Hack, haben die Notwendigkeit einer größeren Transparenz und Verantwortlichkeit in Software-Lieferketten deutlich gemacht. Dies hat dazu geführt, dass SBOMs als Mittel zur Verbesserung der Softwaresicherheit zunehmend an Interesse und Akzeptanz gewinnen. Die US-Regierung setzt sich sogar für SBOMs ein, und sie könnten in naher Zukunft zu einem führenden Element der Überwachung und Berichterstattung des Risikomanagements durch Dritte werden.

In diesem Beitrag wird untersucht, wie sich SBOMs auf das Risikomanagement von Drittanbietern anwenden lassen, es werden die jüngsten Standardisierungsbemühungen untersucht und es werden Best-Practice-Empfehlungen für den Einstieg gegeben.

Anwendung der SBOMs auf das Risikomanagement von Drittparteien

SBOMs haben mehrere Anwendungen in der Verwaltung von Dritten, einschließlich:

• Risikomanagement: SBOMs können verwendet werden, um die mit den Komponenten von Drittanbietern in einer Softwareanwendung verbundenen Risiken zu ermitteln und zu bewerten. Durch die Analyse der SBOM können Sicherheitsteams Schwachstellen erkennen und feststellen, ob die Komponenten auf dem neuesten Stand und richtig konfiguriert sind.
• Einhaltung von Vorschriften: In vielen Branchen, z. B. im Gesundheitswesen und bei Finanzdienstleistungen, gelten strenge Compliance-Anforderungen, die auch Softwarekomponenten von Drittanbietern umfassen. Mit SBOMs lässt sich sicherstellen, dass alle Komponenten diese Anforderungen erfüllen und ordnungsgemäß lizenziert sind.
• Verwaltung der Lieferkette: SBOMs können zur Verwaltung der Software-Lieferkette verwendet werden, indem die Herkunft und der Eigentümer jeder Komponente identifiziert werden. Auf diese Weise können Unternehmen sicherstellen, dass sie nur Komponenten aus vertrauenswürdigen Quellen verwenden und alle Änderungen oder Aktualisierungen der Komponenten verfolgen.

Da die Komplexität von Softwareanwendungen immer weiter zunimmt, ist es unerlässlich, dass Unternehmen ein klares Verständnis für ihre Softwarekomponenten und die damit verbundenen Risiken haben. SBOMs bieten eine strukturierte Möglichkeit, diese Transparenz und Verantwortlichkeit zu erreichen.

Initiativen mit SBOM-Anforderungen

SBOMs gibt es zwar schon seit einiger Zeit, aber ihre Akzeptanz hat zugenommen, da Cybersecurity-Bedrohungen und Vorschriften proaktivere Ansätze für das Management von Risiken Dritter erforderlich machen. Die Zukunft von SBOMs für das Risikomanagement von Drittanbietern sieht vielversprechend aus, da immer mehr Unternehmen die Bedeutung des Risikomanagements in der Software-Lieferkette erkennen. In der Tat gibt es bereits Initiativen, die SBOMs für bestimmte Softwaretypen vorschreiben. Hier sind zwei Beispiele:

• Nationale Telekommunikations- und Informationsbehörde (NTIA): Die National Telecommunications and Information Administration (NTIA) in den Vereinigten Staaten war federführend bei der Entwicklung eines standardisierten SBOM-Formats, das bei Branchenführern und Regulierungsbehörden Anklang gefunden hat. Darüber hinaus hat die Cybersecurity and Infrastructure Security Agency (CISA) vor kurzem einen Leitfaden herausgegeben, in dem empfohlen wird, dass Unternehmen SBOMs als Teil ihrer Software-Lieferketten-Risikomanagement-Praktiken einbeziehen und sich dabei auf die Empfehlungen der NTIA beziehen.
• Durchführungsverordnung zur Verbesserung der Cybersicherheit der Nation: US-Präsident Biden hat eine Durchführungsverordnung erlassen und ein aktualisiertes Strategiepapier zur Cybersicherheit veröffentlicht, das SBOMs für alle an die Regierung verkaufte Software vorschreiben würde.

SBOM-Formate und Standards

Ein Problem bei der Einführung von SBOMs ist die fehlende Standardisierung. Derzeit gibt es einige unterschiedliche Industriestandards für SBOM.

• CycloneDX SBOM: Einer der am weitesten verbreiteten und akzeptierten Standards ist das CycloneDX SBOM-Format, ein offener Standard, der vom CycloneDX-Projekt entwickelt wurde. Das CycloneDX-Format ist so konzipiert, dass es einfach zu verwenden und zu implementieren ist, und es bietet Unterstützung für eine Vielzahl von Softwarekomponenten und Paketmanagern.
• SPDX: Ein weiteres weit verbreitetes SBOM-Format ist SPDX (Software Package Data Exchange), das von der SPDX-Arbeitsgruppe der Linux Foundation gepflegt wird. SPDX ist ein offener Standard für die Beschreibung von Softwarepaketen und ihren zugehörigen Metadaten, einschließlich Lizenzinformationen und Copyright-Erklärungen.
• SWID-Tags: SWID-Tags (Software Identification Tags) sind ein standardisiertes Verfahren zur Identifizierung von Softwarekomponenten und den zugehörigen Metadaten.
• BOMXML: BOMXML ist ein XML-basiertes Format zur Beschreibung von Softwarekomponenten und deren Beziehungen.

Insgesamt kann die Wahl des SBOM-Formats von den spezifischen Bedürfnissen und Anforderungen der Organisation oder Branche abhängen, die es verwendet, sowie von den Werkzeugen und Systemen, die zur Erzeugung und Nutzung der SBOM-Daten eingesetzt werden. Dies erhöht die Komplexität für Risikoteams und Technologien von Drittanbietern, da sie möglicherweise mehrere Formate verarbeiten, interpretieren und analysieren müssen.

Wie Sie SBOM in Ihr Risikomanagementprogramm für Dritte einbeziehen

Ungeachtet der damit verbundenen Komplexität wird die Verwendung von SBOMs voraussichtlich zunehmen. In dem Maße, in dem ihre Verwendung zunimmt, ist es wahrscheinlich, dass sie zu einem Standardbestandteil der Risikomanagementpraktiken für Dritte werden. Unternehmen werden SBOMs nutzen können, um Schwachstellen in der Software von Drittanbietern zu identifizieren und proaktive Schritte zur Abschwächung dieser Risiken zu unternehmen. Darüber hinaus können die Aufsichtsbehörden von den Unternehmen verlangen, SBOMs als Teil ihrer Compliance-Anforderungen bereitzustellen. Im Folgenden finden Sie einige Empfehlungen für die Berücksichtigung von SBOMs als Bestandteil der Sorgfaltspflicht gegenüber Dritten:

1. Verlangt von den Anbietern die Bereitstellung von SBOMs: Verlangen Sie im Rahmen der Due-Diligence-Prüfung von den Anbietern, dass sie aktualisierte SBOMs für ihre Softwareprodukte bereitstellen. Auf diese Weise können Sie potenzielle Schwachstellen oder Lizenzierungsprobleme erkennen, die sich auf die Sicherheit und Compliance Ihres Unternehmens auswirken können.
2. Bewerten Sie das Risiko von Drittanbietern: Die Verwendung einer SBOM zur Bewertung der mit der Software von Drittanbietern verbundenen Risiken hilft Ihnen bei der Ermittlung der Komponenten, die möglicherweise eine zusätzliche Prüfung oder Maßnahmen zur Risikominderung erfordern.
3. Bewertung der Lizenzkonformität: SBOMs können genutzt werden, um die Übereinstimmung von Softwarekomponenten von Drittanbietern mit den Lizenzanforderungen zu bewerten und Lizenzverletzungen zu vermeiden.
4. Überwachung auf Schwachstellen: Verwenden Sie ein SBOM, um nach Schwachstellen in Softwarekomponenten von Drittanbietern zu suchen, potenzielle Sicherheitsrisiken zu erkennen und proaktive Maßnahmen zur Risikominderung zu ergreifen.
5. Entwicklung von Plänen zur Risikominderung: SBOMs können Sie bei der Entwicklung von Risikominderungsplänen unterstützen und potenzielle Sicherheits- oder Compliance-Probleme angehen, bevor sie zu einem Problem werden.
6. SBOMs aktuell halten: Stellen Sie sicher, dass die SBOMs auf dem neuesten Stand gehalten werden, wenn neue Softwarekomponenten hinzugefügt und bestehende Komponenten aktualisiert werden. So erhalten Sie einen genauen und umfassenden Überblick über die Software-Abhängigkeiten in Ihrem Unternehmen.

Wenn Sie diese Empfehlungen in Ihren Due-Diligence-Prozess für Drittanbieter einbeziehen, können Sie sicherstellen, dass Ihr Unternehmen die mit Softwarekomponenten von Drittanbietern verbundenen Risiken effektiv verwalten kann.

Bei Prevalent unterstützen wir SBOM-Dateien als Beweismittel im Rahmen des Due-Diligence-Prozesses. Wenn Sie mehr darüber erfahren möchten, wie wir Ihnen helfen können, SBOMs in Ihre TPRM-Programmstrategie einzubinden, fordern Sie noch heute eine Demo an.