Die Geschwindigkeit, mit der neue Schwachstellen aufgedeckt werden, nimmt ständig zu. Derzeit liegt sie bei durchschnittlich 15,000 CVEs pro Jahr. Das Jahr 2022 sticht mit über 26,000 gemeldeten neuen CVEs hervor. Offensichtlich sind nicht alle Schwachstellen für Ihre Software relevant. Um herauszufinden, ob eine bestimmte Schwachstelle ein Problem darstellt, müssen Sie zunächst herausfinden, ob Sie die Bibliothek oder das Produkt verwenden, die die Schwachstelle enthält, und dann herausfinden, ob Sie die problematische Version und das problematische Modul dieser Bibliothek verwenden. Abschließend müssen Sie Ihr Entwicklungsteam konsultieren, um herauszufinden, ob diese Schwachstelle für Ihr bestimmtes Produkt relevant ist und wie Sie diese anfällige Bibliothek oder dieses anfällige Produkt verwendet haben.
Der Prozess, dies alles herauszufinden, ist nicht einfach und kann ziemlich viel Zeit in Anspruch nehmen. Das schätzt Tom Alrich, ein bekannter Cybersicherheitsexperte Etwa 95 % aller in einem bestimmten Softwareprodukt vorhandenen CVEs sind nicht ausnutzbar. Aber wenn Sie ein Endbenutzer oder ein Unternehmen sind, das Software von Drittanbietern in sein System integrieren möchte, wie können Sie dann die problematischen 5 % identifizieren, damit Sie ordnungsgemäße Korrekturen oder Patches anfordern können?
Hier liegt die Idee von Vulnerability Exploitability Exchange (VEX) kommt ins Spiel. Der Zweck von VEX, wie definiert durch und wollen auch Tipps und Tricks, von der US-amerikanischen National Telecommunications and Information Administration (NTIA) im Jahr 2021 besteht darin, „Benutzern (z. B. Betreibern, Entwicklern und Dienstanbietern) zusätzliche Informationen darüber bereitzustellen, ob ein Produkt von einer bestimmten Schwachstelle in einer enthaltenen Komponente betroffen ist und ob dies der Fall ist.“ , ob Abhilfemaßnahmen empfohlen werden.“
Im Moment denken Sie wahrscheinlich: Wie kann ich diese VEX-Dokumente erhalten und mit der Überprüfung meiner Komponenten beginnen? Nun, die Realität der VEX-Nutzung ist wie üblich kompliziert.
Entdecken Sie den Zweck von VEX
Vereinfacht gesagt soll VEX schnell und einfach die Frage beantworten: „Ist meine Version dieser Software dafür ausnutzbar?“ Verletzlichkeit?'.
Die Antwort auf diese Frage soll eine von vier Hauptoptionen sein:
- Nicht betroffen: Für diese Schwachstelle ist keine Behebung erforderlich.
- Betroffen: Es werden Maßnahmen zur Behebung oder Behebung dieser Schwachstelle empfohlen.
- Fixed: Diese Produktversionen enthalten einen Fix für die Schwachstelle.
- Untersucht: Es ist noch nicht bekannt, ob diese Produktversionen von der Schwachstelle betroffen sind. Ein Update wird in einer späteren Version bereitgestellt.
Da VEX sowohl maschinenlesbar als auch maschinengeneriert sein soll, besteht die Idee darin, irgendwo eine durchsuchbare Datenbank dieser Dokumente zu haben, damit jeder Interessierte sie abfragen und die benötigte Antwort erhalten kann.
Da davon ausgegangen wird, dass 95 % der Schwachstellen in einem bestimmten Softwareprodukt nicht ausgenutzt werden können, soll dieses System die umfangreichen Listen der für jedes Produkt gefundenen Schwachstellen auf diejenigen reduzieren, die der Benutzer im Auge behalten oder eine Behebung oder einen Patch anfordern sollte für.
Es gibt eine Reihe interessanter Fakten zur Geschichte von VEX
Im Jahr 2020 hat NTIA (die US-amerikanische National Telecommunications and Information Administration) begann die Idee von VEX als begleitendes Tool zu diskutieren SBOM (Software-Stückliste). Im September 2021 veröffentlichte die NTIA eine einseitige Einführung und Erläuterung, was VEX tun soll.
Später wurden die Bemühungen zur Verfeinerung der Anforderungen des neuen Beratungsformats unter der Schirmherrschaft von CISA – der US-amerikanischen Cybersecurity and Infrastructure Security Agency – durchgeführt, die ihr eigenes Format herausgab Dokument Anfang 2022 wird etwas detaillierter darauf eingegangen und auf einige Anwendungsfälle eingegangen, bei denen das VEX-Dokument helfen sollte. Das Dokument, ein Entwurf, definierte die mindestens erforderlichen Felder des VEX-Dokuments auf die gleiche Weise, wie NTIA die mindestens erforderlichen Felder des SBOM definierte.
Seitdem gab es zwei große Versuche, tatsächlich ein maschinenlesbares VEX-Dokumentationsformat zu erstellen:
- Die Gemeinsames Sicherheitsberatungsrahmenwerk (CSAF) war das erste verfügbare Format. Dieses Format wurde Ende 2022 von OASIS Open veröffentlicht, einer internationalen gemeinnützigen Organisation, die sich der Entwicklung von Open-Source-Standards für Cybersicherheit, Blockchain, IoT und andere Bereiche widmet.
- Cyclone DX, ein von OWASP (Open Web Application Security Project) eingeführtes standardisiertes Format für SBOMs, das angepasst wurde, um auch VEX-Dokumente zu erstellen.
CSAF ist ein umfassendes Format, aber um es tatsächlich erfolgreich nutzen zu können, müssen Sie mehrere Felder und viele Metainformationen einschließen, was eine tatsächliche Einführung unwahrscheinlich macht. Die CyclonDX VEX-Initiative ist viel schlanker, daher würde man sich bei der Überlegung, welcher VEX-Standard am meisten verwendet werden soll, wahrscheinlich dafür entscheiden mit dem CyclonDX-Format.
Warum VEX auf eine Hürde stößt – Aufdecken der Probleme, die seinen Erfolg sabotieren
VEX ist eine gute Idee und könnte die wertvolle Möglichkeit bieten, schnell zu überprüfen, ob eine bestimmte Schwachstelle in einem bestimmten Softwareprodukt tatsächlich ausnutzbar ist.
Es gibt jedoch mehrere Probleme, die die Umsetzung bislang behindern:
- Verantwortung für die Einreichung – wer sollte für die Einreichung der erforderlichen VEX-Dokumente verantwortlich sein? Sind es die Softwarehersteller? Sicherheitsfirmen von Drittanbietern oder gemeinnützige Organisationen? Eine Regierungsbehörde? Was würde passieren, wenn mehrere Quellen widersprüchliche Informationen einreichen würden?
- VEX-Datenbank – wer oder was sollte die VEX-Informationen speichern und kategorisieren? Angenommen, einige der Dokumente würden ausnutzbare Probleme in der Software beschreiben, besteht dann nicht die Gefahr, dass die Informationen in die falschen (böswilligen) Hände geraten?
- Die aktuellen Formate decken die Frage der Versionen und noch weniger das Problem der kombinierten Versionierung nicht ausreichend ab.
Unter kombinierten Software-/Paketversionen versteht man die Praxis, mehrere Softwarepakete oder Komponenten in einer einzigen Version oder einem einzigen Installationspaket zu bündeln.
Wenn es um das Patchen von Schwachstellen geht, können kombinierte Software-/Paketversionen den Prozess sowohl unterstützen als auch behindern. Einerseits kann ein einziges Installationspaket, das alle erforderlichen Komponenten enthält, den Prozess der Identifizierung und Behebung von Schwachstellen vereinfachen. Anstatt jede einzelne Komponente manuell identifizieren und patchen zu müssen, können Sie den Patch einfach auf das gesamte Paket anwenden.
Die Kehrseite davon ist jedoch, dass die gesamte Software angreifbar ist, wenn eine Komponente innerhalb des Pakets angreifbar ist. Dies bedeutet, dass selbst dann, wenn einige der Komponenten innerhalb des Pakets gepatcht wurden, das Gesamtpaket immer noch gefährdet sein kann, wenn eine einzelne ungepatchte Komponente vorhanden ist.
Nehmen wir an, dass Version 1 der Bibliothek A in Ihrer Software eine Sicherheitslücke aufweist. Dieses Problem tritt nur dann auf, wenn Bibliothek A mit Version 2 von Bibliothek B vorhanden ist. Es gibt einen Sicherheitspatch, aber nicht jeder hätte ihn installiert. Das bedeutet, dass das VEX-Dokument für diese Schwachstelle in Ihrer Software alle möglichen Kombinationen des Produkts, seiner Versionen, seiner enthaltenen Bibliotheken, ihrer Versionen und der möglichen veröffentlichten Patches abdecken muss. Das sind viele komplexe Informationen, die sich nicht einfach ausdrücken lassen.
- Wie würde VEX in Hardware eingebettete Software mit allen dort verfügbaren Versionen und Patches abdecken? Wer wäre dafür verantwortlich, diese Software zu patchen, wenn man bedenkt, dass man die Hardware nicht ohne weiteres öffnen und die Dinge selbst patchen kann?
Dies sind nur einige der Probleme, die jedes automatische Tool für den Umgang mit VEX verstehen und berücksichtigen muss.
Wäre es nicht einfacher, wenn Sie Informationen zu jeder Version anfordern und erhalten könnten?
Die Annahme, dass sich diese wichtigen Informationen am besten über ein Dokument weitergeben lassen, ist möglicherweise falsch. Die Erstellung ausreichender VEX-Dokumente, um jede Kombination aus Version, Patch und Schwachstelle abzudecken, ist eine bedeutsame Aufgabe, die verständlicherweise niemand übernehmen möchte.
Schreiber hat eine Plattform zum Verfolgen und Teilen sicherheitsrelevanter Informationen für jeden Build eines bestimmten Softwareprojekts oder Produkts entwickelt. Als Teil davon generiert jeder Build eine genaue SBOM und eine Liste der im Produkt entdeckten Schwachstellen.
Scribe ermöglicht es dem Softwarehersteller, zu jeder dieser Schwachstellen Hinweise im VEX-Format hinzuzufügen, um festzustellen, ob sie nicht ausnutzbar sind, untersucht werden usw. Sobald eine Version veröffentlicht wird, können alle Sicherheitsinformationen zu dieser Version mit interessierten Dritten, den Benutzern, geteilt werden , Regulierungsbehörden usw. Das Einbeziehen der Schwachstellenliste sowie der VEX-Beratungsliste bedeutet, dass der Empfänger nur die Schwachstellen sehen kann, die ein potenzielles Problem in diesem bestimmten Produkt darstellen. Dies entlastet sowohl den Softwarehersteller, der sein Produkt auf die „Whitelist“ setzen kann, als auch den Softwarekonsumenten, der genau weiß, welches Risikoniveau mit einem bestimmten Softwareprodukt verbunden ist.
Da der Softwarehersteller der Einzige ist, der definitiv sagen kann, ob eine bestimmte Schwachstelle tatsächlich für eine bestimmte Version des Produkts relevant ist, ist er der Einzige, der Empfehlungen zu seinen eigenen Produkten hinzufügen und ändern kann. Das diesbezügliche Urteil des Softwareherstellers ist endgültig und nicht anfechtbar. Die Entscheidung darüber, an wen diese Informationen weitergegeben werden, liegt ebenfalls im Ermessen des Softwareherstellers.
Da der vollständige Verlauf der Produkt-Builds, SBOMs und Sicherheitsinformationen von Scribe gespeichert wird, können Benutzer diese Informationen problemlos für jede Version anfordern und abrufen, die sie während des gesamten Software-Lebenszyklus verwenden.
Fazit
Denken Sie daran, dass heutzutage jeder vernünftige Scan eines Softwareprodukts Hunderte, wenn nicht Tausende möglicher Schwachstellen hervorbringen würde. Die meisten Menschen können mit einer solchen Zahl nicht umgehen. Die Alarmmüdigkeit setzt ein und die Anzahl der Schwachstellen wird zu einer Zahl.
Die Möglichkeit, die Zahl der erkannten Probleme auf ein überschaubares Maß zu reduzieren, wäre ein Segen für Softwarehersteller und -anwender. Ziel ist es, sich nur auf die wirklichen Probleme zu konzentrieren, damit der Softwarehersteller sie so schnell wie möglich patchen und beheben kann.
Automatisierte Tools, wie Schreiber bieten eine einfache Möglichkeit, nur die relevanten Schwachstellen für jedes Ihrer Projekte und Builds zu sehen, Informationen, die Sie einfach teilen können, wodurch der Berg an Schwachstellen deutlich kleiner und viel besser überschaubar wird.
Eine wichtige Einschränkung besteht jedoch darin, dass diese Zukunft, in der wir nur die relevanten Schwachstellen leicht erkennen und darauf reagieren können, ohne die aktive Beteiligung der Open-Source-Community nicht möglich wäre. Heutzutage besteht der meiste Code aus erheblichen Mengen an Open-Source-Software. Deshalb brauchen wir die Betreuer und Entwickler solcher Bibliotheken, die sich an der Entdeckung und Behebung der ausnutzbaren Schwachstellen ihres Codes beteiligen.
Das Problem relevanter, ausnutzbarer Schwachstellen wird nicht verschwinden, daher liegt es an uns allen, den effizientesten und kostengünstigsten Weg zu finden, um die Antwort auf die Frage zu erhalten: „Ist meine Version dieser Software dafür ausnutzbar?“ Verletzlichkeit'.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
