Dokumentation von Software-Schwachstellen Vulnerability Disclosure Report (VDR) und Vulnerability Exploitability eXchange (VEX)

Anbieter zum Thema

emlix GmbH

Im Umgang mit Open Source Software-Komponenten (OSS) gewinnt die Software-Bill-of-Materials (SBOM) immer mehr an Bedeutung. Sie gibt jedoch nur bedingt Auskunft über die Sicherheit einer Anwendung. Dokumentations-Ansätze wie Vulnerability Disclosure Report (VDR) und Vulnerability Exploitability eXchange (VEX) sind für die richtige Einstufung, Risikominderung und Behebung von Schwachstellen unerlässlich.

Geht es darum, die Sicherheit entlang der Software Supply Chain zu stärken, führt mittlerweile kaum noch ein Weg an der SBOM vorbei. Die Software-Stückliste liefert eine detaillierte Liste aller in einer Anwendung verwendeten Code-Komponenten (z. B. Lizenzierung, Versionen, Beziehungen zu anderen Komponenten und Herkunft). Das Ziel: Rechts- und Sicherheitsteams können Compliance-Probleme schneller bewerten und entschärfen.

Es gibt unterschiedliche Standards für die Erstellung einer SBOM. Das Problem: In der Regel legen diese nur Mindestanforderungen bezüglich der aufzuführenden Daten bzw. Datenfelder vor. Damit die Informationen in einer SBOM jedoch für die Praxis verwertbar werden, sind zusätzliche Daten notwendig. Das heißt jedoch nicht, Informationen über Softwareschwachstellen und Sicherheitslücken direkt in die SBOM zu integrieren. Während die SBOM im Normalfall alle Kompositions- und Lizenzierungsinformationen enthält und so von Version zu Version statisch ist, kann sich der Sicherheitsstatus einer Anwendung schnell ändern. Idealerweise finden sich sicherheitsrelevante Daten daher in einem separaten, dazugehörigen Dokument, das eine aktuelle Momentaufnahme zeigt, und entsprechende Querverweise zu in der SBOM aufgelisteten Code-Komponenten sowie notwendigen Kontext liefert.

Für diese Art der Dokumentation gibt es zwei Ansätze: Vulnerability Disclosure Report (VDR) und Vulnerability Exploitability eXchange (VEX).

Was ist ein Vulnerability Disclosure Report (VDR)?

Ein Vulnerability Disclosure Report (VDR) wird in der Regel von Softwareanbietern oder Dritten/Zulieferern zur Verfügung gestellt und dient dem Nachweis einer ordnungsgemäßen und vollständigen Schwachstellenbewertung für die in einem SBOM aufgeführten Komponenten sowie für das Produkt als Ganzes. Die US-Bundesbehörde NIST (National Institute of Standards and Technology), die den Ansatz unterstützt, gibt umfassende Empfehlungen für den Inhalt und die Bereitstellung eines VDR (NIST SP 800-161).

Demnach sollte der Report sowohl die Analyse als auch die Ergebnisse und die Auswirkungen (Impact) der bekanntgewordenen Schwachstelle auf eine Komponente oder ein Produkt beschreiben. Darüber hinaus sollte der Report Informationen über Pläne zur Behebung der CVE enthalten. Um den VDR zu teilen, empfiehlt die Behörde Anbietern, den VDR in einem sicheren, für Kunden zugänglichen Portal zu veröffentlichen und das Dokument mit einem Schlüssel zu signieren.

Wichtige Elemente eines VDR

Im Grunde belegt ein VDR, dass Softwareanbieter und -zulieferer alle Schwachstellen, die in ihren Anwendungen enthalten sind, ordnungsgemäß offengelegt haben. Ein typischer VDR enthält folgende Informationen:

• Alle Schwachstellen, die ein Produkt oder seine Abhängigkeiten betreffen (sowohl direkte als auch transitive)

• Eine Analyse der Auswirkungen (oder das Fehlen solcher Auswirkungen) auf ein Produkt oder eine Abhängigkeit

• Empfehlungen zur Behebung der Schwachstelle, einschließlich möglicher Lösungsansätze oder Patches

• Eine VDR-Signatur mit einem vertrauenswürdigen, überprüfbaren, privaten Schlüssel, der einen Zeitstempel enthält, der das Datum und die Uhrzeit der Unterzeichnung angibt

