״Softwareanbieter müssen haftbar gemacht werden wenn sie ihrer Fürsorgepflicht gegenüber Verbrauchern, Unternehmen oder Anbietern kritischer Infrastruktur (dem Weißen Haus) nicht nachkommen.
Heutzutage wird von jedem Softwareanbieter erwartet, dass er durch vertragliche Vereinbarungen, Software-Releases und -Updates, Benachrichtigungen und die Behebung von Schwachstellen eine größere Verantwortung für die Gewährleistung der Integrität und Sicherheit von Software übernimmt. Kürzlich hat die ESF (Enduring Security Framework), eine branchenübergreifende Arbeitsgruppe, Leitlinien herausgegeben, die empfohlene Best Practices und Standards enthalten, um Kunden bei der Implementierung von Sicherheitsmaßnahmen innerhalb der Software-Lieferkette zu unterstützen. In diesem Artikel werde ich näher auf die praktische Empfehlung eingehen, die SBOM-gesteuerte Risikobewertung als wirksamen Mechanismus zur Triage und Priorisierung einzusetzen.
Es gibt nach wie vor gängige Methoden zur Kompromittierung von Software-Lieferketten, darunter die Ausnutzung von Software-Designfehlern, die Integration anfälliger Komponenten Dritter in ein Softwareprodukt, die Infiltrierung des Netzwerks des Lieferanten mit bösartigem Code vor der endgültigen Lieferung des Softwareprodukts und das Einschleusen bösartiger Software in die bereitgestellte Software im Kundenumfeld.
Eine Software-Stückliste (SBOM) hat sich zu einem entscheidenden Element der Softwaresicherheit und des Risikomanagements der Softwarelieferkette entwickelt. Eine SBOM dient als verschachteltes Inventar und stellt eine Liste der Bestandteile bereit, aus denen Softwarekomponenten bestehen.
Die Operationalisierung von SBOMs im großen Maßstab erfordert die Automatisierung und Standardisierung von Werkzeugen bei der Systembereitstellung, der Produktentwicklung und dem Datenaustausch zwischen Softwareanbietern und Verbrauchern.
Es gibt einige wichtige maschinenlesbare SBOM-Standardformate von der Industrie unterstützt. CycloneDX und SPDX definieren die Art und Weise, wie SBOMs erstellt, analysiert und geteilt werden. VEX ist eine ergänzende Form einer Sicherheitswarnung, die angibt, ob ein Produkt oder mehrere Produkte von einer oder mehreren bekannten Schwachstellen betroffen sind. Somit bietet es den Vorteil, zu zeigen, dass ein Produkt nicht von einer bestimmten Schwachstelle betroffen ist, selbst wenn diese Schwachstelle in seiner SBOM vorhanden ist.
Die Korrelation von SBOM-Inhalten über im Unternehmen eingesetzte Softwareprodukte hinweg kann den Anwendungssicherheits-, Vorfallreaktions- und Forensikteams, dem Risikomanagement und der Beschaffung wertvolle Erkenntnisse liefern. Von Unternehmen wird erwartet, dass sie eine große Menge an SBOM-Daten für interne Produkte generieren und verwalten sowie externe Daten nutzen, die effektiv verwaltet werden müssen. Daher besteht Unterstützungsbedarf Prozessdefinierung Automatisierung von SBOM-gesteuertes Risikomanagement auf einer Skala.
Verwendung von SBOMs und Risikobewertung
Die Risikobewertung kann dazu dienen, aus SBOM-Inhalten einen komprimierten Überblick zu generieren, der schnelle Vergleiche mit externen Datenquellen ermöglicht und eine schnelle Entscheidungsfindung auf der Grundlage der erhaltenen SBOMs und der Priorisierung erleichtert.
- Das SBOM erhöht die Transparenz und verbessert dadurch das Software-Asset-Management, das Patch-Management, die Identifizierung technischer Schuldenlücken und das Schwachstellenmanagement für Kundenorganisationen. Es birgt auch das Potenzial, die Herkunft von Komponenten zu extrahieren, um Integrität und Vertrauen zu validieren.
- Die Analyse der SBOM-Inhaltsausrichtung über im Unternehmen implementierte Softwareprodukte hinweg liefert wertvolle Erkenntnisse für Incident-Response-Teams, Risikomanagement und Beschaffungsprozessvalidierung.
SBOM in maßstabsgetreue Risikoinformationen umwandeln – Begründung für die Risikobewertung
Eine zentrale Herausforderung für jeden AppSec-Experten und CISO ist die Bewältigung der Alarmmüdigkeit bei Ihren Produkten und Dienstleistungen. Einschließlich der Bewertung externer Risiken, die von Softwarekomponenten Dritter ausgehen.
Die größten Hindernisse für die Implementierung sind veralteter vertraglicher oder lizenzbasierter Support, der sich auf die Verfügbarkeit von Downstream-Patches und Produktaktualisierungen auswirken kann, sowie das exponentielle Wachstum der Komplexität von Abhängigkeiten innerhalb von Softwareprodukten, unabhängig davon, ob es sich um Open-Source- oder Closed-Source-Produkte handelt.
A Risiko-Score ist eine Metrik zur Vorhersage von Aspekten der Software und ihrer Komponenten, des aktuellen und zukünftigen Risikos, die die Priorisierung in großem Maßstab wirksam unterstützen kann.
Risikobewertung = Wahrscheinlichkeit x Auswirkung
Mit der Risikobewertung können Unternehmen das Risiko ihrer Software-Lieferkette anhand definierter Risikofaktoren verstehen und das potenzielle zukünftige Risiko eines bestimmten Softwareprodukts im Unternehmen vorhersehen.
Eine effektive Risikobewertung könnte auf einer Skala von 1 bis 10 liegen (z. B. CVSS und Scorecard), sodass wir jede Risikokomponente zur leichteren Bezugnahme auf die Skala von 1 bis 10 ausrichten können.
Eine aggregierte Risikobewertung: In vielen komplexen Systemen und Systemsystemen kann es mehrere SBOMs als Teil der Gesamtlösung und damit einer Sammlung von Risikobewertungen geben.
Komponenten der Risikobewertung:
1.Schwachstellen: Zuordnung bekannter Schwachstellen mithilfe der CVE-Enumeration und CVSS-Score aus verfügbaren Feeds wie NVD, OSV und Github Advisories.
2. Kontext von Anbietern: VEX und Beratungskontext von Anbietern, die die Entscheidung über die Schwachstellenbewertung im Kontext der Nutzung ändern können. Die Verknüpfung von SBOMs mit Schwachstellen ermöglicht Risikokennzeichnungen, während VEX-Dokumente es einem Verbraucher ermöglichen, Schwachstellen zu priorisieren.
3. EPSS 3.0: Ausnutzbarkeitsmetrik von FIRST, die die Wahrscheinlichkeit (zwischen 0 und 1.0) einer Ausnutzung in den nächsten 30 Tagen vorhersagt. Dies ist eine effektive zusätzliche Wahrscheinlichkeitsschicht zum CVSS-Score, der dabei helfen kann, die wichtigsten CVEs zu priorisieren, die zuerst bearbeitet werden müssen.
4. KEV: CISA hat auch einen öffentlich zugänglichen Threat-Intelligence-Feed erstellt, der heute als bekannt ist CISA KEV-Katalog (Known Exploitable Vulnerabilities).. Dieser Katalog enthält etwa 5 % aller identifizierten CVEs, die laut CISA aktiv ausgenutzt wurden oder aktiv ausgenutzt wurden. Daher ist dies ein guter Ausgangspunkt für die Priorisierung von Schwachstellen mit großer Auswirkung, die behoben werden müssen. Darüber hinaus ist dies Teil der Checkliste, die Sie vor der endgültigen Genehmigung der neuen Version validieren würden.
5. Bedrohungsinformationen – Zusätzliche hinzufügen Bedrohungsquellen und Schwachstellen-Feeds bekannter Schadpakete (Beispiele: private Feeds von Snyk, Sonatype, Graynoise usw.)
6. OSS-Reputation: Die Die Open SSF Scorecard bewertet unabhängig Leistungskennzahlen, die sich auf verschiedene Teile der Software-Lieferkette auswirken, einschließlich Quellcode, Build, Abhängigkeiten, Tests und Projektwartungsreputation von Open-Source-Projekten (Bewertung 1–10).
7. Leistung im Laufe der Zeit: MTTR (Mean Time To Repair) kritische Schwachstellen einer Produkt-/Paketversion könnten eine relevante Kennzahl für die Leistung von Sicherheitsrisiken liefern.
8. Auswirkung und Kontext. In dieser Hinsicht würde eine Priorisierung auf der Grundlage des Geschäftskontexts des Softwareprodukts dabei helfen, die Schwachstellenstruktur zu priorisieren und zu selektieren.
Ein paar Beispiele sind
- Kritikalität des Moduls/Produkts: Ist dies geschäftskritisch (Sensitivität oder Kritikalität)?
- Bei wie vielen Produkten liegt die konkrete Schwachstelle vor?
- Externe Exposition eines Dienstes/einer Komponente
9. Compliance-Gefährdung – Lizenzen: Sowohl proprietäre als auch Open-Source-Softwarelizenzen sind wichtig, um die Einhaltung der rechtlichen Richtlinien der Organisation zu überprüfen.
Konzept der Risikobewertungsebenen – Hinzufügen von Risikometriken zu SBOMs:
- Startseite mit CVE-Aufzählung und CVSS-Score basierend auf den SBOM-Daten.
- Nutzen Sie VEX-Kontext und fügen Sie ihn hinzu, um die Kritikalität neu zu priorisieren
- Bewerten Sie CVEs mit einem hohen EPSS-Score (d. h. 0.6–1.0).
- Priorisieren Sie die KEV-Liste – bis zuerst ansprechen.
- Bewerten Sie anhand des OpenSSF-Reputationsfaktors (1–10) – identifizieren Sie riskante Abhängigkeiten.
- Analysieren Belichtung zum externen Netzwerk (mittels CVSS-Vektor)
- Bewerten Sie das akkumulierte Risiko durch die Menge der Produktanzahl pro Schwachstelle.
- Bewerten Sie durch die Etikette der Wichtigkeit einer bestimmten Container-SBOM für das Unternehmen.
- Identifikation Compliance-Verstoß Risiken bei der Verwendung der SBOM-Abhängigkeitsanalyse gemäß der Lizenzrichtlinie des Unternehmens.
- Teilen und die Daten verwalten as Bescheinigungen in einer kollaborativen Plattform mit Workflows zu anderen Systemen wie Jira und anderen über API und maschinenlesbar.
Nutzung von SBOMs mit Risikobewertung für praktische Anwendungsfälle:
- Kontinuierliche Schwachstellentriage für Produkte mithilfe von Risikometriken, um einen Patching-Arbeitsplan für alle Produkte zu priorisieren.
- Vergleichen Sie Produkte nebeneinander basierend auf Risikokennzahlen.
- Vergleichen und genehmigen Sie neue Versionsaktualisierungen vor der Bereitstellung/Veröffentlichung.
- Verfolgen Sie die technische Schuldenlücke anhand der Risikobewertungsschwellen für Produktversionen.
- Erstellen Sie einen schnellen Bericht über die 50 größten Risiken meiner kritischsten Produkte.
- Auswirkungsanalyse zur Beschleunigung einer Reaktion auf einen Vorfall – für den Fall, dass eine aktiv ausgenutzte Schwachstelle entdeckt wird. In diesem Fall, Zeit ist wichtig um schnell zu erkennen, wie ich betroffen bin und wie groß der Explosionsradius der Wärmekarte dieser Exposition sein würde.
So nutzen Sie die Scribe Hub-Plattform für ein effektives Risikomanagement:
- Zentralisierte SBOM-Managementplattform – Erstellen, verwalten und teilen Sie SBOMs zusammen mit ihren Sicherheitsaspekten: Schwachstellen, VEX-Hinweise, Lizenzen, Reputation, Ausnutzbarkeit, Scorecards usw.
- Erstellen und implementieren Sie sichere Software – Erkennen Sie Manipulationen, indem Sie Quellcode, Container-Images und Artefakte in jeder Phase Ihrer CI/CD-Pipelines kontinuierlich signieren und überprüfen.
- Automatisieren und vereinfachen Sie die SDLC-Sicherheit – Kontrollieren Sie das Risiko in Ihrer Softwarefabrik und stellen Sie die Vertrauenswürdigkeit des Codes sicher, indem Sie Sicherheit und Geschäftslogik in automatisierte Richtlinien übersetzen, die durch Leitplanken durchgesetzt werden
- Transparenz aktivieren. Verbessern Sie die Liefergeschwindigkeit – Geben Sie Sicherheitsteams die Möglichkeit, ihre Verantwortung wahrzunehmen und die Sicherheitskontrolle zu optimieren, ohne die Ergebnisse der Entwicklerteams zu beeinträchtigen.
- Richtlinien durchsetzen. Demonstrieren Sie Compliance - Überwachen und setzen Sie SDLC-Richtlinien und -Governance durch, um die Software-Risikolage zu verbessern und die für Ihr Unternehmen erforderliche Compliance nachzuweisen.
Zwei Beispiele für Schreiber-Hub Risikoanalysefunktionen werden vorgestellt:
Schwachstellen werden nach SBOMs abgebildet, Risikobewertung anhand von CVSS-, VEX-, EPSS- und KEV-Daten.
Zeitreihe der SBOM-Versionsleistung im Zeitverlauf, die MTTR als durchschnittliche Zeit zur Behebung kritischer identifizierter Schwachstellen angibt.
Zusammenfassung
Mit der SBOM-gesteuerten Risikobewertung können Unternehmen das Risiko der Lieferkette bewerten, indem sie vordefinierte Risikofaktoren bewerten und potenzielle zukünftige Risiken im Zusammenhang mit einem bestimmten Softwareprodukt innerhalb des Unternehmens vorhersehen. Der Risikoscore dient als quantitatives Maß zur Antizipation aktueller und zukünftiger Risiken im Zusammenhang mit der Software und ihren Komponenten.
Diese Bewertungsmetrik wird aus Indikatoren abgeleitet, die unter anderem aus SBOM, VEX und anderen Feeds stammen, und stimmt mit den Inhalten überein, die das Supply Chain Risk Management (SCRM) unterstützen. Bei der Anwendung oder Bewertung einer Risikobewertung sollten Faktoren wie der Nutzungskontext der Software, die Art und Weise, wie auf sie zugegriffen wird oder sie isoliert wird, sowie die von ihr unterstützten Prozesse und Systeme berücksichtigt werden.
Scribe Hub dient als kollaborative Plattform für die Extraktion, Verwaltung, Bescheinigungserfassung und Risikobewertungsanalyse von SBOMs in großem Maßstab. Diese Plattform verarbeitet effizient mehrere externe Datenfeeds, um die Feinheiten komplexer Systeme und Softwareprodukte zu bewältigen.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
