Kontinuierliches Exposure Management für den Mittelstand

Kleine und mittlere Unternehmen betreiben heute dieselbe Art von Infrastruktur wie Konzerne: Cloud-Server, Container, Software mit Hunderten Abhängigkeiten, Geräte im Feld. Sie haben aber selten ein Sicherheitsteam. Die Aufgabe, neue Schwachstellen gegen den eigenen Bestand zu prüfen, landet bei der IT oder bei einem Dienstleister, der viele Kunden parallel betreut.

Das gängige Instrument ist der periodische Penetrationstest. Er liefert eine Momentaufnahme. Zwischen zwei Tests vergehen oft zwölf Monate. In dieser Zeit erscheinen neue Schwachstellen, der Bestand ändert sich, und niemand gleicht beides ab. In den drei Beobachtungstagen dieses Berichts lieferten allein zwölf öffentliche Feeds 2.204 Meldungen. Ein Schwachstellenscanner verkürzt den Abstand, erzeugt aber ein zweites Problem: lange Listen. Jeder Treffer muss von Hand geprüft werden. Nutzen wir das Paket? Ist der Dienst erreichbar? Gibt es eine Korrektur? Diese Prüfung kostet Zeit, und deshalb bleibt sie liegen.

Drei Dinge fehlen: ein Bestand, der aktuell bleibt; eine Triage, die jeden Treffer gegen diesen Bestand bewertet; und ein Weg, der von der Bewertung bis zur verifizierten Behebung führt. Unsere Hypothese: Ein kleiner, kontinuierlich laufender Node pro Kunde kann diese drei Dinge leisten, wenn eine KI-Triage den Abgleich übernimmt und Menschen nur noch die Behebung freigeben.

Das System heißt intern vulnwatch. Es ist in Python geschrieben, läuft als systemd-Dienst auf einem Linux-Server und hält seinen Zustand in einer SQLite-Datenbank. Ein Timer startet alle fünf Minuten einen Lauf. Jeder Lauf durchläuft die Stufen Ingest, Abgleich, Triage, Meldung. Schwere Quellen laufen seltener: Repository-Inventar stündlich, Host-Reports alle drei Stunden, Außenscan, Secret-Scan und CI-Audit täglich.

Ingest: welche Daten das System liest

• CISA KEV (Known Exploited Vulnerabilities, JSON-Katalog): Treffer per Hersteller- und Produktabgleich; jeder Treffer gilt als kritisch.
• OSV (querybatch und Detailabfrage): Advisories zu jedem Paket aus den Lockfiles des Kunden. Zehn Lockfile-Formate werden gelesen (npm, bun, pnpm, yarn, requirements, poetry, uv, Cargo, go.sum).
• Aikido-Malware-Listen für npm und PyPI: eine bösartige Version im Bestand gilt als kritisch.
• Zwölf RSS-Feeds, darunter CERT-Bund WID, oss-security, Node.js Security, Hersteller-Research und Fachpresse. Stichwortabgleich gegen 84 Stack-Begriffe.
• Host-Agent auf jedem Kundenserver: Trivy-Scan des Dateisystems und der laufenden Container, dazu die Liste offener Ports (ss -ltnup). Der Node holt die Reports per SSH ab; der Agent öffnet keinen Rückkanal.
• Außensicht: nmap über die 1.000 häufigsten TCP-Ports (IPv4 und IPv6), Shodan InternetDB, Certificate-Transparency-Logs (crt.sh), TLS-Gültigkeit und Ablauf.
• Secrets und CI: gitleaks über Bare-Mirrors aller aktiven Repositories, zizmor über GitHub-Actions-Workflows.

Der erste Lauf jeder Quelle ist eine Baseline. Sie erzeugt keine Warnung, sondern einen Backlog, den ein KI-Modell zu einer Liste der zwanzig wichtigsten Maßnahmen verdichtet. Erst Änderungen gegenüber der Baseline lösen Meldungen aus.

Triage: Abgleich gegen den Bestand

