SBOM und VEX: Komponenten und Auswirkungen von Schwachstellen
Sytance · Aktualisiert
Eine SBOM identifiziert die Softwarekomponenten eines Produkts. Vulnerability Exploitability eXchange (VEX) gibt an, ob eine bestimmte Schwachstelle dieses Produkt betrifft. Die Bewertung hängt von der Produktversion, ihrer Konfiguration und der Verwendung der Komponente ab.
Komponentenbestand, Abgleich und Auswirkungen
Das Inventar hält fest, ob eine Komponente vorhanden ist. Ein Schwachstellenabgleich zeigt, dass ein Sicherheitshinweis die Komponente oder ihre Version nennt. Die Auswirkungsanalyse prüft anschließend, ob der anfällige Code im tatsächlichen Build und bei der Verwendung des Produkts vorhanden und ausnutzbar ist.
CycloneDX verwendet VEX, um die Bewertung für ein bestimmtes Produkt zu kommunizieren. Beispielsweise kann eine Komponente vorhanden sein, während ein optionales anfälliges Merkmal beim Build ausgeschlossen wurde. Für diese Unterscheidung sind Build-Informationen und Analysen erforderlich.
Die vier OpenVEX-Status
OpenVEX definiert vier Statuswerte. Jeder Status gilt für die in der Erklärung angegebene Produktversion und Schwachstelle.
| OpenVEX-Status | Bedeutung |
|---|---|
| under_investigation | Auswirkungen werden noch bewertet |
| affected | Das angegebene Produkt ist betroffen |
| fixed | Die angegebene Version enthält eine Korrektur |
| not_affected | Das angegebene Produkt ist nicht betroffen |
Ein optionaler Decoder in einem Gateway
Stellen Sie sich ein fiktives Gateway mit einer Parserbibliothek vor, die einen optionalen Decoder enthält. Nehmen wir an, eine Schwachstelle betrifft diesen Decoder. Zunächst ist festzustellen, welcher Build der Bibliothek im ausgelieferten Image enthalten ist und ob der Decoder einkompiliert wurde.
Bestätigen Build-Einstellungen und Analyse der Binärdatei, dass der anfällige Decoder fehlt, können sie eine Erklärung mit dem Status `not_affected` und der Begründung `vulnerable_code_not_present` stützen. Die Erklärung gilt für diesen Build.
Ist der Code vorhanden, aber seine Ausführung unklar, bleibt die Bewertung unter Untersuchung, bis Einstiegspunkte und Ausführungspfade geprüft wurden. Ist das Produkt betroffen und enthält eine spätere Version die Korrektur, bleibt die frühere Version betroffen; für die spätere Version wird eine eigene Erklärung abgegeben.
Begründungen für den Status „nicht betroffen“
OpenVEX verlangt für eine Erklärung mit dem Status `not_affected` eine Begründung oder eine Auswirkungserklärung. Die maschinenlesbaren Begründungen unterscheiden fehlende Komponenten, fehlenden anfälligen Code, Code außerhalb des Ausführungspfads, Einschränkungen der Angreiferkontrolle und eingebaute Gegenmaßnahmen.
Für jede Begründung gelten andere Bedingungen. Eine Netzwerkbeschränkung entfernt keinen anfälligen Code. Bei der Begründung mit einer eingebauten Gegenmaßnahme verlangt OpenVEX einen Schutz, der die Ausnutzung verhindert und vom Nutzer weder deaktiviert noch neu konfiguriert werden kann.
Bei einer Schlussfolgerung zum Codepfad sind die betroffene Funktion, die geprüften Pfade und die Konfigurationsbeschränkungen anzugeben. Die Bewertung ist erneut zu prüfen, wenn sich diese Bedingungen ändern. Hängt die Schlussfolgerung von einer kundenseitig kontrollierten Einstellung ab, ist diese Abhängigkeit klar zu kommunizieren.
VEX-Erklärung eines Lieferanten verwenden
Die VEX-Erklärung eines Lieferanten kann helfen, Warnmeldungen zu filtern oder ihre Priorität zu ändern. Prüfen Sie vor der Verwendung, ob die Quelle vertrauenswürdig ist und die Produktversion übereinstimmt. Prüfen Sie außerdem Veröffentlichungsdatum, Überarbeitungen, geltende Konfiguration und empfohlene Maßnahmen.
Weichen die Angaben eines vertrauenswürdigen Anbieters von der eigenen Analyse ab, sind beide Aufzeichnungen aufzubewahren und die Abweichung ist zu klären. Eine pauschale Erklärung für eine Produktfamilie gilt möglicherweise nicht für einen kundenspezifischen Build mit anderen Komponenten oder Optionen.
Eine SBOM bleibt auch nach Veröffentlichung einer VEX-Erklärung nützlich. Neue Sicherheitshinweise können den Untersuchungsbedarf ändern, und ein überarbeitetes Produkt kann eine alte Schlussfolgerung ungültig machen. Verknüpfen Sie Inventaraktualisierungen und Auswirkungsbewertungen miteinander und bewahren Sie ihre getrennten Verläufe auf.