Ein VDR sollte also zwei spezifische Informationen abdecken: Zum einen die Aufzählung von Schwachstellen, einschließlich Quelle, Schweregrad und gängige Sicherheitslücken. Zum anderen ein Verweis auf die Abschnitte in der SBOM, für den die Schwachstelle relevant ist.

Besonderheiten von VDR

VDRs sind nicht zwangsläufig an eine SBOM gebunden, sie stellen jedoch eine gute Ergänzung dar. Während SBOMs das Inventar einer Anwendung offenlegen, dokumentieren VDRs Schwachstellen. Werden neue Schwachstellen bekannt, muss auch logischerweise der VDR aktualisiert werden.

VDRs sind in der Regel sehr umfangreich und nicht alle bereitgestellten Informationen sind durchwegs relevant. Nur weil eine Schwachstelle für eine Komponente gemeldet wird, wirkt sie sich nicht automatisch auf die Sicherheit einer Anwendung aus. Wie so oft ist der Kontext entscheidend, in der die Anwendung genutzt wird. Darüber hinaus finden sich auch bei VDRs noch keine fester Standard. Die Reports variieren je nach Organisation oder Vereinbarung zwischen den jeweiligen Partnern. Daher gilt es bei der Erstellung und der Übermittlung von VDRs, die Anforderungen und Richtlinien im Vorfeld klar zu definieren. Sprich: Trotz Dokumentation sollte jede Schwachstelle individuell geprüft werden.

Was ist ein Vulnerability Exploitability eXchange (VEX)?

Auch ein Vulnerability Exploitability eXchange(VEX)-Bericht wird entweder vom Softwareanbieter oder einem Dritten/Zulieferer bereitgestellt. Er gilt als wichtiges Artefakt für die Transparenz und Sicherheit einer Anwendung. VEX wurde bekannt durch eine Initiative der NTIA (National Telecommunications and Information Administration), die sich für mehr Transparenz in der Softwareentwicklung einsetzt. Mittlerweile treibt die CISA (Cybersecurity and Infrastructure Security Agency) in den USA den Dokumentations-Ansatz voran.

VEX soll es Softwareherstellern und Dritt-Anbietern ermöglichen, den Status der Ausnutzbarkeit von Schwachstellen (Exploitability) anzugeben. Im Wesentlichen ist der VEX ein Diagnosewerkzeug, das Klarheit schafft, von welchen Schwachstellen im Zusammenhang mit einem bestimmten Produkt ein Risiko ausgeht und von welchen nicht. Oft wird der Bericht als eine Art „negatives Security Advisory“ bezeichnet: Er erklärt, warum eine Schwachstelle keine Auswirkungen auf eine Anwendung hat. Dadurch sollen Sicherheitsexperten Vulnerabilities in Anwendungen schneller priorisieren und beheben können.

Wichtige Elemente eines VEX

Ein VEX-Bericht sollte folgende Informationen bereitstellen:

• Eine Analyse, die die Auswirkungen (oder deren Fehlen) einer Schwachstelle auf ein Produkt, eine Produktfamilie oder eine Organisation beschreibt

• Pläne zur Behebung der Schwachstelle

• Eine VEX-Signatur mit einem vertrauenswürdigen, überprüfbaren privaten Schlüssel einschließlich eines Zeitstempels, der das Datum und die Uhrzeit der VEX-Signatur angibt

Die CISA stellt für VEX zudem weitere Mindestanforderungen auf:

• VEX-Metadaten wie VEX Format Identifier (ob im CycloneDX- oder CSAF-Format), Identifier-String für das VEX-Dokument, Autor/Herausgeber/Anbieter, Titel und Zeitstempel

• Produktangaben wie Product Identifier, Product Family Identifier, Name des Lieferanten, Produktname, Versionsstring

• CVE oder andere Identifikatoren/Beschreibung der Sicherheitslücke

• Kontext der Schwachstelle (CVE) in Bezug auf eine Anwendung und Komponenten nach vier vordefinierten Kategorien:

• Not affected – Eine bestimmte Softwarekomponente ist von dieser Sicherheitslücke nicht betroffen und erfordert daher keine Maßnahmen. Im VEX-Dokument werden die Gründe für den Status in einem maschinenlesbaren Feld angegeben.

• Affected – Die Komponente ist von der Sicherheitslücke betroffen und es werden Abhilfemaßnahmen empfohlen.

• Fixed – Ein für eine bestimmte Sicherheitslücke verfügbarer Patch oder eine Maßnahme wurden für die in der SBOM gelisteten Version angewandt.

