OPAIRS SBOM-Scanner: Laufende Schwachstellen- und Lieferketten-Überwachung für den Cyber Resilience Act

Jede Software in der Fertigung besteht zum größten Teil aus Bausteinen, die nicht im eigenen Haus geschrieben wurden: Bibliotheken, Basis-Images, Laufzeitumgebungen. Ein typischer Docker-Container bringt Hunderte solcher Pakete mit. Wird in einem davon eine Lücke bekannt, lautet die erste Frage: Sind wir betroffen, und wo? Ohne Stückliste beginnt an dieser Stelle die Suche von Hand – genau dann, wenn die Zeit am knappsten ist.

Mit dem EU Cyber Resilience Act wird aus dieser guten Praxis eine Pflicht. OPAIRS hat deshalb einen eigenen SBOM-Scanner entwickelt, der auf unseren Servern produktiv läuft und als Open Source frei verfügbar ist. Er erzeugt für jeden laufenden Container eine Software-Stückliste, verfolgt Schwachstellen über die Zeit und meldet sich per Mail, wenn eine Lücke aktiv ausgenutzt wird oder ein Paket als bösartig gemeldet wurde. Er läuft vollständig lokal beim Betreiber, ohne Cloud-Konto und ohne externen Dienstleister.

Was der Cyber Resilience Act jetzt verlangt

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist seit Dezember 2024 in Kraft und gilt gestaffelt. Er betrifft Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden – also auch Maschinen- und Anlagenbauer, deren Steuerungen, Bedienoberflächen oder Software-Module mit einem Netzwerk verbunden sind. Den Verordnungstext gibt es auf EUR-Lex: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847

• Seit 11. September 2026 gelten die Meldepflichten nach Artikel 14: Aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle sind zu melden – mit Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur. Das gilt auch für Produkte, die bereits auf dem Markt sind.
• Gemeldet wird über die Single Reporting Platform der ENISA, die am selben Tag in Betrieb ging: https://www.enisa.europa.eu/cra-srp/
• Ab 11. Dezember 2027 gelten alle wesentlichen Anforderungen. Dazu gehört nach Anhang I, Teil II, dass Hersteller die Komponenten ihrer Produkte identifizieren und dokumentieren, unter anderem mit einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, und Schwachstellen über den gesamten Unterstützungszeitraum behandeln.
• Am 27. Juli 2026 hat die EU-Kommission Leitlinien zur Anwendung veröffentlicht, mit 67 Praxisbeispielen und besonderem Blick auf kleine und mittlere Unternehmen: https://digital-strategy.ec.europa.eu/de/news/commission-publishes-new-guidance-support-businesses-implementation-cyber-resilience-act

Für die Praxis heißt das: Die 24-Stunden-Frist beginnt, sobald der Hersteller von einer aktiv ausgenutzten Lücke weiß. Wer erst dann herausfinden muss, welche Produkte und Versionen die betroffene Bibliothek enthalten, verliert genau die Stunden, die für die Meldung gebraucht werden. Eine aktuelle Stückliste und eine laufende Überwachung sind deshalb die Voraussetzung, um die Pflichten überhaupt erfüllen zu können. Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung; ob und wie ein Produkt unter den CRA fällt, ist im Einzelfall zu prüfen.

Ein Dienst, der laufend mitschaut

Der Scanner läuft als einzelner Container neben den übrigen Diensten und arbeitet in kleinen Schritten statt in einem großen nächtlichen Lauf. Er baut auf zwei etablierten Open-Source-Werkzeugen von Anchore auf, Syft für die Stückliste und Grype für den Abgleich mit Schwachstellen-Datenbanken, und ergänzt sie um alles, was für den Dauerbetrieb nötig ist:

