CVE: Drei Buchstaben halten Sie und uns seit einiger Zeit und wohl bis in alle Ewigkeit auf Trab. Common Vulnerablities und Exposures ist der Langname, der hinter der Abkürzung steckt und mehrere Aspekte beinhaltet.
Eigentlich ist die CVE eine Organisation, die sich schon seit 25 Jahren mit Cybersicherheit beschäftigt. Sie selbst bezeichnet sich auch als Programm, das mit Partnern auf der ganzen Welt zusammenarbeitet. Finanzielle Unterstützung kommt
- vom U.S. Department of Homeland Security (DHS)
- von der Cybersecurity and Infrastructure Security Agency (CISA) und
- von Mitre, einem US-basierten, internationalem Unternehmen, das u.a. in Ramstein, Stuttgart und Wiesbaden vertreten ist, und sich mit einem Bündel an globalen Herausforderungen von 5G/6G, GPS über Cybersicherheit bis zu Gesundheitsvorsorge und Flugsicherheit beschäftigt.
CVE-Liste
Diese CVE-Organisation führt eine Liste mit CVE-IDs, die bekannt gewordene Sicherheitslücken kennzeichnen. Eine solche ID besteht aus der Jahreszahl und einer zufällig gewählten Nummer, also z.B. CVE-2024-38821. Diese ID wird auf Antrag vergeben, wenn eine Sicherheitslücke gefunden und gemeldet wird. Sobald unter dieser ID eine Mindestmenge an Informationen zusammengetragen wurde, erfolgt die Veröffentlichung des CVE-Eintrags in der CVE-Liste.
Wenn wir von CVEs sprechen, meinen wir also eine gewisse Menge solcher IDs, die aus vielen internationalen Quellen in die Liste der CVE eingespeist werden. Zentrale Player und Namen sind auch noch:
- die OWASP-Foundation, die zwar die Wespe im Logo führt, aber als Open Worldwide Application Security Project viel sinnvollere Dinge tut als Menschen zu stechen. Sie ist weltweit tätig und arbeitet mit Wissensvermittlung, Tools und Zusammenarbeit an ihrer Vision, dass es eines Tages keine unsichere Software mehr gibt. Sie veröffentlicht eine Top Ten Liste der kritischsten Sicherheitslücken für Web-Anwendungen.
- das CVSS, das Commun Vulnerability Scoring System, des FiRST-Teams, dem Forum of Incident Response and Security Teams. Dieses CVSS bewertet die Sicherheitslücken nach ihrem Schweregrad in low, medium, high und critical.
Wir beobachten die CVE-Listen
Dafür nutzen wir das Tool Dependency Track, das uns sehr gut dabei unterstützt, den Überblick über unsere SBOM zu behalten. Hinter dieser Abkürzung steckt die Software Bill of Materials, was man auch als Liste aller verwendeten Software-Bestandteile beschreiben könnte.
Das Dashboard mit etlichen Diagrammen in bunten Farben vermittelt einen ersten Eindruck von der aktuellen Situation:
Weitere Ansichten zeigen im Detail für unsere Anwendungen, welche Version betroffen ist und wie die Schweregrade verteilt sind. Blau ist uns dabei am liebsten, nicht nur, weil es unsere Logo-Farbe ist, sondern vielmehr weil es signalisiert, dass alles im grünen Bereich ist.
Eine weitere Ansicht zeigt die Liste der CVE-IDs und bietet jede Menge Links zu weiterführenden Informationen, an Hand derer eine Einschätzung vorgenommen werden kann, ob das betroffene Element in unseren Anwendungen enthalten ist, ob Handlungsbedarf besteht, welche Aktualisierungsmöglichkeiten vorhanden sind und wie dringend gehandelt werden muss.
Um unsere die Projektleiter auf dem Laufenden zu halten, wurde ein Mailservice eingerichtet, der über gefundene CVEs informiert. Schon im Betreff sieht man, ob man die Mail löschen kann, weil keine von uns verwendeten Komponenten betroffen sind oder es sich um eine falsch-positive Meldung handelt. Trotzdem bleibt noch einiges übrig, was aber zunächst von der Entwicklung bewertet wird. Spätestens im Schätzmeeting des nächsten Sprints erscheinen die CVEs, die dringend beseitigt werden sollen. Meist erhalten sie dann auch gleich den Status „inSprint“, um in den nächsten Tagen beseitigt zu werden.
Wie schnell die Auslieferung erfolgt, legen die Projektleiter nach Rücksprache mit ihren Ansprechpartnern bei den Kunden fest.
Der Spagat zwischen CVEs und Patches
„In Triage“ heißt der Status für CVEs, die bei den Entwicklern zur Prüfung liegen. Auch wenn es hier nicht direkt um Leben und Tod geht, kann die Entscheidung über das weitere Vorgehen doch schwerwiegende Konsequenzen haben.
Was kann im schlimmsten Fall passieren, wenn
- die Sicherheitslücke nicht geschlossen wird?
- ein Upgrade zum Schließen der Sicherheitslücke eingespielt wird, der Seiteneffekte auf andere Funktionalitäten hat?
Einen Verdachtsfall zum zweiten Punkt hatten wir bereits, so dass wir hier sensibilisiert sind und stets die Frage mit berücksichtigt werden muss, welche Funktionalitäten auf die betroffenen Komponenten zugreifen und wieviel Zeit und Ressourcen zum Testen zur Verfügung stehen.
In einem anderen Fall hat eine geschlossene Sicherheitslücke erhebliche Umbauten in einer Anwendung nach sich gezogen. „Mal eben schnell“ war da nicht möglich, zumal zunächst die Ursache für das unerwartete Verhalten der Anwendugn und anschließend eine neue Lösung gefunden werden musste.
Die Wahrheit wird hoffentlich in den meisten Fällen in der Mitte zwischen den beiden worst case-Polen liegen. Wir sind proaktiv am Thema dran, halten unsere Bibliotheken und Komponenten so aktuell wie möglich, damit jeder neue Patch nur geringfügige Änderungen mit sich bringt und die gefunden Sicherheitslücken rasch geschlossen werden können.