• Under Investigation or To Be Researched – Es ist nicht bekannt, ob die Komponenten von einer bestimmten Sicherheitslücke betroffen sind. Updates werden bereitgestellt, sobald sie verfügbar sind.

Besonderheiten von VEX

VEX-Berichte sind so konzipiert, dass sie sich in SBOM, Schwachstellendatenbanken und Security Advisories integriert lassen. In Kombination liefern VEX und SBOM ein vollständiges Bild des Risikos in einem bestimmten Kontext zu einem bestimmten Zeitpunkt. Sie lassen sich aber auch unabhängig voneinander verwenden. VEX ist noch ein relativ neuer Ansatz. Seit seiner Einführung gibt es bereits unterschiedliche Versuche, optionale Elemente für die Automatisierung und Interoperabilität hinzuzufügen bzw. weiter zu definieren und zu spezifizieren.

Es gibt unterschiedliche Formate für VEX: Das Common Security Advisory Framework (CSAF) wurde von OASIS Open entwickelt. CycloneDX stammt von der OWASP Foundation. Jedes dieser Formate kann für die Kommunikation mit Kunden und Aufsichtsbehörden verwendet werden. Dabei gilt es zu beachten: VEX liefert Kontext zu bekannten Schwachstellen/Risiken von Softwarekomponenten, nicht jedoch zu unbekannten oder neuen Schwachstellen. Für diese ist eine Aktualisierung nötig. Der Kontext von VEX ist für die Festlegung von Maßnahmen (Remediaton & Mitigation) durchaus hilfreich. Umfassende Tools zur Analyse des Software-Codes (Software Composition Analysis) sowie regelmäßige Schwachstellen-Scans entlang des Software Development Life Cycles (SDLC) sind jedoch unerlässlich.

Unterschied zwischen VDR und VEX?

Oberflächlich betrachtet sehen VDR und VEX sehr ähnlich aus. Beide beziehen sich auf Schwachstellen, beide enthalten eine Analyse der Auswirkungen, und beide enthalten Pläne zur Behebung der Schwachstellen. Worin besteht also der Unterschied?

Wie die SBOM ist auch ein VEX so konzipiert, dass er maschinenlesbar ist. VDRs hingegen sind „menschenlesbar“ und sollen das Sicherheitsbewusstsein von Anwendern schärfen und aufzeigen, wo Handlungsbedarf für sie besteht. Ein weiteres Unterscheidungskriterium: VDRs decken sowohl Komponenten als auch Produkte ab, während sich VEX auf das Produkt konzentriert. Das ist einer der Gründe, warum VEX überhaupt existiert: Eine komponentenzentrierten Analyse ohne Produktkontext ist in manchen Fällen ungenügend. Details der Implementierung sind zentral. Erst wenn eine Schwachstelle im Kontext des Software-Produkts betrachtet wird, lässt sie sich auch hinsichtlich ihrer Kritikalität und ihrer Auswirkungen bewerten. Eine kompakte Gegenüberstellung von VDR und VEX findet sich beispielsweise in einem Blog der Open Worldwide Application Security Project® (OWASP) von Steve Springett (Grafik 3).

Klarzustellen ist jedoch die Tatsache: VDR und VEX schließen sich nicht aus. Eine hybride Dokumentationsform ist durchaus denkbar. In ihrem Leitfaden weist NIST auf die Möglichkeit hin, einen separaten Benachrichtigungskanal für Kunden aufzubauen, um Schwachstellen zu kommunizieren, die zu sensibel sind, um sie in Reports mitaufzunehmen. Damit bleibt die Tür für weitere Ansätze offen. Welche Berichtsform sich innerhalb Entwickler- und Security-Kreise letztendlich durchsetzen wird, hängt von unterschiedlichen Faktoren ab. Dazu gehören neben Präferenzen auf regulatorischer Seite auch schlichtweg Praktikabilität und Pragmatismus bei der Entwicklung von Software und dem Management von Schwachstellen.

* Nicole Segerer blickt auf über 15 Jahre Erfahrung in den Bereichen Softwareproduktstrategie und Marketing zurück. Bei ihr dreht sich alles um die Analyse von Softwareprodukten und darum, den Mehrwert der Lösungen sowie das Kundenerlebnis zu steigern. Als SVP und General Manager von Revenera bei Revenera unterstützt sie Softwareanbieter und IoT-Hersteller bei der Umstellung auf neue digitale Geschäftsmodell und der Optimierung der Softwaremonetarisierung.

(ID:49891243)