• Stücklisten im Format CycloneDX für alle laufenden Docker-Container, Kubernetes-Pods und frei wählbare Verzeichnisse. Solange sich ein Image nicht ändert, wird die gespeicherte Stückliste wiederverwendet.
• Verfolgung über die Zeit: Jeder Fund hat ein Datum für „zuerst gesehen“, „zuletzt gesehen“ und „behoben“. Sichtbar wird, was neu ist, was erledigt wurde und was offen bleibt.
• Bewertung mit CVSS, der Ausnutzungswahrscheinlichkeit EPSS von FIRST und der Angabe, ab welcher Version die Lücke behoben ist.
• Ein Tagesbericht per Mail mit Zahlen, Veränderungen, den größten offenen Risiken und dem Betriebszustand des Scanners selbst.
• Eine REST-Schnittstelle, über die sich Funde in eigene Werkzeuge, Dashboards oder Automationen übernehmen lassen.

Ein fehlgeschlagener Scan gilt als Fehler und nicht als „keine Funde“. Er wird mit wachsender Wartezeit wiederholt und im Tagesbericht ausgewiesen. Syft und Grype laufen mit niedriger CPU-Priorität, und der Plattenverbrauch ist begrenzt: Berichte haben eine Aufbewahrungsfrist, Stücklisten werden komprimiert archiviert, Arbeitsdateien nach jedem Lauf gelöscht.

Alarm nur, wenn es zählt

