Aus Gründen der Effizienz und Zeitersparnis verwenden Entwickler bei der Erstellung ihrer Anwendungen routinemäßig den Code von Drittanbietern. Diese Abhängigkeit von externen Komponenten, insbesondere von Open-Source-Software (OSS), birgt jedoch erhebliche Risiken, darunter Sicherheitslücken und Lizenzierungsprobleme. Laut einer GitHub-Umfrage aus dem Jahr 2023 halten 31 % der Entwickler das Auffinden und Beheben von Sicherheitslücken für ihre zweitwichtigste Aufgabe, gleich nach dem Schreiben von Code (32 %).
Folglich sind viele Unternehmen besorgt über ihre Abhängigkeit von OSS, da diese häufig ins Visier von Hackern gerät. Die Unternehmen stehen vor der Herausforderung, dass die Software-Lieferkette immer anfälliger wird und dass sie angesichts der jüngsten Angriffe wissen müssen, wie sie das Risiko effektiv mindern können.
Ein Forschungsbericht von ESG zeigt, dass 91 % der Unternehmen in den letzten 12 Monaten einen Vorfall in der Software-Lieferkette erlebt haben. Zu den häufigsten Vorfällen gehören:
Prominente Sicherheitslücken wie Log4J, Curl, Apache Struts und OpenSSL haben zu zahlreichen betrieblichen Schäden geführt. Sie machen deutlich, welch schwerwiegende Folgen es für Unternehmen hat, wenn eine einzige Schwachstelle innerhalb der Software-Lieferkette ausgenutzt wird. Als Reaktion auf diese wachsenden Risiken legen Aufsichtsbehörden auf der ganzen Welt den Schwerpunkt auf die Transparenz und Sicherheit von Software. Die Einführung eines Software Bill of Materials (SBOM) entwickelt sich zu einer Schlüsselstrategie für das Management von Risiken in der Software-Lieferkette.
SBOM-Verordnungen gewinnen an Schwung
SBOM-Vorschriften sind zunehmend verbreitet. Viele Regierungen haben Empfehlungen zur Umsetzung von SBOM veröffentlicht. In den USA sind SBOM-Empfehlungen in mehreren Regierungsrichtlinien enthalten, darunter:
Im Jahr 2023 veröffentlichte die CISA drei Schlüsseldokumente, um die Einführung von SBOM zu fördern. Diese konzentrierten sich auf die Ausweitung der SBOM-Nutzung, die Erforschung neuer Technologien und Anwendungen sowie die Förderung der Zusammenarbeit in der Gemeinschaft.
In Europa hat die EU-Agentur für Cybersicherheit (ENISA) "Guidelines for Securing the Supply Chain for the Internet of Things" veröffentlicht, die Unternehmen wertvolle Einblicke in die Verbesserung der Cybersicherheit und das Management softwarebezogener Lieferkettenrisiken bieten.
Andere Länder haben ähnliche Leitlinien herausgegeben, darunter:
rät Organisationen, SBOMs zu verwenden, um die Risiken zu bewerten, die mit den von ihnen verwendeten Softwarekomponenten verbunden sind, und um Schwachstellen in diesen Komponenten zu identifizieren und zu beheben.
Im "Information Security Manual: Guidelines for Software Development" (Richtlinien für die Software ) empfiehlt der ACSC die Verwendung von SBOMs, um die Transparenz der Cyber-Lieferkette zu erhöhen und die Identifizierung und das Management von Sicherheitsrisiken im Zusammenhang mit einzelnen Softwarekomponenten, die in Anwendungen verwendet werden, zu erleichtern.
In "Recommendations to Improve the Resilience of Canada's Digital Supply Chain" (Empfehlungen zur Verbesserung der Widerstandsfähigkeit der digitalen Supply Chain Kanadas) plädiert die CSE für den Einsatz von SBOMs, um die Transparenz zu erhöhen und Bedrohungen in der Software-Lieferkette wirksam zu begegnen.
Wie der PCI DSS die SBOM-Erstellung erforderlich macht
Der Payment Card Industry Data Security Standard (PCI DSS) hat die eskalierenden Risiken für Zahlungskartendaten erkannt und ist zu einer treibenden Kraft für die Einführung von SBOMs geworden. Die neueste Version, PCI DSS 4.0, schreibt die Verwendung von SBOMs vor und unterstreicht damit deren entscheidende Rolle beim Schutz sensibler Daten. Durch die Bereitstellung eines detaillierten Inventars von Softwarekomponenten ermöglichen SBOMs es Unternehmen, Schwachstellen proaktiv zu erkennen und zu beheben und so das Risiko von kostspieligen Datenschutzverletzungen und finanziellen Verlusten zu verringern.
Der PCI DSS wurde 2004 eingeführt und ist ein umfassender Sicherheitsstandard zum Schutz von Kreditkartendaten. Er enthält eine Reihe strenger Anforderungen für Unternehmen, die Kreditkartentransaktionen abwickeln, die auf das Volumen der jährlich verarbeiteten Transaktionen zugeschnitten sind. Mit der Veröffentlichung von PCI DSS v4.0 im Jahr 2022 wurden bedeutende Änderungen eingeführt, darunter das SBOM-Mandat, um den sich entwickelnden Bedrohungen zu begegnen. Die Einhaltung von PCI DSS v4.0 ist bis April 2024 verpflichtend, wobei bestimmte Anforderungen schrittweise bis zum 31. März 2025 eingeführt werden.
Quelle: PCI DSS V4.0 auf einen Blick
Durch die Vorgabe von SBOMs ermöglicht der PCI DSS den Unternehmen einen umfassenden Einblick in ihr Software-Ökosystem, so dass sie Schwachstellen proaktiv erkennen und beheben können. Dieser Ansatz verringert das Risiko kostspieliger Datenschutzverletzungen und finanzieller Verluste erheblich.
Eine neuere Version des PCI DSS, Version 4.0.1, wurde Mitte 2024 veröffentlicht. Das bedeutet, dass die vorherige Version 4.0 nach dem 31. Dezember 2024 nicht mehr gültig sein wird. In der neuen Version wurden jedoch keine Regeln hinzugefügt oder entfernt und die Fristen wurden nicht geändert. Daher gelten die Informationen über die SBOM-Anforderungen in diesem Blog sowohl für die Version 4.0 als auch für die Version 4.0.1.
Erfüllung der PCI DSS-Anforderung 6.3.2
Die SBOM-Anforderung in PCI DSS v4.0 ist Teil der umfassenderen Verbesserungen, die in der neuesten Version des PCI DSS vorgenommen wurden. Die SBOM-Anforderung wurde als Teil der 64 neuen Anforderungen in Version 4.0 eingeführt und zielt speziell auf die Notwendigkeit für Unternehmen ab, ein Inventar von Softwarekomponenten zu führen, wobei der Schwerpunkt auf maßgeschneiderter und kundenspezifischer Software liegt.
Diese Anforderung fällt unter die PCI DSS-Anforderung 6, die die Schaffung und Aufrechterhaltung sicherer Systeme und Anwendungen durch die Umsetzung strenger Sicherheitsmaßnahmen und die regelmäßige Durchführung von Schwachstellenbewertungen und Updates vorschreibt. Diese Anforderung ist für die Verringerung der von Software-Schwachstellen ausgehenden Risiken und für den Schutz der Daten von Karteninhabern unerlässlich. Abschnitt 6 deckt fünf Hauptbereiche ab:
- 6.1 Prozesse und Mechanismen zur Entwicklung und Pflege sicherer Systeme und Software sind definiert und verstanden.
- 6.2 Maßgeschneiderte und kundenspezifische Software wird auf sichere Weise entwickelt.
- 6.3 Sicherheitsschwachstellen werden ermittelt und beseitigt.
- 6.4 Öffentlich zugängliche Webanwendungen sind gegen Angriffe geschützt.
- 6.5 Änderungen an allen Systemkomponenten werden sicher verwaltet.
Insbesondere die Anforderung 6.3.2 ist eine wichtige Aktualisierung, die sich aus mehreren Sicherheitsverletzungen ergab, bei denen Schwachstellen in Komponenten von Drittanbietern oder Verletzungen von Drittanbietern von Komponenten zu einer Kompromittierung von Karteninhaberdaten führten. Die Anforderung lautet wie folgt:
6.3.2.b Prüfung der Softwaredokumentation, auch für maßgeschneiderte und kundenspezifische Software, die Softwarekomponenten von Drittanbietern integriert, und Vergleich mit dem Inventar, um zu überprüfen, ob das Inventar die maßgeschneiderte und kundenspezifische Software und die Softwarekomponenten von Drittanbietern enthält.
Unternehmen müssen die spezifischen Komponenten und Dienste, die in ihren Anwendungen verwendet werden, gründlich dokumentieren und verwalten. Während einige dieser Informationen vielleicht schon in Datenflussdiagrammen erfasst wurden, erfordern die neuen Anforderungen eine wesentlich detailliertere Dokumentation. Es kann schwierig sein, den Überblick über diese Details zu behalten, wenn Komponenten aktualisiert und geändert werden. Es ist ratsam, eine Standardvorlage für die Erfassung dieser Informationen zu verwenden. Darüber hinaus bieten einige Quellcode-Repositories, wie z. B. GIT, Tools zum Exportieren einer Liste der verwendeten Komponenten an. Ihr Inventar sollte mindestens Folgendes enthalten:
- Anwendungskomponenten (in der Regel Repository-Projekte)
- Liste der Komponenten von Drittanbietern
- Liste der Anwendungsabhängigkeiten (d. h. Tomcat, Jboss, .NET, Middleware)
- Liste der autorisierten Zahlungsseiten-Skripte
Wie OPSWAT SBOM zur Erfüllung der PCI DSS-Anforderungen beitragen kann
Die Vorschriften verlangen zunehmend SBOMs, um die Sicherheit der Software-Lieferkette zu gewährleisten. Unternehmen tun sich jedoch schwer damit, eine genaue Bestandsaufnahme der Zusammensetzung ihres Software-Codes zu erstellen.
Quelle: EGS-Bericht 2024
Die Erstellung genauer und umfassender SBOMs stellt jedoch eine große Herausforderung für Unternehmen dar. Diese Dokumente erfordern eine akribische Inventarisierung der Softwarekomponenten und detaillierte Informationen über deren Herkunft, Versionen und Abhängigkeiten. Ohne präzise SBOMs haben Unternehmen Schwierigkeiten, die Risiken in ihrer Software-Lieferkette effektiv zu identifizieren, zu bewerten und abzumildern.
Leitlinien für die Erstellung von SBOMs
OPSWAT SBOM automatisiert die Erstellung von SBOMs sowohl für Code als auch für Container, wodurch die Sicherheit erhöht und die Einhaltung von Vorschriften innerhalb der Software-Lieferkette unterstützt wird.
- Identifizieren Sie alle Komponenten und Abhängigkeiten
Identifizieren Sie alle Softwarekomponenten, einschließlich Open-Source-Bibliotheken und Bibliotheken von Drittanbietern, zusammen mit ihren Versionen und Abhängigkeiten genau. Dies bildet die Grundlage für eine robuste SBOM. - OSS-Risiken bewerten
Bewerten Sie die potenziellen Risiken, die mit OSS-Komponenten verbunden sind. Berücksichtigen Sie Faktoren wie Lizenzkonformität, Sicherheitslücken und Wartungsstatus. Priorisieren Sie die Komponenten auf der Grundlage ihrer Kritikalität für die Software. - Scannen nach OSS-Schwachstellen
Einsatz von Schwachstellen-Scannern und SBOM-Generierungs-Tools zur Ermittlung bekannter Schwachstellen in den OSS-Komponenten. Priorisierung der Schwachstellen auf der Grundlage ihres Schweregrads und ihrer potenziellen Auswirkungen auf die Software.
Verwendung von OPSWAT SBOM
OPSWAT SBOM automatisiert die Erstellung von SBOMs sowohl für Code als auch für Container, wodurch die Sicherheit erhöht und die Einhaltung von Vorschriften innerhalb der Software-Lieferkette unterstützt wird.
Hier erfahren Sie, wie Sie OPSWAT SBOM nutzen können, um SBOMs effektiv zu erstellen:
Durch die Bereitstellung eines Inventars aller Open-Source-Bibliotheken und -Komponenten, die in einer Anwendung verwendet werden, hilft OPSWAT SBOM bei der Verwaltung von Abhängigkeitsschwachstellen in der Software-Lieferkette und versetzt die Benutzer in die Lage, Schwachstellen in Anwendungen effizient zu identifizieren und zu beheben.
Neben der Identifizierung von Schwachstellen validiert OPSWAT SBOM auch die mit jeder Softwarekomponente verbundenen Lizenzen. Dies gewährleistet die Einhaltung der Lizenzbedingungen und vermeidet potenzielle rechtliche Fallstricke. Erfahren Sie mehr über die entscheidende Rolle der Lizenzerkennung in OSS.
OPSWAT SBOM unterstützt über 10 Programmiersprachen, darunter Java, JavaScript, Go, PHP und Python. Diese breite Unterstützung gewährleistet eine umfassende vulnerability detection über verschiedene Softwareentwicklungs-Ökosysteme hinweg.
Sanktionen bei Nichteinhaltung der Vorschriften
Unternehmen, die die PCI DSS-Standards, einschließlich der SBOM-Anforderungen, nicht einhalten, können mit Geldstrafen von 5.000 bis 100.000 US-Dollar pro Monat belegt werden. Diese Geldstrafen können im Laufe der Zeit eskalieren, wenn die Probleme mit der Einhaltung der Vorschriften nicht gelöst werden.
Neben finanziellen Strafen kann die Nichteinhaltung des PCI DSS zu erheblichen rechtlichen und betrieblichen Herausforderungen führen. Zu den rechtlichen Folgen können Klagen, Verteidigungskosten und erhebliche Vergleiche gehören. Darüber hinaus kann die Nichteinhaltung von Vorschriften zu Prüfungen durch Bundesbehörden wie die Federal Trade Commission (FTC) führen, was zusätzliche Strafen nach sich zieht.
Nächste Schritte zur Einhaltung von PCI DSS 4.0
Die Integration von SBOM in das PCI DSS 4.0-Rahmenwerk bedeutet einen entscheidenden Wandel hin zu einer sichereren Software-Lieferkette. Durch den Einsatz fortschrittlicher Tools wie OPSWAT SBOM können Unternehmen Open-Source-Risiken effektiv verwalten, die Compliance verbessern und sich vor kostspieligen Datenschutzverletzungen schützen.
Die Verwendung von SBOMs ist nicht länger eine Option, sondern eine Notwendigkeit. Durch proaktive Maßnahmen zum Verständnis und zur Bewältigung von Softwareabhängigkeiten können Unternehmen eine solide Sicherheitsgrundlage schaffen, die ihren Betrieb schützt und das Vertrauen ihrer Kunden stärkt.
Verbessern Sie Ihre Sicherheit
Posture mit OPSWAT
Beginnen Sie jetzt mit der Verwaltung von Open-Source-Abhängigkeiten
.