Jeder neue Treffer geht in Paketen von höchstens 25 Stück an eine Triage-Instanz. Das ist ein Claude-Modell im Headless-Betrieb mit eingeschränkten Rechten: nur lesender Zugriff, kein Zugriff auf Konfiguration oder Schlüssel, GitHub nur über einen GET-only-Wrapper. Als Kontext erhält es eine gepflegte Beschreibung des Bestands (Server, Dienste, Netzgrenzen, Abhängigkeiten) und die Inventar-Tabellen. Feed-Texte sind als nicht vertrauenswürdig deklariert; Anweisungen darin werden ignoriert. Pro Treffer entsteht ein strukturiertes Urteil: applies (ja, nein, unklar), Schwere, Begründung in höchstens drei Sätzen, empfohlene Maßnahme. Fällt die Triage aus, eskalieren kritische Treffer aus KEV, OSV, Malware-Listen, Secret- und Host-Scan trotzdem.

Routing, Meldung, Behebung

Eine Registry ordnet Repositories, Hosts, Adressen und Domains je einem Projekt zu. Treffer werden zur Abfragezeit über ihre Assets geroutet; jedes Projekt hat eine eigene Warteschlange. Die Warteschlange enthält nur geprüfte, strukturierte Felder. Freitext aus Advisories gelangt nie ungefragt in den Arbeitsauftrag eines Agenten. Meldungen gehen ab Schwere „high“ per E-Mail, Push nur bei „critical“, dazu ein Tagesbericht um 07:30 und ein Wochenbericht. Ein Dispatcher auf einer Arbeitsstation öffnet pro Projekt eine Sitzung, in der ein Agent den Befund auf dem Kundensystem nachstellt, einen Pull Request mit Tests vorbereitet und das Ergebnis in einem Remediation-Protokoll festhält. Änderungen an Produktivsystemen setzen die Freigabe des Kunden voraus. Ein Fund schließt sich, wenn der Scanner ihn nicht mehr meldet, oder ein Mensch verwirft ihn mit Begründung.

Die Leistungsstufen Monitor (überwachen und melden), Respond (getestete Korrektur liefern) und Managed (vereinbarte Korrekturen einspielen) unterscheiden sich nur darin, wie weit dieser letzte Schritt reicht.

Der Node läuft seit dem 22. Oktober 2026, 08:43 UTC. Dieser Bericht wertet den Stand vom 25. Oktober 2026, 11:37 UTC aus: ein Fenster von drei Tagen und drei Stunden, also noch keine volle Woche. In dieser Zeit startete der Timer 591 Läufe ohne einen Ausfall der Dienst-Einheit. Die erste Produktivumgebung ist Client A, eine SaaS-Plattform für Fitnessstudios mit Kiosk-Geräten in den Studios. Der Betreiber hat die Überwachung und die aktive Prüfung schriftlich beauftragt; das System betreibt die von Hören Potential Ventures UG. Derselbe Node überwacht auch unsere eigene Infrastruktur und ein zweites Kundenprojekt.

Drei Beobachtungen. Erstens: Die Baseline dominiert. 785 der 941 Treffer stammen aus dem ersten Scan und sind alte, bekannte Pakete ohne Korrektur im Distributions-Repository. Das System meldet sie nicht, sondern verdichtet sie zu einem Backlog. Zweitens: Die Triage entfernt den größten Teil des Rauschens. Von 44 geprüften Treffern stufte sie 34 als nicht zutreffend ein, zum Beispiel weil der verwundbare Codepfad nicht erreichbar ist oder das Paket nur in einer Entwicklungsumgebung liegt. Drittens: Der Secret-Scan ist der lauteste Scanner. Über alle Projekte prüften wir 280 Funde aus fünf privaten Repositories gegen die laufenden Systeme: null lebende Zugangsdaten, acht tote, zehn Testwerte, 262 Fehlalarme.

Über alle drei Projekte verarbeitete der Node 3.010 Treffer, triagierte 193, schloss 307 automatisch (Median 4,8 h, n = 307) und versendete 13 Warnungen sowie zwei Tagesberichte.