Ein Scanner, der täglich hundert Mails schickt, wird nach einer Woche ignoriert. Die Alarmierung ist deshalb regelbasiert und bewusst sparsam. Höchste Priorität haben zwei Fälle: Eine gefundene Lücke steht im Katalog der aktiv ausgenutzten Schwachstellen der US-Behörde CISA (Known Exploited Vulnerabilities, https://www.cisa.gov/known-exploited-vulnerabilities-catalog), oder ein eingesetztes Paket wurde als bösartig gemeldet. Das sind genau die Situationen, in denen die Meldefristen des CRA relevant werden können. Daneben gibt es Warnungen für kritische Funde und für hohe Funde mit einer Ausnutzungswahrscheinlichkeit von mindestens 50 Prozent.

Jeder Fund wird nur einmal gemeldet, erneut nur bei Verschärfung – etwa wenn eine bekannte Lücke nachträglich in den KEV-Katalog aufgenommen wird – oder wenn er nach einer Behebung wieder auftaucht. Der erste Scan eines Systems gilt als Ausgangsstand: Altlasten landen im Tagesbericht statt im Posteingang, aktiv ausgenutzte Lücken und Malware alarmieren trotzdem sofort. Dieselbe Lücke in mehreren Images steht in einer Zeile, und jede Mail nennt Image, Paket, Version, Zielversion und eine konkrete Maßnahme.

Lieferketten-Angriffe: wenn ein Paket absichtlich schädlich ist

Ein klassischer Schwachstellen-Scanner findet bekannte Fehler. Ein Paket, das absichtlich mit Schadcode veröffentlicht wurde, findet er nicht. Wie real das Risiko ist, hat 2026 der Angriff auf das Python-Paket LiteLLM gezeigt: Im März wurden zwei manipulierte Versionen auf PyPI veröffentlicht, nachdem Angreifer über eine kompromittierte CI-Pipeline an die Zugangsdaten des Maintainers gelangt waren – ausgerechnet über einen Sicherheitsscanner, der dort eingebunden war. Der Ablauf ist im Projekt dokumentiert: https://github.com/BerriAI/litellm/issues/24518

Der OPAIRS-Scanner gleicht deshalb alle sechs Stunden sämtliche Pakete aus den gespeicherten Stücklisten mit den Malware-Meldungen der Datenbank OSV ab (https://osv.dev), die aus dem Projekt OpenSSF Malicious Packages gespeist werden. Das läuft unabhängig vom eigentlichen Scan: Wird ein Paket erst Wochen nach dem Bau eines Images als schädlich gemeldet, schlägt der Scanner trotzdem an. Die Grenzen sind klar: Abgedeckt sind nur die Ökosysteme, die OSV kennt (npm, PyPI, Cargo, RubyGems, Go, Maven, NuGet), nur Pakete, die in der Stückliste auftauchen, und nur, was bereits gemeldet wurde. Es ist eine Alarmanlage, kein Unbedenklichkeitsnachweis.

Ein kleines Sprachmodell, das nur formuliert

Optional schreibt ein kleines Sprachmodell zu jedem Alarm einen kurzen Hinweis, was der Fund bedeutet und was zu tun ist, und fasst den Tagesbericht zusammen. Es läuft über llama.cpp auf der CPU, belegt keine Grafikkarte und kommt mit rund zwei Gigabyte Arbeitsspeicher aus; bei uns ist es IBM Granite 4.0 Micro in einer 4-Bit-Quantisierung, im Repository ist Qwen2.5-1.5B voreingestellt. Das Modell entscheidet nichts: Schweregrad, Priorität und Alarmierung sind fest geregelt, die Texte sind als KI-Einschätzung ohne Gewähr gekennzeichnet. Weil CVE-Beschreibungen von Dritten stammen, werden sie als nicht vertrauenswürdig behandelt, bereinigt, gekürzt und ausdrücklich als Daten und nicht als Anweisungen übergeben. Ist das Modell langsam oder abgeschaltet, gehen die Mails ohne Hinweis hinaus.

Erfahrungen aus dem eigenen Betrieb

Seit dem 25. Oktober 2026 überwacht der Scanner unseren Plattform-Server mit rund 50 Images, darunter Sprachmodell-Server, Datenbanken und eigene Dienste. Der erste Alarm wegen einer aktiv ausgenutzten Lücke betraf den Scanner selbst: Eine veraltete Version des Web-Frameworks Starlette stand seit Anfang September im KEV-Katalog. Sie wurde noch am selben Tag aktualisiert – ein gutes Beispiel dafür, warum sich ein Werkzeug selbst mitprüfen sollte.

Lehrreich war auch, wo die Werkzeuge an Grenzen stoßen. Bei Images mit eingebetteten Modelldateien, etwa vLLM und Open WebUI, wuchs der Abgleich mit Grype auf rund 25 Gigabyte Arbeitsspeicher an, bis der Prozess beendet wurde. Ursache ist ein offener Fehler in Grype beim Einlesen von Modell-Komponenten ohne Paketkennung (https://github.com/anchore/grype/issues/3767). Der Scanner entfernt diese Komponenten deshalb aus einer Kopie der Stückliste, bevor Grype sie liest; sie können ohnehin keine Paket-Schwachstelle treffen, und das archivierte Original bleibt vollständig. Danach lief der Scan eines vLLM-Images in 18 Sekunden durch, und 49 von 50 Zielen waren erfasst. Beim letzten, einem besonders großen Spracherkennungs-Image, zeigt schon die Stücklisten-Erzeugung dasselbe Muster; dort ist eine weitere Gegenmaßnahme im Test, die Modelldateien gar nicht erst einliest. Weitere Lehren: Die Alarmierung bündelt aktiv ausgenutzte Lücken jetzt im Abstand von zehn Minuten, und gleiche Lücken in mehreren Images erscheinen nur noch einmal im Bericht.

Was der Scanner nicht leistet

Der Scanner ist kein Nachweis für Sicherheit und keine CRA-Konformität auf Knopfdruck. Er findet bekannte Lücken und gemeldete bösartige Pakete, keine unbekannten Fehler im eigenen Code. Das Betriebssystem des Servers und Software, die erst zur Laufzeit nachgeladen wird, prüft er nicht. Er stellt keine Meldung an die ENISA-Plattform ab; die Bewertung, ob eine Lücke im eigenen Produkt tatsächlich ausnutzbar ist und gemeldet werden muss, bleibt eine menschliche Entscheidung. Risikoanalyse, Unterstützungszeitraum, Update-Prozess und technische Dokumentation verlangt der CRA zusätzlich. Was der Scanner liefert, ist die Datengrundlage dafür: eine aktuelle Stückliste, eine nachvollziehbare Historie jedes Fundes und ein Alarm in dem Moment, in dem die Uhr zu laufen beginnt.

Unabhängig von externen Dienstleistern

SBOM- und Schwachstellen-Management wird heute meist als Cloud-Plattform angeboten. Dafür muss die vollständige Liste der eingesetzten Software das Haus verlassen – also genau die Information, die ein Angreifer für die Vorbereitung eines Angriffs am liebsten hätte. Der OPAIRS-Scanner läuft dagegen beim Betreiber: auf einem vorhandenen Linux-Server, mit Docker Compose in wenigen Minuten gestartet, ohne Konto, Lizenzschlüssel oder Abonnement. Ausgehende Verbindungen gibt es nur zu den öffentlichen Datenquellen (Schwachstellen-Datenbank, KEV-Katalog, OSV), und mit dem Offline-Modus lassen sich auch diese abschalten, etwa für Anlagen ohne Internetzugang. Die Mails gehen über den eigenen Mailserver. Damit können auch kleinere Hersteller und Maschinenbauer eine laufende Überwachung aufbauen, ohne sich an einen Anbieter zu binden – und Integratoren können ihren Kunden etwas anbieten, das vor Ort läuft und dort bleibt.

Danksagung

Die eigentliche Analyse leisten die Werkzeuge und Daten anderer: Syft und Grype von Anchore, der KEV-Katalog der CISA, OSV und das Projekt OpenSSF Malicious Packages, die EPSS-Werte von FIRST, llama.cpp sowie IBM Granite als lokales Modell. Der OPAIRS-Scanner entwickelt keines davon; er verbindet sie zu einem Dienst, der dauerhaft und mit begrenztem Aufwand im eigenen Haus läuft. Die Lizenzen und Nutzungsbedingungen der Datenquellen und Modellgewichte sollten vor einem Einsatz geprüft werden.

Teil der OPAIRS-Plattform

Auf der OPAIRS-Plattform ist der Scanner ein weiterer lokaler Fachdienst neben Sprachmodellen, SQL-Agent und Prognose-Dienst. Über seine Schnittstelle lassen sich Funde in Automationen übernehmen oder von einem Agenten im Chat abfragen, etwa mit der Frage, welche Images von einer bestimmten Lücke betroffen sind. Er ergänzt damit die Governance-Bausteine, die wir für den EU AI Act beschrieben haben: https://opairs-systems.com/insights/eu-ai-act-industrie-orientierung

Open Source auf GitHub

Der Scanner ist Open Source und steht unter der MIT-Lizenz auf GitHub: https://github.com/OPAIRS/sbom-scanner. Dort liegen Code, Tests, Docker-Compose-Beispiel, eine vollständige Beschreibung aller Einstellungen und Schnittstellen sowie die Beitragsregeln. Jede Änderung läuft durch automatische Tests und einen Docker-Build mit Start- und Health-Check. Wer den Scanner prüfen, im eigenen Betrieb einsetzen oder weiterentwickeln möchte, kann das ohne Abhängigkeit von OPAIRS tun.

Mitmachen: Tests, Rückmeldungen, Beiträge

Der Scanner soll Herstellern, Maschinenbauern und Betreibern helfen, die Pflichten aus dem Cyber Resilience Act mit eigenen Mitteln anzugehen. Damit er das gut kann, brauchen wir Rückmeldungen aus anderen Umgebungen: andere Image-Landschaften, Kubernetes-Cluster, Anlagen ohne Internetzugang, Anforderungen aus Audits. Besonders wertvoll sind Fälle, in denen der Scanner etwas übersieht, zu viel meldet oder an Grenzen stößt. Issues und Pull Requests sind im Repository willkommen.

Für gemeinsame Pilotprojekte, Einbindung in bestehende Prozesse oder Fragen zum Einsatz: office@opairs-systems.com