Implementierung von Mindestanforderungen für VEX
| Ingenieurwesen
Die Software-Stückliste (SBOM) wird durch SBOM-Qualität und schwachstellenspezifisches Rauschen erschwert. Die CISA hat empfohlen, VEX-Informationen mit Mindestanforderungen für den Vulnerability Exploitability eXchange (VEX) zu erstellen, um Letzteres anzugehen.
Das VEX-Mindestanforderungsdokument empfiehlt, bestimmte Felder in die in eine SBOM eingebettete VEX oder als eigenständiges Dokument aufzunehmen.
In einem früheren Beitrag haben wir uns darauf konzentriert, detailliert darzustellen, wo CycloneDX VEX, OpenVEX und CSAF im Verhältnis zur Offenlegung von Schwachstellen stehen.
In diesem Beitrag schlüsseln wir die Feldzuordnungen der Mindestanforderungen zu CycloneDX VEX und OpenVEX auf.
Mindestanforderungen für VEX
VEX, ein Akronym für Vulnerability Exploitability eXchange, ist ein strukturiertes Datenformat, das den Austausch von Schwachstelleninformationen zwischen Softwareherstellern, Sicherheitsanalysten und Verbrauchern erleichtert. Es zielt darauf ab, die Herausforderungen zu bewältigen, die mit herkömmlichen Schwachstellenmeldungen verbunden sind. Diesen fehlt es oft an Maschinenlesbarkeit und sie vermitteln nicht, ob eine Schwachstelle in einem bestimmten Produkt oder einer bestimmten Umgebung tatsächlich ausnutzbar ist.
Das Dokument von CISA „Minimum Requirements for VEX“ definiert die Mindestelemente unabhängig vom VEX-Format oder der Spezifikation, wobei der Schwerpunkt auf der Maschinenlesbarkeit liegt.
Es beschreibt ein VEX-Dokument, das in VEX-Dokument-Metadaten und mindestens eine VEX-Erklärung unterteilt ist, die wiederum aus Erklärungs-Metadaten, Status, Details zur Schwachstelle und Produktdetails besteht.
Dokument-Metadaten
MÜSSEN die Dokumenten-ID, eine oder mehrere Dokumentenversionen, den Autor, den Zeitstempel der Erstausgabe und den Zeitstempel der letzten Aktualisierung enthalten.
KÖNNEN Tooling und die Rolle des Autors enthalten.
VEX-Erklärungs-Metadaten
MÜSSEN die Erklärungs-ID, die Erklärungsversion, den Zeitstempel der Erstausgabe und den Zeitstempel der letzten Aktualisierung enthalten.
VEX-Erklärung Produkt
MUSS die Produkt-ID und den Anbieter enthalten.
KANN die Subkomponenten-ID enthalten.
VEX-Erklärung Schwachstelle
MUSS die Schwachstellen-ID und eine Beschreibung enthalten.
VEX-Erklärung Status
MUSS den Schwachstellenstatus enthalten und unter bestimmten Bedingungen MUSS sie eine Begründung (für den Status Nicht betroffen) oder eine Auswirkungserklärung (für den Status Nicht betroffen ohne Begründung) enthalten. Sie MUSS unter bestimmten Bedingungen eine Aktionserklärung für den Status Betroffen enthalten.
KANN den Zeitstempel der Auswirkungs- oder Aktionserklärung enthalten und KANN Statusnotizen enthalten.
Mindestanforderungen in CycloneDX
CycloneDX hat Schwachstellen und deren Analyse ab Version 1.4 als Felder integriert und diese mit Version 1.5 erweitert. Daher ist CycloneDX eine natürliche Spezifikation zur Einbettung von VEX-Informationen in die SBOM.
Einige Feldzuordnungen sind jedoch auf den ersten Blick möglicherweise nicht offensichtlich.
Interlynk empfiehlt, die Mindestanforderungen für VEX mit CycloneDX wie folgt zu implementieren:
Dokumenten-Metadaten
Dokument-ID: [Erforderlich] Seriennummer
Dokumentversion: [Erforderlich] Version
Autor: [Erforderlich] Metadaten-Autoren
Zeitstempel der Erstveröffentlichung: [Erforderlich] Schwachstellenanalyse firstIssued (Version 1.5+)
Zeitstempel der letzten Aktualisierung: [Erforderlich] Schwachstellenanalyse lastUpdated (Version 1.5+)
Tooling: [Optional] Metadaten-Tools (Hinweis: CycloneDX verfügt auch über einen Bereich Schwachstellen: Tools, dieser ist jedoch so konzipiert, dass er Tools zur Identifizierung und Analyse von Schwachstellen auflistet).
Autorenrolle: [Optional] Nicht zugeordnet
VEX-Erklärungs-Metadaten
Erklärungs-ID: [Erforderlich] Schwachstellenanalyse Bom-Ref
Zeitstempel der Erstveröffentlichung: [Erforderlich] Schwachstellenanalyse firstIssued (Version 1.5+)
Zeitstempel der letzten Aktualisierung: [Erforderlich] Schwachstellenanalyse lastUpdated (Version 1.5+)
VEX-Erklärung Produkt
Produkt-ID: [Erforderlich] Schwachstellenanalyse Affects Ref
Lieferant: [Erforderlich] Komponentenlieferant, wobei die Komponente bom-ref mit der Produkt-ID übereinstimmt (Betroffenes Produkt/Komponente)
Unterkomponenten-ID: [Optional] Schwachstellenanalyse Affects Ref
VEX-Erklärung Schwachstelle
Schwachstellen-ID: [Erforderlich] Schwachstellen-ID
Schwachstellenbeschreibung: [Erforderlich] Schwachstellenbeschreibung
VEX-Erklärungsstatus [Erforderlich]
Status „Nicht betroffen“: Schwachstellenanalyse Status: not_affected
Status „Betroffen“: Schwachstellenanalyse Status: exploitable
Status „Behoben“: Schwachstellenanalyse Status: resolved
Status „In Untersuchung“: Schwachstellenanalyse Status: in_triage
Statusbemerkungen: [Optional] Schwachstellenanalyse Detail
VEX-Erklärung Begründung [Bedingt erforderlich]
Begründung „Component_not_present“: Schwachstellenanalyse Begründung: requires_dependency
Begründung „Vulnerable_code_not_present“: Schwachstellenanalyse Begründung: code_not_present
Begründung „Vulnerable_code_not_in_execute_path“: Schwachstellenanalyse Begründung: code_not_reachable
Begründung „Vulnerable_code_cannot_be_controlled_by_adversary“: Schwachstellenanalyse Begründung: requires_environment
Begründung „Inline_mitigations_already_exist“: Schwachstellenanalyse Begründung: protected_by_mitigating_control
VEX-Erklärung Auswirkungsbeschreibung
Auswirkungsbeschreibung: [Bedingt erforderlich] Schwachstellenanalyse Detail (Hinweis: CycloneDX vulnerability>analysis>detail ist beschrieben als Detaillierte Beschreibung der Auswirkungen einschließlich der bei der Bewertung angewandten Methoden. Wenn eine Schwachstelle nicht ausnutzbar ist, sollte dieses Feld spezifische Details darüber enthalten, warum die Komponente oder der Dienst von dieser Schwachstelle nicht betroffen ist. Dies entspricht dem CISA-Hinweis zur Auswirkungsbeschreibung: Für den [Status] „not_affected“ MUSS eine VEX-Erklärung, wenn keine [Begründung] angegeben ist, eine [Auswirkungsbeschreibung] (impact_statement) bereitstellen, die näher erläutert, wie oder warum die aufgeführten [product_id]s nicht von der [vul_id] betroffen („not_affected“) sind.)
Zeitstempel der Auswirkungsbeschreibung: [Optional] Schwachstellenanalyse lastUpdated (Version 1.5+)
VEX-Erklärung Haken/Maßnahme
Maßnahmebeschreibung: [Bedingt erforderlich] Schwachstellenempfehlung (Hinweis: CycloneDX vulnerability>recommendation ist beschrieben als Empfehlungen, wie die Schwachstelle behoben oder abgemildert werden kann. Dies entspricht der von der CISA vorgeschlagenen Rolle der Maßnahmebeschreibung: Für den Status „affected“ MUSS eine VEX-Erklärung eine [Maßnahmebeschreibung] (action_statement) enthalten, die Maßnahmen zur Behebung oder Abmilderung der [vul_id] beschreiben SOLLTE.)
Zeitstempel der Maßnahmebegründung: [Optional] Schwachstellenanalyse lastUpdated (Version 1.5+)
Mindestanforderungen in OpenVEX
Die Spezifikation von OpenVEX wurde parallel zur Ausarbeitung des Dokuments über die Mindestanforderungen der CISA-Arbeitsgruppe aktualisiert. Daher bietet OpenVEX die direkteste Zuordnung zu den referenzierten Feldern.
Dokument-Metadaten
Dokumenten-ID: [Erforderlich] @id
Dokumentenversion: [Erforderlich] version
Autor: [Erforderlich] author
Zeitstempel der Erstausstellung: [Erforderlich] timestamp
Zeitstempel der letzten Aktualisierung: [Erforderlich] last_updated
Rolle des Autors: [Optional] role
Tooling: [Optional] tooling
Metadaten der VEX-Erklärung
Erklärungs-ID: [Erforderlich] statements:@id
Zeitstempel der Erstausstellung: [Erforderlich] statements:timestamp
Zeitstempel der letzten Aktualisierung: [Erforderlich] statements:last_updated
Produkt der VEX-Erklärung
Produkt-ID: [Erforderlich] products:@id
Lieferant: [Erforderlich] supplier
Subkomponenten-ID: [Optional] subcomponents:@id
Schwachstelle der VEX-Erklärung
Schwachstellen-ID: [Erforderlich] vulnerbilities:@id
Beschreibung der Schwachstelle: [Erforderlich] vulnerabilities:description
Status der VEX-Erklärung [Erforderlich]
Status „Nicht betroffen“: statements:status:not_affected
Status „Betroffen“: statements:status:affected
Status „Behoben“: statements:status:fixed
Status „In Untersuchung“: statements:status:under_investigation
Status-Notizen: [Optional] statements:status_notes
Begründung der VEX-Erklärung [Bedingt erforderlich]
Begründung „Komponente nicht vorhanden“: statements:justification:component_not_present
Begründung „Schwachstellenbehafteter Code nicht vorhanden“: statements:justification:vulnerable_code_not_present
Begründung „Schwachstellenbehafteter Code nicht im Ausführungspfad“: statements:justification:vulnerable_code_not_in_execute_path
Begründung „Schwachstellenbehafteter Code kann nicht vom Angreifer kontrolliert werden“: statements:justification:vulnerable_code_cannot_be_controlled_by_adversary
Begründung „Integrierte Schadensminderungen existieren bereits“: statements:vulnerable_code_cannot_be_controlled_by_adversary
Auswirkungserklärung der VEX-Erklärung
Auswirkungserklärung: [Bedingt erforderlich] statements:impact_statement
Zeitstempel der Auswirkungserklärung: [Optional] statements:impact_statement_timestamp
Maßnahmenbeschreibung der VEX-Erklärung
Maßnahmenbeschreibung: [Bedingt erforderlich] statements:action_statement
Zeitstempel der Maßnahmenbeschreibung: [Optional] statements:action_statement_timestamp
Eine bessere Nutzung von SBOMs für das Schwachstellenmanagement und die Risikobewertung erfordert eine grundlegende maschinelle Lesbarkeit des VEX-Dokuments. Daher empfehlen wir, VEX innerhalb von CycloneDX oder OpenVEX unter Verwendung einer gemeinsam vereinbarten Konvention zu erstellen.
Interlynk bemüht sich darum, Sicherheitsmeldungen einfach, verständlich und automatisiert zu gestalten. Wir beantworten gerne alle Ihre Fragen. Sie können uns jederzeit unter hello@interlynk.io oder über interlynk.io erreichen.