Befundklasse. Ein Datenbankdienst war an alle Netzwerkschnittstellen gebunden. Die Cloud-Firewall ließ den Port von außen für genau eine Adresse zu, den Betriebsserver des Dienstleisters. Zugleich erlaubte die Richtlinie des Overlay-Netzes jedem Gerät im Netz den Zugriff, darunter den Kiosk-Rechnern in den Studios. Die Datenbank hing damit an zwei Regeln, die niemand prüfte. Eine Änderung an einer davon, oder ein kompromittiertes Gerät, hätte den direkten Zugang geöffnet.

Die Korrektur stand rund 30 Stunden nach der ersten Aufzeichnung. Zwei Lehren: Eine Baseline ohne Alarm ist richtig, damit der erste Tag nicht in Hunderten Meldungen untergeht; sie braucht aber eine zügige menschliche Durchsicht. Und der Scanner, der den Befund fand, ist auch der beste Zeuge für die Behebung.

Was dieser Bericht nicht zeigt

• Kurzes Fenster. Drei Tage sind eine Stichprobe, keine Statistik. Die Baseline prägt alle Zahlen. Eine zweite Auswertung nach 30 Tagen ist geplant.
• Ein Node, drei Projekte. Die Zielarchitektur sieht einen Node pro Kunde und einen zentralen Hub vor, der nur signierte öffentliche Meldungen verteilt. Heute liest ein Node, den wir betreiben, die Quellen direkt und überwacht unsere Infrastruktur und zwei Kundenprojekte gemeinsam. Der signierte Hub-Feed ist entworfen, nicht gebaut.
• Stille Baseline. Das Fallbeispiel zeigt die Kehrseite: Ein Befund aus dem ersten Scan erzeugt keine Warnung. Die Durchsicht der Baseline ist heute ein manueller Schritt.
• Fehlende Zeitstempel. Die Datenbank hält fest, wann ein Treffer entsteht und wann er schließt, aber nicht, wann die Triage ihn bewertet hat. Zeit bis Triage und Kosten pro Triage sind deshalb nicht messbar.
• Bestandsbeschreibung von Hand. Der Kontext der Triage ist ein gepflegter Text plus Inventar-Tabellen, kein strukturierter Asset-Graph. Veraltet der Text, sinkt die Qualität der Urteile.
• Blinde Flecken. Kein EPSS im Produktiv-Node (nur im Prototyp). Keine Inventarisierung der Arbeitsstationen und der Windows-Kiosks. Treffer aus Nachrichten-Feeds ohne Asset-Bezug laufen nur in das Standardprojekt. Der Host-Scanner sieht die Laufzeitumgebung einer Anwendung nicht, wenn sie als einzelne Binärdatei installiert ist.
• KI-Urteile sind fehlbar. Die Triage kann einen Treffer falsch einstufen. Der Fail-safe eskaliert kritische Funde auch ohne Urteil; eine systematische Messung der Urteilsqualität gegen eine menschliche Zweitmeinung steht aus.
• Behebung braucht Freigabe. Mehrere vorbereitete Korrekturen warten auf die Freigabe des Betreibers für die Produktivumgebung. Die Zeit zwischen „Korrektur bereit“ und „eingespielt“ liegt beim Kunden und erscheint in keiner Kennzahl.

Nächste Schritte

1. Triage-Zeitstempel und Token-Kosten pro Lauf in der Datenbank erfassen.
2. Einen dedizierten Node für Client A ausrollen; Hub-Feed mit Signatur bauen.
3. Baseline-Durchsicht automatisieren: der Backlog-Lauf eskaliert Funde zur Netzexposition sofort.
4. EPSS in die Priorisierung des Produktiv-Nodes übernehmen.
5. Urteilsqualität messen: eine Stichprobe von Triage-Urteilen gegen manuelle Prüfung, mit Fehlerquote je Klasse.
6. Bericht v1.1 nach 30 Tagen Betrieb mit denselben Kennzahlen.