Software-Transparenz erfährt derzeit einen dringend benötigten und lang erwarteten Aufschwung. Die Software-Stückliste (SBOM – Software Bill of Materials) soll zum wichtigsten Artefakt für Software-Transparenz und Schwachstellenkoordination innerhalb und zwischen Organisationen werden. Da SBOM-Formate notwendige Details enthalten, wie z. B. Softwarekomponenten und deren Herkunft, kann eine gute SBOM verwendet werden, um bekannte Schwachstellen in der Software zu verfolgen und zu überwachen.
Die SBOM-Komponentenliste kann in Verbindung mit Schwachstellendatenbanken (z. B. NVD) verwendet werden, um eine Schwachstellenliste für das Produkt zu erstellen.
Eine SBOM allein codiert jedoch unter Umständen nicht genügend Details, um nicht ausnutzbare Schwachstellen von ausnutzbaren zu unterscheiden. Dies kann zu einer neuen Flut von Rauschen in einer ohnehin schon unruhigen Umgebung von Sicherheitsdatenpunkten führen.
Frühe Anwender von SBOM haben dies erkannt und sowohl neue Standards als auch Aktualisierungen bestehender Standards vorgeschlagen, um den Status jeder Schwachstelle direkt neben der SBOM selbst anzugeben. In diesem Zusammenhang spielen bestehende Praktiken wie VDR und CSAF sowie die im Entstehen begriffenen Standards VEX und OpenVEX eine Schlüsselrolle.
VDR: Bericht zur Offenlegung von Schwachstellen
VDR ist die Liste der bekannten Schwachstellen, die vom Softwarehersteller veröffentlicht wird. Ein typisches Dokument listet Schwachstellen, die zugehörige CVE, CVSS, Auswirkungen, den Zeitplan und Abhilfestrategien sowie die Kontaktinformationen innerhalb des Herstellers auf. Der VDR ist nicht für den programmgesteuerten Verbrauch konzipiert, und das tatsächliche Format (HTML, Excel, PDF, CSV) kann je nach Organisation variieren.
Beispiel für einen Vulnerability Disclosure Report bei Invicti
NIST-800–161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations empfiehlt die folgende Rolle für VDR, um ein detailliertes Verständnis und ein proaktives Management von Schwachstellen zu demonstrieren.
Unternehmen können, sofern anwendbar und angemessen, in Erwägung ziehen,
Kunden einen Vulnerability Disclosure Report (VDR) zur Verfügung zu stellen, um
ordnungsgemäße und vollständige Schwachstellenbewertungen für die in den
SBOMs aufgeführten Komponenten nachzuweisen. Der VDR sollte die Analyse und die Ergebnisse enthalten, die die
Auswirkungen (oder das Fehlen von Auswirkungen) beschreiben, die die gemeldete Schwachstelle auf eine
Komponente oder ein Produkt hat. Der VDR sollte auch Informationen über Pläne
zur Behebung der CVE enthalten. Unternehmen sollten in Erwägung ziehen, den VDR
in einem sicheren Portal zu veröffentlichen, das für Kunden zugänglich ist, und den VDR mit
einem vertrauenswürdigen, überprüfbaren, privaten Schlüssel zu signieren, der einen Zeitstempel enthält, der
Datum und Uhrzeit der VDR-Signatur und des zugehörigen VDR angibt. Unternehmen
sollten auch in Erwägung ziehen, einen separaten Benachrichtigungskanal für
Kunden einzurichten, falls Schwachstellen auftreten, die nicht im VDR
offengelegt sind. Unternehmen sollten von ihren Hauptauftragnehmern verlangen, dass sie
diese Kontrolle implementieren und diese Anforderung an die relevanten
Unterauftragnehmer weitergeben.
VDR meldet bekannte Schwachstellen des Produkts, hat aber keinen direkten Bezug zur SBOM
Während VDR theoretisch den Status jeder Schwachstelle beschreiben kann, macht das Fehlen eines gemeinsamen Berichtsstandards die Nutzung für Programme weniger praktisch und stellt daher einen Engpass bei der Bewertung der Ausnutzbarkeit von Schwachstellen dar.
VEX: Vulnerability Exploitability eXchange (Austauschformat zur Ausnutzbarkeit von Schwachstellen)
Das Konzept von VEX entwickelte sich innerhalb derselben NTIA-Multistakeholder-Gruppe, die auch die SBOM-Empfehlungen in SBOM Framing und SBOM Minimum Elements formalisierte. VEX ist noch nicht formalisiert, aber sein Ansatz zielt darauf ab, eine Aussage über den Status einer Schwachstelle in bestimmten Produkten oder Versionen zu teilen. Der Status kann sein: — Not Affected (Nicht betroffen), Affected (Betroffen), Fixed (Behoben), Under Investigation (Wird untersucht).
VEX: Einzelnes Dokument, das mehrere Produkte, mehrere Schwachstellen und mehrere Status umfasst
Anfang dieses Jahres einigte sich die Arbeitsgruppe auch auf die Mindestanforderungen für VEX (Minimum Requirements for VEX), bei denen jedes VEX-Dokument als eine Reihe von VEX-Aussagen beschrieben wird, wobei jede Aussage einen Status für eine Schwachstelle enthält.
VEX-Dokument und -Aussagen aus den Mindestanforderungen für VEX
Mit anderen Worten: Wenn SBOM und VEX zusammen verwendet werden, kann eine gut beschriebene SBOM Komponenten und möglichen Schwachstellen zugeordnet werden, während VEX dazu verwendet werden kann, die Anzahl der tatsächlich zutreffenden Schwachstellen zu reduzieren. Ein Community-Mitglied beschrieb dies treffend mit den Worten: „Zuerst schaltet die SBOM alle relevanten Lichter ein, und VEX schaltet alle unnötigen wieder aus.“
VEX-Varianten: VEX1 in SBOM integriert, um einige Status auszuschalten, VEX2 später veröffentlicht, um neu entdeckte Schwachstellen auszuschalten, VEX3 später veröffentlicht, um laufende Arbeiten für eine andere Schwachstelle zu deklarieren
Obwohl nicht zwingend erforderlich, ist ein VEX-Dokument als direkter Begleiter zur SBOM gedacht. VEX kann direkt in CycloneDX 1.4 eingebettet werden und ist im Security-Profil des Release Candidate von SPDX 3.0 enthalten. VEX ist außerdem ein Profil in CSAF-Version 2.0 (siehe CSAF unten).
OpenVEX: Offener Austausch über Schwachstellen-Ausnutzbarkeit (Open Vulnerability Exploitability eXchange)
OpenVEX ist eine Implementierung von VEX, die auf Interoperabilität und Einbettbarkeit ausgelegt ist. Während VEX im Prinzip einen Mechanismus zur Übermittlung des Status von Schwachstellen zusammen mit der SBOM selbst bereitstellte, war die Einbettung dieser Status außerhalb von CycloneDX oder CSAF nicht möglich. OpenVEX zielt darauf ab, agnostisch gegenüber der SBOM-Spezifikation zu sein, und fungiert als Alternative zu VEX mit einem bereits vorhandenen formalen Schema.
OpenVEX-Beispiel
CSAF: Common Security Advisory Framework (Gemeinsames Sicherheitsberatungs-Framework)
OASIS CSAF ist eine offene Spezifikation für die „Erstellung, Aktualisierung und den interoperablen Austausch von Sicherheitsmitteilungen als strukturierte Informationen über Produkte, Schwachstellen sowie den Status von Auswirkungen und Behebungen“.
Mit anderen Worten: CSAF macht die Offenlegung von Schwachstellen und deren Auswirkungen programmgesteuert zugänglich. CSAF soll jedoch weit mehr sein als nur die Offenlegung und Koordinierung von Schwachstellen. Seit der im November 2022 verabschiedeten Version 2.0 unterstützt CSAF fünf verschiedene Profile:
CSAF Base (Standardwerte)
Security incident response (für Sicherheitsvorfälle wie Datenlecks)
Information Advisory (für Informationen, die keine Schwachstellen betreffen, wie z. B. Fehlkonfigurationen)
Security Advisory (für Informationen zu Schwachstellen)
VEX (Vulnerability Exploitability eXchange – für Informationen zur Ausnutzbarkeit von Schwachstellen)
Ein CSAF-Advisory von RedHat, das eine Schwachstelle in OpenShift meldet
Best Practices
Die Offenlegung von Schwachstellen durch VDR ist eine etablierte Praxis, und auch CSAF hat sich seit 2017 kontinuierlich verbessert (z. B. Red Hat CSAF). VEX und OpenVEX sollen direkte Begleiter von SBOM sein, um das Schwachstellenrauschen zu kontrollieren. Es gibt jedoch keine formelle Spezifikation für VEX (außer den CISA-Beispielen), und OpenVEX befindet sich Ende Juni 2023 immer noch auf Version v0.0.0. Mit anderen Worten: Die Offenlegung des Schwachstellenstatus parallel zur SBOM bleibt ein aktiver Bereich.
Wir bei Interlynk empfehlen die folgenden Prozesse, um Best Practices im Bereich Sicherheit zu demonstrieren und das Schwachstellenrauschen im Unternehmen zu begrenzen:
1. Erstellung von SBOMs pro Release: Viele SBOM-Generierungstools, einschließlich Open-Source-Tools, können SBOMs aus Abhängigkeitsbäumen, CI/CD, Image-Scans oder Software-Composition-Analysen erstellen. Für Produkte, die aus zugrunde liegenden Projekten zusammengesetzt werden, verwenden Sie ein Tool wie sbom-assemble, um die SBOM für das Endprodukt zusammenzustellen und zu verfolgen.
2. SBOMs speichern und verfolgen: Während es möglich ist, einen gewissen Nutzen aus SBOMs durch Tools wie sbom-grep zu ziehen, kann ein formelles System (wie SBOM Link) die Verknüpfung von SBOMs mit bekannten Schwachstellen mühelos machen und die Artefakte für die Zukunft bewahren.
3. Schwachstellenstatus erfassen: Verwenden Sie für jedes Produktrelease ein System, um den Status von Schlüsselschwachstellen zu erfassen, die durch die SBOM-Analyse identifiziert wurden. Die Definition einer Schlüsselschwachstelle variiert je nach Umfang der Anwendung und der Risikotoleranz des Unternehmens. Unternehmen sollten sich jedoch mindestens darauf vorbereiten, Aufzeichnungen für Schwachstellen zu führen, die als Kritisch oder Hoch eingestuft werden. Das Endziel sollte darin bestehen, den Status jeder Schlüsselschwachstelle an einem einzigen und spezifikationsunabhängigen Ort zu erfassen. Dies erleichtert bei Bedarf die Übersetzung in Standards wie CycloneDX VEX, OpenVEX und SPDX3.0 oder CSAF.
4. Produkt mit SBOM UND Schwachstellenstatus/VDR freigeben: Eine Produktfreigabe, die eine SBOM enthält, sollte auch ein Dokument zum Schwachstellenstatus umfassen. Eine SBOM ohne Offenlegung des Schwachstellenstatus wird wahrscheinlich unnötiges Rauschen erzeugen. Wenn das Unternehmen Sicherheitswarnungen über CSAF herausgibt, ist dies ein hervorragender Ort für die Offenlegung des Schwachstellenstatus. Wenn nicht, können die Status in CycloneDX 1.4, SPDX 3.0 (demnächst verfügbar) eingebettet oder zusammen mit der SBOM in OpenVEX bereitgestellt werden.
5. VEX für neu entdeckte Schwachstellen veröffentlichen: Wenn eine neu gemeldete Schwachstelle ein bereits freigegebenes Produkt betrifft, müssen eine oder mehrere neue VEX-Dateien erstellt werden, um die Analyse der Schwachstelle für das Produkt zu dokumentieren. Wir empfehlen, so schnell wie möglich mit „Under Investigation“ (In Untersuchung) zu beginnen und den Status zu aktualisieren, sobald das Ausmaß der Schwachstelle bekannt ist. Beachten Sie, dass wir NICHT empfehlen, den Schwachstellenstatus für alle neu gemeldeten Schwachstellen zu generieren. Stattdessen empfehlen wir, sich auf Schwachstellen zu konzentrieren, die in einer der Komponenten entdeckt werden, die in der zuvor freigegebenen SBOM enthalten sind. Aus diesem Grund ist das Speichern und Verfolgen von SBOMs ein wesentlicher Bestandteil dieser Praxis.
Softwaretransparenz via SBOM hat das Potenzial, den Sicherheitspraktiken während der Entwicklung dringend benötigte Aufmerksamkeit und Ressourcen zu verschaffen. Das Schwachstellenmanagement war jedoch bereits ein ressourcenintensives Problem, bevor SBOM Teil der Debatte wurde. VEX und verwandte Spezifikationen zielen darauf ab, Sicherheitsteams nicht zusätzlich zu belasten und unnötige Warnmeldungen zu eliminieren. Dies ist noch in Arbeit, aber Unternehmen können dennoch robuste Praktiken entwickeln, um Ablenkungen zu minimieren.