VDR, VEX, OpenVEX und CSAF
26.06.2023
Interlynk
Die Software-Transparenz hat einen dringend benötigten und lange erwarteten Schub erhalten. Das Software Bill of Materials (SBOM) soll das zentrale Artefakt für Software-Transparenz und Koordination von Verwundbarkeiten innerhalb und zwischen Organisationen werden. Da SBOM-Formate notwendige Details, einschließlich Softwarekomponenten und deren Ursprünge, enthalten, kann ein gutes SBOM verwendet werden, um bekannte Verwundbarkeiten in der Software zu verfolgen und zu überwachen.
Die SBOM-Komponentenliste kann mit Verwundbarkeitsdatenbanken (z. B. NVD) verwendet werden, um eine Verwundbarkeitsliste für das Produkt zu erstellen.
Allerdings reicht ein SBOM allein möglicherweise nicht aus, um genügend Details zu kodieren, um nicht ausnutzbare Verwundbarkeiten von ausnutzbaren zu unterscheiden. Dies kann zu einem neuen Rauschen in einer bereits lauten Umgebung von Sicherheitsdatenpunkten führen.
Frühe Anwender von SBOM haben dies erkannt und neue Standards sowie Aktualisierungen bestehender Standards vorgeschlagen, um den Status jeder Verwundbarkeit neben dem SBOM selbst zu spezifizieren. In diesem Kontext spielen bestehende Praktiken wie VDR, CSAF und aufkommende Standards wie VEX und OpenVEX eine entscheidende Rolle.
VDR: Sicherheitsanfälligkeits-Offenlegungsbericht
VDR ist die Liste bekannter Schwachstellen, die vom Softwareanbieter veröffentlicht wird. Ein typisches Dokument listet Schwachstellen, zugehörige CVE, CVSS, Auswirkungen, Zeitrahmen und Strategien zur Minderung auf, sowie die Kontaktdaten innerhalb des Anbieters. Der VDR ist nicht für die programmgesteuerte Nutzung vorgesehen, und das tatsächliche Format (HTML, Excel, PDF, CSV) kann je nach Organisation variieren.
Beispiel für einen Schwachstellenoffenlegungbericht (VDR) bei Invicti
NIST-800–161r1: Praktiken des Risikomanagements in der Cybersicherheit für Lieferketten in Systemen und Organisationen empfiehlt die folgende Rolle für VDR, um ein detailliertes Verständnis und ein proaktives Management von Schwachstellen zu demonstrieren.
Unternehmen, wo anwendbar und angebracht, können in Betracht ziehen,
Kunden einen Schwachstellenoffenlegungbericht (VDR) zur Verfügung zu stellen, um
korrekte und vollständige Schwachstellenbewertungen für in
SBOMs aufgeführte Komponenten zu demonstrieren. Der VDR sollte die Analyse und Ergebnisse enthalten, die den
Einfluss (oder das Fehlen von Einfluss) beschreiben, den die gemeldete Schwachstelle auf eine
Komponente oder ein Produkt hat. Der VDR sollte auch Informationen zu Plänen
zur Behebung der CVE enthalten. Unternehmen sollten in Erwägung ziehen, den VDR
innerhalb eines sicheren Portals für Kunden zu veröffentlichen und den VDR mit
einem vertrauenswürdigen, verifizierbaren privaten Schlüssel zu unterzeichnen, der einen Zeitstempel enthält, der
das Datum und die Uhrzeit der VDR-Unterzeichnung und des dazugehörigen VDR angibt. Unternehmen sollten auch in Betracht ziehen, einen separaten Benachrichtigungskanal für
Kunden einzurichten, in Fällen, in denen Schwachstellen auftreten, die nicht im VDR offengelegt werden. Unternehmen sollten verlangen, dass ihre Hauptauftragnehmer
diese Kontrolle umsetzen und diese Anforderung an relevante Unterauftragnehmer weitergeben.
VDR berichtet über bekannte Schwachstellen des Produkts, hat jedoch keine direkte Beziehung zum SBOM
Während VDR theoretisch den Status jeder Schwachstelle beschreiben kann, macht der Mangel an einem gemeinsamen Berichtstandard es weniger praktikabel für die programmgesteuerte Nutzung und damit zu einem Engpass bei der Bewertung der Ausnutzbarkeit von Schwachstellen.
VEX: Verwundbarkeitsausnutzungs-austausch
Das Konzept von VEX entwickelte sich innerhalb derselben NTIA-Multistakeholder-Gruppe, die die SBOM-Empfehlungen in SBOM-Formulierung und SBOM-Mindestelemente formalisiert hat. VEX ist noch nicht formalisiert, aber sein Vorschlag zielt darauf ab, eine Aussage über den Status einer Schwachstelle in bestimmten Produkten oder Versionen zu teilen. Der Status kann sein – Nicht Betroffen, Betroffen, Behebt, Unter Untersuchung.
VEX: Ein einzelnes Dokument, das Mehrere Produkte, Mehrere Schwachstellen, Mehrere Status
Früher in diesem Jahr hat die Arbeitsgruppe auch den Mindestanforderungen für VEX zugestimmt, wobei jedes VEX-Dokument als eine Reihe von VEX-Aussagen beschrieben wird, wobei jede Aussage einen Status für eine Schwachstelle trägt.
VEX-Dokument und Aussagen aus den Mindestanforderungen für VEX
Anders ausgedrückt, wenn SBOM und VEX zusammen verwendet werden, kann ein gut beschriebenes SBOM auf Komponenten und mögliche Schwachstellen abgebildet werden, während VEX verwendet werden kann, um die Anzahl der tatsächlich anwendbaren Schwachstellen zu reduzieren. Ein Community-Mitglied hat es schön als „Zuerst schaltet SBOM alle relevanten Lichter ein, und VEX schaltet alle unnötigen aus.“ beschrieben.
VEX-Varianten: VEX1 eingebettet in SBOM, um einige Status auszuschalten, VEX2 später veröffentlicht, um neu entdeckte Schwachstellen auszuschalten, VEX3 später veröffentlicht, um die Arbeit an einer anderen Schwachstelle zu erklären
Obwohl nicht unbedingt erforderlich, ist ein VEX-Dokument als direkter Begleiter zum SBOM gedacht. VEX kann direkt eingebettet werden in CycloneDX 1.4 und ist im Sicherheits-Profil des SPDX 3.0 Release-Kandidaten enthalten. VEX ist auch ein Profil in CSAF-Version 2.0 (siehe CSAF unten).
OpenVEX: Offener Schwachstellen-Ausnutzbarkeitsaustausch
OpenVEX ist eine Implementierung von VEX, die darauf ausgelegt ist, interoperabel und einbettbar zu sein. Obwohl VEX im Prinzip einen Mechanismus bereitstellt, um den Status von Schwachstellen zusammen mit dem SBOM selbst zu kommunizieren, war das Einbetten dieser Status außerhalb von CycloneDX oder CSAF nicht möglich. OpenVEX zielt darauf ab, gegenüber der SBOM-Spezifikation neutral zu sein und fungiert als Alternative zu VEX mit einem formalen Schema, das bereits vorhanden ist.
OpenVEX-Beispiel
CSAF: Gemeinsamer Sicherheitsberatung-Rahmen
OASIS CSAF ist eine offene Spezifikation für die "Erstellung, Aktualisierung und interoperable Weitergabe von Sicherheitswarnungen als strukturierte Informationen über Produkte, Schwachstellen und den Status von Auswirkungen und Abhilfen."
Mit anderen Worten, CSAF macht die Offenlegung von Schwachstellen und deren Auswirkungen programmatisch zugänglich. CSAF zielt jedoch darauf ab, deutlich mehr als nur die Offenlegung und Koordination von Schwachstellen zu sein. Mit Version 2.0, die im November 2022 genehmigt wurde, unterstützt CSAF fünf verschiedene Profile:
CSAF-Basismodell (Standardwerte)
Reaktion auf Sicherheitsvorfälle (bei Sicherheitsvorfällen wie Leaks)
Informationshinweis (für nicht-spezifizierte Informationen, wie Fehlkonfigurationen)
Sicherheitswarnung (für Informationen zu Schwachstellen)
VEX (für Informationen zur Ausnutzbarkeit von Schwachstellen)
Eine CSAF Warnung von RedHat, die eine Schwachstelle in OpenShift erklärt
Best Practices
Die Offenlegung von Sicherheitsanfälligkeiten über VDR ist eine etablierte Praxis, und CSAF hat sich seit 2017 ebenfalls verbessert (z. B. Red Hat CSAF). VEX und OpenVEX sollen direkte Begleiter von SBOM sein, um das Geräusch von Sicherheitsanfälligkeiten zu kontrollieren. Es gibt jedoch keine formelle Spezifikation für VEX (außer den CISA-Beispielen), und OpenVEX ist zum Ende Juni 2023 immer noch v0.0.0. Mit anderen Worten, die Offenlegung des Status von Sicherheitsanfälligkeiten neben SBOM bleibt ein aktives Thema.
Bei Interlynk empfehlen wir die folgenden Prozesse, um die besten Sicherheitspraktiken zu demonstrieren und das Geräusch von Sicherheitsanfälligkeiten in der Organisation zu begrenzen:
1. SBOM pro Version erstellen: Viele SBOM-Generator-Tools, einschließlich Open-Source-Tools, können SBOM aus Abhängigkeitsdiagrammen, CI/CD, Bildanalysen oder Softwarezusammensetzungsanalysen generieren. Für Produkte, die aus zugrunde liegenden Projekten zusammengesetzt sind, verwenden Sie ein Tool wie sbom-assemble, um die SBOM für das Endprodukt zu erstellen und zu verfolgen.
2. SBOM speichern und verfolgen: Während es möglich ist, durch Tools wie sbom-grep einen gewissen Nutzen aus SBOMs zu ziehen, kann ein formelles System (wie SBOM Link) das Verbinden von SBOM mit bekannten Sicherheitsanfälligkeiten mühelos machen und die Artefakte für die Zukunft aufbewahren.
3. Status von Sicherheitsanfälligkeiten aufzeichnen: Für jedes Produktrelease verwenden Sie ein System, um den Status von wichtigen Sicherheitsanfälligkeiten aufzuzeichnen, wie sie durch die SBOM-Analyse identifiziert wurden. Die Definition von wichtigen Sicherheitsanfälligkeiten variiert je nach Anwendungsbereich und Risikotoleranz der Organisation. Dennoch sollten Organisationen mindestens bereit sein, einen Bericht über als kritisch oder hoch gemeldete Sicherheitsanfälligkeiten zu führen. Das Endziel sollte darin bestehen, den Status jeder wichtigen Sicherheitsanfälligkeit an einem einzigen und spezifikationsagnostischen Ort festzuhalten. Dies erleichtert die Übersetzung zu Standards wie CycloneDX VEX, OpenVEX und SPDX3.0 oder CSAF nach Bedarf.
4. Produkt mit SBOM UND Sicherheitsanfälligkeitsstatus/VDR veröffentlichen: Ein Produktrelease, das SBOM umfasst, sollte auch ein Dokument zum Sicherheitsanfälligkeitsstatus enthalten. Ein SBOM ohne die Offenlegung des Sicherheitsanfälligkeitsstatus dürfte unnötiges Geräusch erzeugen. Wenn die Organisation Sicherheitsratgeber über CSAF erstellt, ist dies ein ausgezeichneter Ort für Offenlegungen des Sicherheitsanfälligkeitsstatus. Andernfalls können die Status in CycloneDX 1.4, SPDX 3.0 (demnächst) eingebettet oder zusammen mit SBOM und OpenVEX enthalten werden.
5. VEX für neu entdeckte Sicherheitsanfälligkeiten veröffentlichen: Wenn eine neu gemeldete Sicherheitsanfälligkeit für ein zuvor veröffentlichtes Produkt gilt, müssen eines oder mehrere neue VEX generiert werden, um die Analyse der Sicherheitsanfälligkeit im Verhältnis zum Produkt aufzuzeichnen. Wir empfehlen, so schnell wie möglich mit „In Untersuchung“ zu beginnen und die Aktualisierung vorzunehmen, sobald der Umfang der Sicherheitsanfälligkeit festgestellt wird. Beachten Sie, dass wir nicht empfehlen, den Sicherheitsanfälligkeitsstatus für alle neu gemeldeten Sicherheitsanfälligkeiten zu generieren. Stattdessen empfehlen wir, uns auf Sicherheitsanfälligkeiten zu konzentrieren, die in einem der zuvor veröffentlichten SBOM-Komponenten entdeckt wurden. Deshalb ist das Speichern und Verfolgen von SBOM ein wesentlicher Bestandteil der Praxis.
Die Transparenz von Software über SBOM hat das Potenzial, dringend benötigte Aufmerksamkeit und Ressourcen für Sicherheitspraktiken während der Entwicklung zu schaffen. Dennoch ist das Sicherheitsmanagement ein ressourcenintensives Problem, das schon vor der Einführung von SBOM Teil der Diskussion war. VEX und verwandte Spezifikationen zielen darauf ab, keinen zusätzlichen Stress für die Sicherheitsteams zu verursachen und unnötige Warnungen zu vermeiden. Dies bleibt ein fortlaufender Prozess, aber Organisationen können dennoch robuste Praktiken entwickeln, um Ablenkungen zu minimieren.