Implementierung der Mindestanforderungen für VEX
11.12.2023
Ingenieurwesen
Das Software-Bill of Materials (SBOM) wird durch SBOM-Qualität und anfälligkeitsspezifische Geräusche behindert. CISA hat empfohlen, VEX-Informationen mit mindestanforderungen für die Verwundbarkeitsexploitiertbarkeitsaustausch zu erstellen, um Letzteres anzugehen.
Das Dokument zu den VEX-Mindestanforderungen empfiehlt, Felder in die VEX aufzunehmen, die in einem SBOM oder als eigenständiges Dokument eingebettet sind.
In einem früheren Beitrag haben wir uns darauf konzentriert, wo CycloneDX VEX, OpenVEX und CSAF in Bezug auf die Offenlegung von Sicherheitsanfälligkeiten stehen.
In diesem Beitrag brechen wir die Feldzuordnungen der Mindestanforderungen zu CycloneDX VEX und OpenVEX auf.
Mindestensanforderungen für VEX
VEX, ein Akronym für Vulnerability Exploitability eXchange, ist ein strukturiertes Datenformat, das den Austausch von Schwachstelleninformationen zwischen Softwareanbietern, Sicherheitsanalysten und Verbrauchern erleichtert. Es zielt darauf ab, die Herausforderungen im Zusammenhang mit veralteten Schwachstellenhinweisen zu bewältigen, die oft keine maschinenlesbare Form haben und nicht vermitteln, ob eine Schwachstelle in einem bestimmten Produkt oder Umfeld tatsächlich ausnutzbar ist.
Das Dokument der CISA mit den Mindestanforderungen für VEX definiert die minimalen Elemente unabhängig vom VEX-Format oder der Spezifikation mit einem Fokus auf maschinenlesbare Formate.
Es beschreibt ein VEX-Dokument, das in VEX-Dokumentmetadaten und mindestens eine VEX-Erklärung unterteilt ist, die wiederum aus Erklärungsmetadaten, Status, Schwachstellendetails und Produktdetails besteht.
Dokumentmetadaten
MUß Dokument-ID, eine oder mehrere Dokumentversionen, Autor, Zeitstempel der ersten Ausgabe und Zeitstempel der letzten Aktualisierung enthalten.
DARF Werkzeuge und Autorrolle enthalten
Metadaten der VEX-Erklärung
MUß Erklärungs-ID, Erklärungsversion, Zeitstempel der ersten Ausgabe und Zeitstempel der letzten Aktualisierung enthalten
VEX-Erklärung Produkt
MUß Produkt-ID und Anbieter enthalten
DARF Unterkomponenten-ID enthalten
VEX-Erklärung Schwachstelle
MUß Schwachstellen-ID und Beschreibung enthalten
VEX-Erklärung Status
MUß Schwachstellenstatus und bedingt MUß Begründung (für den Status Nicht betroffen) oder Wirkungsbeschreibung (für den Status Nicht betroffen, aber keine Begründung). Es muß bedingt ein Handelnde Erklärung für den Status Betroffen.
DARF Zeitstempel der Auswirkungen oder der Handlung und DARF Statusnotizen enthalten
Minimale Anforderungen in CycloneDX
CycloneDX hat Schwachstellen und deren Analyse als Felder in der Version 1.4 eingefügt und sie mit der Version 1.5 erweitert. Daher ist CycloneDX eine natürliche Spezifikation zum Einbetten von VEX-Informationen mit dem SBOM.
Einige Feldzuordnungen könnten jedoch auf den ersten Blick nicht offensichtlich sein.
Interlynk empfiehlt, die Mindestanforderungen für VEX mit CycloneDX wie folgt umzusetzen:
Dokumentmetadaten
Dokument-ID: [Erforderlich] Seriennummer
Dokumentversion: [Erforderlich] Version
Autor: [Erforderlich] Metadatenautoren
Zeitstempel erste Ausgabe: [Erforderlich] Schwachstellenanalyse erste Ausgabe (Version 1.5+)
Zeitstempel letzte Aktualisierung: [Erforderlich] Schwachstellenanalyse letzte Aktualisierung (Version 1.5+)
Werkzeuge: [Optional] Metadatenwerkzeuge (Hinweis: CycloneDX hat auch einen Schwachstellen: Werkzeuge-Bereich, der dazu dient, Werkzeuge zur Identifizierung und Analyse von Schwachstellen aufzulisten).
Autorrolle: [Optional] Unzugeordnet
VEX-Erklärungsmetadaten
Erklärungs-ID: [Erforderlich] Schwachstellenanalyse Bom-Ref
Zeitstempel erste Ausgabe: [Erforderlich] Schwachstellenanalyse erste Ausgabe (Version 1.5+)
Zeitstempel letzte Aktualisierung: [Erforderlich] Schwachstellenanalyse letzte Aktualisierung (Version 1.5+)
VEX-Erklärung Produkt
Produkt-ID: [Erforderlich] Schwachstellenanalyse betrifft Ref
Lieferant: [Erforderlich] Komponentenlieferant, bei dem die Komponenten-Bom-Ref die gleiche wie die Produkt-ID ist (Betroffenes Produkt/Komponente)
Unterkomponenten-ID: [Optional] Schwachstellenanalyse betrifft Ref
VEX-Erklärung Schwachstelle
Schwachstellen-ID: [Erforderlich] Schwachstellen-ID
Schwachstellenbeschreibung: [Erforderlich] Schwachstellenbeschreibung
VEX-Erklärung Status [Erforderlich]
Status „Nicht betroffen“: Schwachstellenanalyse Status: nicht_betroffen
Status „Betroffen“: Schwachstellenanalyse Status: ausnutzbar
Status „Behoben“: Schwachstellenanalyse Status: behoben
Status „In Untersuchung“: Schwachstellenanalyse Status: in_triage
Statusnotizen: [Optional] Schwachstellenanalyse Detail
VEX-Erklärung Begründung [Bedingt erforderlich]
Begründung „Komponente_nicht_vorhanden“: Schwachstellenanalyse Begründung: erfordert_abhängigkeit
Begründung „Anfälliger_Code_nicht_vorhanden“: Schwachstellenanalyse Begründung: code_nicht_vorhanden
Begründung „Anfälliger_Code_nicht_im_Ausführungsweg“: Schwachstellenanalyse Begründung: code_nicht_erreichbar
Begründung „Anfälliger_Code_kann_von_Feind_nicht_gesteuert_werden“: Schwachstellenanalyse Begründung: erfordert_umgebung
Begründung „Inline_Minderungen_sind_bereits_gegeben“: Schwachstellenanalyse Begründung: geschützt_durch_mindernde_kontrolle
VEX-Erklärung Auswirkungen
Auswirkungsstatement: [Bedingt erforderlich] Schwachstellenanalyse Detail (Hinweis: CycloneDX schwachstelle>analyse>detail wird als Detaillierte Beschreibung der Auswirkungen einschließlich der während der Bewertung verwendeten Methoden beschrieben. Wenn eine Schwachstelle nicht ausnutzbar ist, sollte dieses Feld spezifische Details enthalten, warum die Komponente oder der Dienst von dieser Schwachstelle nicht betroffen ist. Dies entspricht der CISA-Notiz des Auswirkungsstatements: Für den [Status] „nicht betroffen“, wenn [Begründung] nicht bereitgestellt wird, muss eine VEX-Erklärung ein [Auswirkungsstatement] bereitstellen, das näher erläutert, wie oder warum die aufgeführten [Produkt_ID]s „nicht betroffen“ von [vul_id] sind.)
Zeitstempel Auswirkungsstatement: [Optional] Schwachstellenanalyse letzte Aktualisierung (Version 1.5+)
VEX-Erklärung Handlungsanweisung
Handlungsanweisung: [Bedingt erforderlich] Schwachstellennachweisung (Hinweis: CycloneDX schwachstelle>empfehlung wird als Empfehlungen beschrieben, wie die Schwachstelle behoben oder gemildert werden kann. Dies entspricht der CISA-vorgeschlagenen Rolle des Handlungsstatements: Für den Status „betroffen“ muss eine VEX-Erklärung ein [Handlungsstatement] enthalten, das die Maßnahmen zur Behebung oder Minderung von [vul_id] beschreiben sollte.)
Zeitstempel Handlungsanweisung: [Optional] Schwachstellenanalyse letzte Aktualisierung (Version 1.5+)
Mindestanforderungen in OpenVEX
OpenVEX Spezifikation wurde aktualisiert neben der CISA-Arbeitsgruppe, die das Dokument zu den Mindestanforderungen verfasst hat, und daher bietet OpenVEX die direkteste Zuordnung zu den referenzierten Feldern.
Dokumentenmetadata
Dokumenten-ID: [Erforderlich] @id
Dokumentversion: [Erforderlich] version
Autor: [Erforderlich] author
Erstellungszeitstempel: [Erforderlich] timestamp
Zuletzt aktualisierter Zeitstempel: [Erforderlich] last_updated
Autorrolle: [Optional] role
Werkzeuge: [Optional] tooling
VEX-Aussage-Metadaten
Aussage-ID: [Erforderlich] statements:@id
Erstellungszeitstempel: [Erforderlich] statements:timestamp
Zuletzt aktualisierter Zeitstempel: [Erforderlich] statements:last_updated
VEX-Aussage Produkt
Produkt-ID: [Anforderung] products:@id
Lieferant: [Erforderlich] supplier
Unterkomponenten-ID: [Optional] subcomponents:@id
VEX-Aussage Verwundbarkeit
Verwundbarkeits-ID: [Erforderlich] vulnerbilities:@id
Beschreibung der Verwundbarkeit: [Erforderlich] vulnerabilities:description
VEX-Aussage Status [Erforderlich]
Status "Nicht Betroffen": statements:status:not_affected
Status "Betroffen": statements:status:affected
Status "Behoben": statements:status:fixed
Status "Unter Untersuchung": statements:status:under_investigation
Statusnotizen: [Optional] statements:status_notes
VEX-Aussage Begründung [Bedingt erforderlich]
Begründung "Komponente_nicht_vorhanden": statements:justification:component_not_present
Begründung "Verwundbarer_Code_nicht_vorhanden": statements:justification:vulnerable_code_not_present
Begründung "Verwundbarer_Code_nicht_im_Ausführungsweg": statements:justification:vulnerable_code_not_in_execute_path
Begründung "Verwundbarer_Code_kann_von_Gegner_nicht_kontrolliert_werden": statements:justification:vulnerable_code_cannot_be_controlled_by_adversary
Begründung "Inline_Minderungsmaßnahmen_existieren_bereits": statements:vulnerable_code_cannot_be_controlled_by_adversary
VEX-Aussage Auswirkungen
Auswirkungen: [Bedingt erforderlich] statements:impact_statement
Zeitstempel der Auswirkungen: [Optional] statements:impact_statement_timestamp
VEX-Aussage Handlungsaufforderung
Handlungsaufforderung: [Bedingt erforderlich] statements:action_statement
Zeitstempel der Handlungsaufforderung: [Optional] statements:action_statement_timestamp
Eine bessere Nutzung von SBOM für die Verwaltung von Verwundbarkeiten und Risikobewertung erfordert die maschinenlesbare Grundlage des VEX-Dokuments. Daher empfehlen wir, VEX innerhalb von CycloneDX oder OpenVEX unter Verwendung einer allgemein vereinbarten Konvention zu erstellen.
Interlynk versucht, die Sicherheitsoffenlegung einfach, offensichtlich und automatisiert zu gestalten. Wir freuen uns darauf, Fragen zu beantworten. Zögern Sie nicht, uns unter hello@interlynk.io oder über interlynk.io zu kontaktieren.