Asset-Listen werden in der Produktion oft wie das verstaubte Excel-Sheet im Keller behandelt: Sobald sie fertig sind, eigentlich auch schon out-of-date und obsolet. Am Beispiel der neuen, mit 10.0 bewerteten CVE-2026-3587 wird klar, dass wir uns dieses Blindflug-Management nicht mehr leisten können.
Dabei baut gerade WAGO an sich extrem solides Gear und ist nicht umsonst ein absoluter Industriestandard, den ich eigentlich sehr schätze. Dennoch, oder aber gerade deshalb, ist dieser Case ein perfekter Wake-up-Call für uns alle:
Wer heute noch glaubt, eine simple Liste von IP-Adressen reicht aus, hat die Tragweite von NIS-2 und dem Cyber Resilience Act (CRA) nicht verstanden. Ein CLI Escape via undokumentierter, versteckter Funktion (wie bspw. hier beim WAGO 852er Switch) ist das Paradebeispiel dafür, warum es einer echten, idealerweise automatisierten #SBOM (Software Bill of Materials) bedarf.
Eine SBOM ist die längst überfällige Evolution der Asset-Liste. Während die Liste mir nur sagt, dass da ein Switch im Schrank hängt, verrät mir die SBOM, was tief im Inneren dieses Geräts eigentlich läuft; samt Dependencies und gern vergessener Submodule.
Auf Basis meiner bisherigen Kenntnisse scheint mir dabei die vollständige Automatisierung innerhalb der CI/CD-Pipeline kein Luxus zu sein, sondern eine absolute Notwendigkeit, welche ich innerhalb meiner eigenen Auditing-Tools versuche vollständig zu automatisieren, denn
- Ohne SBOM wissen wir erst von einer Schwachstelle, wenn die CVE droppt. Mit einer SBOM könnten wir proaktiv scannen, welche Komponenten (wie das betroffene CLI-Modul) in unserer Infrastruktur lauern, bevor der Exploit die Runde macht >> Transparenz vs. Blackbox
-#CRA und NIS-2 kommen nicht, um uns zu ärgern. Sie zwingen Hersteller endlich dazu, die Supply Chain offenzulegen. Das Ende der "Security by Obscurity" >> Compliance als Enabler
- Wenn die Hütte brennt, haben wir keine Zeit für manuelle Inventur. Wir brauchen maschinenlesbare Daten, um innerhalb von Sekunden zu wissen: "Sind wir betroffen?" >> Incident Response
---
In der IT-Welt "shippen" wir Code am laufenden Band. In der OT-Welt stehen Geräte oft 15 Jahre+.
---
Ohne eine dynamische SBOM, die mit regulatorischen Anforderungen wie dem CRA korreliert, bauen wir uns eine technische Schuld auf, die uns bei der nächsten kritischen Lücke das Genick bricht.
Der WAGO-Case zeigt: Versteckte Funktionen sind technische Schulden, die der Angreifer für uns eintreibt. Patchen (V1.2.1.S1) ist im akuten Fall sicherlich die Pflicht, aber Transparenz via SBOM ist die Kür, um langfristig aus dem reaktiven Feuerlöschen rauszukommen.