Zwei Tage Schwachstellen-Jagd: Was stille Ausfälle über Automatisierung lehren

08.07.2026 · setup

Zwei Tage Schwachstellen-Jagd: Was stille Ausfälle über Automatisierung lehren

Statt neue Features zu bauen, habe ich zwei Tage lang gezielt nach Schwachstellen im eigenen KI- und Automatisierungs-Setup gesucht — gemeinsam mit Claude (Fable 5, dem neuen Frontier-Modell von Anthropic) als Auditor. Der Ansatz: nicht Einzelfehler abarbeiten, sondern nach ganzen Fehlerklassen suchen. Das Ergebnis hat mich in einem Punkt überrascht — die gefährlichsten Probleme haben nie einen Alarm ausgelöst.

Der Befund: Kaputte Automatisierung ist stumm

Die Liste der Funde liest sich wie ein Katalog des Schweigens:

Ein täglicher Automatisierungs-Job war seit über drei Monaten tot. Ursache war eine Shell-Eigenheit: Die Cron-Standardshell löst das Einlesen der Umgebungsdatei über den Suchpfad statt über das Arbeitsverzeichnis auf — der Job brach ab, bevor überhaupt eine Log-Datei entstand. Keine Spur, kein Fehler, nichts.
Eine Synchronisations-Brücke stand nach einem Server-Neustart 43 Stunden still — ein Race beim Hochfahren, das der Dienst kommentarlos schluckte.
Der Alert-Kanal selbst hatte einen Bug: Eine Hilfsfunktion verwarf zwei Parameter, dadurch kam fast die Hälfte aller Meldungen mit falscher Priorität an. Das Werkzeug, das Ausfälle melden soll, war selbst unzuverlässig.
Die Tages-Budgets pro Mandant im LLM-Gateway griffen bei Streaming-Antworten nicht — das Kosten-Tracking sah nur rund 4 % der echten Ausgaben. Die Grenze existierte auf dem Papier, nicht in der Praxis.
Der Dienst, der Firewall-Regeln über Neustarts hinweg persistiert, war inaktiv — nach einem Reboot waren Regeln verschwunden, die längst gesetzt schienen.
Ein Container lief auf einem ungepinnten :latest-Tag und driftete unbemerkt auf eine neue Major-Version, die formal funktionierte, aber nur noch leere Ergebnisse lieferte.

Was sich geändert hat

Vier Maßnahmen, alle übertragbar:

Jeder Job bekommt ein Lebenszeichen. Die Zahl der überwachten Heartbeats stieg von 14 auf 52 — ein ausbleibender Lauf ist jetzt selbst ein Signal, statt auf einen Fehler zu hoffen, der nie geloggt wird.

Drift systematisch prüfen. Ein generischer Abgleich zwischen Versionsverwaltung und Server (statt vier kopierter Einzelchecks) fand im ersten Lauf sieben Abweichungen — Skripte, die auf dem Server längst weiterentwickelt waren als im Repo.

Enforcement testen statt Konfiguration glauben. Ein Red-Team-Testharnisch gegen die eigenen Inhaltsfilter senkte die Erfolgsquote trivialer Umgehungen (Base64 & Co.) von 75 % auf 0. Die Streaming-Kosten wurden mit echten Requests nachgerechnet und stimmen jetzt centgenau mit der Abrechnung überein.

Abhängigkeiten aktuell halten. Eine offene Sicherheitslücken-Kette im Gateway-Unterbau wurde per Versions-Upgrade geschlossen, ein Schwachstellen-Sweep über fünf Anwendungs-Repos räumte vier kritische und sieben hohe Findings auf null.

Zum Mitnehmen

„Kein Fehler im Log" heißt nicht „es läuft". Stille ist der Normalzustand kaputter Automatisierung — wer nur auf Fehler-Alerts baut, sieht genau die schlimmsten Ausfälle nicht.
Jede Grenze (Budget, Filter, Firewall) ist eine Behauptung, bis man ihre Durchsetzung getestet hat.
Ein LLM als Auditor lohnt sich dort, wo es um Fehlerklassen geht: Das Modell hat nicht einen toten Job gefunden, sondern die Frage gestellt, welche Jobs überhaupt beweisen können, dass sie leben.