Warum Unternehmen nicht auf die Software Bill of Materials (SBOM) verzichten sollten
Eine SBOM erlaubt es Lieferanten und Anbietern von Softwareprodukten, branchenspezifische Vorgaben, Gesetze und Compliance-Vorschriften einzuhalten sowie die Leistungen für ihre Kunden genau zu definieren. Kommt es zu Cyberangriffen auf ein Produkt ohne SBOM, drohen hohe Strafen und weitere Konsequenzen wie etwa der Vertrauensverlust von Kunden oder finanzielle Einbußen. Ohne SBOM ist es schwierig bis unmöglich, die Einhaltung gesetzlicher und regulatorischer Anforderungen sicherzustellen.
Eine Software Bill of Materials (SBOM) bietet eine detaillierte Auflistung aller Komponenten und deren Versionen, die in einer Software enthalten sind. Diese Transparenz hilft zu verstehen, welche Teile der Software von Drittanbietern stammen und welche proprietär sind. Die SBOM inventarisiert selbst entwickelten Code genauso wie Open-Source-Komponenten und Software von Drittanbietern. Durch diese eindeutige Dokumentation sämtlicher Softwarekomponenten können Sicherheitslücken schneller erkannt und behoben werden. Wird also beispielsweise eine Sicherheitslücke in einer bestimmten Komponente bekannt, lassen sich mithilfe einer SBOM die betroffenen Systeme schnell identifizieren.
Über den gesamten Lebenszyklus eines Produktes ist damit klar ersichtlich, welche Softwareversionen enthalten sind, wie die Lizenzierung dieser Komponenten gehandhabt wird, wer die Komponente entwickelt hat und natürlich Zeitstempel der verwendeten Codebereiche.
Eine SBOM hilft somit, die Lizenzierung der verwendeten Softwarekomponenten zu überwachen und sicherzustellen, dass alle Lizenzen korrekt verwendet und aktualisiert werden. Dies minimiert das Risiko von Verstößen und rechtlichen Problemen. All das sind nahezu unverzichtbare Informationen für ein Softwareprodukt. Obwohl es die Verantwortlichen in den Unternehmen besser wissen (sollten), verzichten sie dennoch nicht selten auf den Einsatz einer Software Bill of Materials. Dies hat fatale Folgen, wie Studien zeigen.
Studien zeigen die Probleme auf, die entstehen, wenn eine SBOM fehlt
Eine Studie des Ponemon Institute zeigt, dass mehr als die Hälfte der befragten Unternehmen im Jahr 2023 Opfer eines Angriffs auf die Software-Lieferkette geworden sind. Dabei wurde fast ein Drittel der Angriffe durch Schwachstellen in nicht gepatchten Open-Source-Komponenten verursacht.
Gleichzeitig sind mehr als 60 Prozent der Befragten der Meinung, dass ihr Unternehmen nicht ausreichend für den Schutz der Software-Lieferkette vor Malware-Angriffen sorgt. Weniger als die Hälfte der Unternehmen verfügt über ein Verfahren zum Schutz vor schädlichen Open-Source-Paketen, und ebenfalls die Hälfte benötigt im Durchschnitt mehr als einen Monat, um Malware zu identifizieren und zu entfernen. In diesem enorm langen Zeitraum haben Angreifer Zeit, Software zu kompromittieren, Daten zu stehlen und nahezu unkalkulierbaren Schaden anzurichten.
Eine SBOM kann genau das verhindern und sie einzuführen ist nicht so komplex, wie viele denken. Kommt es zu einem Sicherheitsvorfall, ermöglicht eine SBOM eine schnelle und genaue Analyse der betroffenen Softwarekomponenten. So können Firmen zügig reagieren und mögliche Schäden minimieren. Angesichts der Vorteile sollten alle betroffenen Unternehmen spätestens jetzt aktiv werden. Mit einer detaillierten Übersicht über alle Komponenten und deren Versionen wird zudem die Wartung und Aktualisierung der Software wesentlich effizienter. Es ist leichter zu erkennen, welche Komponenten aktualisiert werden müssen, um die Software sicher und funktionsfähig zu halten.
Gesetzgeber erkennen Nutzen von SBOM und stellen Anforderungen an Unternehmen
Mittlerweile haben auch Regierungen den Nutzen einer Software Bill of Materials erkannt und stellen konkrete Anforderungen an Unternehmen was die Nutzung anbelangt. Zwei zentrale gesetzliche Rahmenbedingungen, die den Einsatz von SBOMs vorantreiben, sind die Richtlinien der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) und der EU Cyber Resilience Act (CRA). In den USA kann eine SBOM entweder für Teilbereiche gefordert werden, bei Software für Medizinprodukte ist sie bereits Pflicht.
In der EU sind die Anforderungen im aktuellen Cyber Resilience Act (CRA) eindeutig. Artikel 37 und Anhang 1, Abschnitt 2 des CRA spezifizieren, dass Hersteller die Komponenten ihrer Produkte einschließlich der SBOM in einem gängigen und maschinenlesbaren Format dokumentieren müssen: „Hersteller von Produkten mit digitalen Elementen müssen: (1) die Schwachstellen und die in dem Produkt enthaltenen Komponenten identifizieren und dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem allgemein gebräuchlichen und maschinenlesbaren Format.“
Die Einhaltung dieser Vorschriften wird von der EU-Kommission überwacht und Verstöße können zu erheblichen Geldstrafen führen. Inzwischen kann man durchaus so weit gehen zu sagen, dass der Verzicht auf eine SBOM dem Verzicht auf einen generellen Schutz gegen Malware oder dem Verzicht auf eine Firewall gleichkommt.
Der Softwareentwicklungsprozess mit SBOM
Im Rahmen des Softwareentwicklungsprozesses können mithilfe einer SBOM die Dateien und Hashes der beteiligten Produkte erfasst werden. Hinzu kommen die Abhängigkeiten und das Schwachstellenmanagement sowie bestehende Lizenzen und die Einhaltung von Lizenzbestimmungen. Damit sind alle wichtigen Fakten sofort verfügbar, zum Beispiel die Gesamtzahl der Abhängigkeiten und woraus diese Abhängigkeiten im Einzelnen bestehen. Eine SBOM ist in der Lage, eine komplette Struktur der Abhängigkeiten zu erstellen. Daraus wird schnell ersichtlich, an welchen Stellen eine Lieferkette für Schwachstellen anfällig ist. Entwickler können auf Basis dieser Informationen Schwachstellen identifizieren und beheben.
SBOMs sind eng mit den verschiedenen Software-Development-Life-Cycle-(SDLC)-Aktivitäten integriert. So können Daten aus einer SBOM exportiert und externe Informationen importiert werden. Quellen, Abhängigkeiten, Binärdateien und Artefakte lassen sich mittels eines Multifaktor-Scans erkennen. Diese Informationen stehen dann gleichzeitig auch Regulierungsbehörden und Kunden zur Verfügung. Noch benutzerfreundlicher wird eine SBOM über Vulnerability Exploitability eXchange (VeX). Der Dokumentationsansatz gibt Auskunft über die Sicherheit einer Anwendung und erleichtert es, Schwachstellen richtig einzustufen, das damit verbundene Risiko zu senken, respektive die Lücken zu beheben.
Deshalb brauchen Anbieter und Kunden eine SBOM
Eine SBOM erlaubt es Lieferanten und Anbietern von Softwareprodukten branchenspezifische Vorgaben, Gesetze und Compliance-Vorschriften einzuhalten sowie die Leistungen für ihre Kunden genau zu definieren. Schwachstellen werden nicht nur zuverlässig erkannt, sondern können schnell an Kunden und Aufsichtsbehörden gemeldet werden. Zudem erleichtert es eine SBOM, veraltete oder nicht mehr unterstützte Komponenten zu identifizieren. Durch die regelmäßige Überprüfung und Aktualisierung dieser Komponenten lassen sich technische Schulden (Technical Debt) reduzieren und die langfristige Wartbarkeit der Software verbessern. Ohne SBOM fehlt die nötige Transparenz über die Zusammensetzung einer Software. Dies kann zu Schwierigkeiten bei der Fehlerdiagnose und -behebung führen, weil nicht klar ist, welche Komponenten betroffen sein könnten.
Viele Kunden verlangen deshalb bereits eine SBOM sowie den Nachweis eines sicheren SDLC. Darüber hinaus erwarten viele Unternehmen von ihren Lieferanten, dass sie zeitnah über Schwachstellen informiert und bei deren Behebung unterstützt werden. SBOMs sind keine eigenständige Lösung, sondern werden in den Entwicklungsprozess eines Produktes integriert und erfassen genau die Informationen, die ohne SBOMs schlichtweg fehlen würden.
Fehlende Informationen sind in Zeiten zunehmender Cyberangriffe kaum noch hinnehmbar. Verschiedene Regierungen haben dies erkannt und die Anforderungen in Vorschriften und Gesetze gegossen. Kommt es zu Cyberangriffen auf ein Produkt ohne SBOM, drohen hohe Strafen und weitere Konsequenzen wie etwa der Vertrauensverlust von Kunden oder finanzielle Einbußen. Ohne SBOM ist es schwierig bis unmöglich die Einhaltung gesetzlicher und regulatorischer Anforderungen sicherzustellen. Potenzielle Compliance-Verstöße ziehen dann auch noch juristische Folgen nach sich.
Es spricht also einiges dafür, nicht auf eine SBOM zu verzichten.
Boris Cipot ist Senior Sales Engineer bei Synopsys SIG.
Weitere Artikel zum Thema finden Sie hier:
- Integrität digitaler Artefakte in der Lieferkette: Der lange dunkle Weg ins Licht
- (Cyber-) Sicherheit auf die Kette bekommen
- Was ist eine Kubernetes Bill of Materials und wie funktioniert sie?