CVE-2025-15467: Nicht die Lücke ist das Problem, sondern dass du nicht weißt, wo OpenSSL überall steckt

Uns beschäftigt eine andere Frage:
Wie lange hat dein Team gebraucht, um herauszufinden, wo überall OpenSSL in eurer Infrastruktur steckt?

Uns interessiert die ehrliche Antwort!

Hand aufs Herz, der typische Ablauf sieht doch so aus:

1. Security-News lesen, erstmal klären: Betrifft uns das überhaupt?
2. Ticket aufmachen: „OpenSSL-Versionen prüfen“
3. Admins loggen sich auf Servern ein und tippen openssl version
4. Jemand erinnert sich, dass in den Docker-Containern eine andere Version läuft
5. Jemand anderes fragt, was eigentlich auf den Firewalls, Load Balancern und Appliances läuft
6. Stunden bis Tage vergehen, bis ein halbwegs vollständiges Bild entsteht

Wir kennen das, aus eigener Erfahrung und aus Kundenprojekten. Und selbst in diesem Ablauf hat noch niemand an die statisch gelinkten Binaries gedacht, die ihre eigene OpenSSL-Version mitbringen.

OpenSSL steckt in zwei Welten: in Software, die wir selbst bauen und deployen, und in Appliances, deren Innenleben der Hersteller kontrolliert. Für beide braucht es einen Ansatz — und für beide gibt es einen. Dieser Artikel zeigt, wie ihr beim nächsten Mal in Minuten statt Tagen reagiert.

SBOM: Die Zutatenliste für Software

Eine Software Bill of Materials (SBOM) ist im Kern simpel: eine maschinenlesbare Liste aller Komponenten, die in einem Softwareprodukt stecken. Name, Version, Herkunft. Für jedes Paket, jede Library, jede Abhängigkeit.

Wer eine aktuelle SBOM seiner Systeme hat, beantwortet die Frage „Wo steckt OpenSSL 3.x?“ mit einem Query statt mit SSH-Sessions auf 30 Servern. Spätestens mit NIS2 und dem Cyber Resilience Act ist das auch regulatorisch keine Kür mehr.

Wie das in der Praxis aussieht Wir nutzen dafür OWASP Dependency-Track, eine Open-Source-Plattform, die SBOMs entgegennimmt, gegen Schwachstellendatenbanken abgleicht und betroffene Komponenten über das gesamte Portfolio sichtbar macht.

Für eigene Software und Container werden die SBOMs mit Tools wie Syft oder Trivy in der CI/CD-Pipeline erzeugt und per API in Dependency-Track importiert. Sobald eine neue CVE veröffentlicht wird, matcht die Plattform automatisch gegen alle hinterlegten Komponenten.

Statt „Wo läuft OpenSSL?“ heißt die Frage dann: „Welche meiner 120 Projekte nutzen OpenSSL 3.0 bis 3.6?“ Die Antwort liegt vor, bevor der erste Admin sich irgendwo einloggt.

Und auf der Netzwerk-Seite?
Damit ist die Software-Seite abgedeckt. Aber wer wie wir vor allem Firewalls, Switches und Appliances betreut, weiß: Das ist nur die eine Hälfte. Bei Netzwerk-Appliances sieht die Realität anders aus, und zwar gleich doppelt.

Das akute Problem ist nicht die CVE, sondern der Überblick. Wenn Check Point ein Advisory veröffentlicht, das Gaia R81.20 vor Jumbo Hotfix Take 78 als betroffen listet, stellt sich eine simple Frage: Welche unserer 47 Security Gateways laufen noch auf welchem Take? Bei Cisco, Fortinet oder Palo Alto ist es dasselbe. Die Hersteller liefern die Zuordnung CVE-zu-Version zuverlässig und schnell. Was in den meisten Unternehmen fehlt, ist eine saubere Datenbasis, die Firmware-Versionen pro Gerät erfasst und abfragbar macht.

Das ist kein SBOM-Problem. Das ist Device Lifecycle Management. Wer Firmware-Stände nur in Excel-Listen oder im Kopf einzelner Kollegen pflegt, sucht bei jeder kritischen CVE wieder manuell. Dedizierte NCM-Lösungen wie ManageEngine oder SolarWinds bringen genau dafür Firmware-Vulnerability-Matching mit, inklusive automatischem Abgleich gegen NIST-Datenbanken. Wer bereits eine Network Source of Truth wie NetBox betreibt, hat die Datenbasis schon: Mit gezielter Automatisierung lassen sich die Firmware-Versionen aller Geräte regelmäßig abfragen und zentral erfassen. Die Frage „Welche FortiGates laufen auf 7.4.2?“ wird dann zu einem API-Call statt zu einer Suchexpedition.

Das strukturelle Problem dahinter: Für proprietäre Firmware liefert kein Syft und kein Trivy eine SBOM. Welche OpenSSL-Version in FortiOS 7.4.3 steckt, weiß nur Fortinet. Der Cyber Resilience Act wird das ändern: Ab 2027 müssen Hersteller maschinenlesbare SBOMs für den europäischen Markt liefern. Cisco bietet das für On-Premise-Software seit 2023 bereits an. Bei anderen Herstellern lohnt es sich, gezielt nachzufragen, jede Kundenanfrage beschleunigt den Prozess für alle.

Was jetzt zu tun ist
CVE-2025-15467 patchen, sofort. Und dann dafür sorgen, dass ihr beim nächsten Mal nicht wieder manuell suchen müsst. Denn die nächste kritische CVE kommt bestimmt — und mit KI-gestützter Vulnerability Discovery wie bei dieser hier werden die Abstände kürzer.