Falco für MSPs: Runtime-Erkennung von CI-Pipelines bis Kubernetes-Flotten

Verwaltete Kubernetes-Flotten und die CI-Pipelines, die Code in sie ausliefern, sind zwei unterschiedliche Angriffsflächen, und MSPs brauchen zunehmend für beide ein eigenes Werkzeug. Dieser Leitfaden behandelt Falco, eine von der CNCF graduierte Runtime-Engine, die verdächtiges Container-Verhalten in eine abgestimmte Alert-Pipeline verwandelt, sowie zizmor, einen statischen Analysator, der riskante GitHub-Actions-Konfigurationen erkennt, bevor ein Workflow überhaupt läuft.

Was Falco ist und was es erkennt

Falco wurde von Sysdig entwickelt und ist heute ein graduiertes Projekt der Cloud Native Computing Foundation. Es beobachtet Systemaufrufe über eBPF-basiertes Monitoring und meldet Prozess-, Datei- und Netzwerkaktivität, die innerhalb eines laufenden Containers verdächtig wirkt. Dadurch lässt sich ein laufender Angriff erkennen, statt ihn erst bei einer nachträglichen Analyse zu entdecken.

Worauf zuerst reagiert werden sollte

Nicht jedes Signal, das Falco erzeugen kann, rechtfertigt einen Bereitschaftsalarm. Für MSPs mit vielen Tenants zählen vor allem Regeln, die eine niedrige Falsch-positiv-Rate mit hohen Kosten im Übersehensfall verbinden: eine interaktive Shell in einem Anwendungscontainer, der eigentlich nie eine braucht, ein Prozess, der von einem sensiblen Mount-Pfad wie dem Host-Dateisystem liest, sowie Rechte- oder Linux-Capability-Änderungen in einem laufenden Pod. Diese drei decken die meisten Fälle ab, in denen gerade wirklich etwas Kritisches passiert.

Alerts so weiterleiten, dass sie bearbeitet werden

Ein Erkennungswerkzeug hilft nur, wenn der Alert jemanden erreicht, der handeln kann. Falco-Events sollten genug Kontext mitbringen — Cluster, Namespace, Tenant und Pod-Identität —, um direkt in das Bereitschafts- oder ITSM-Tool des MSP zu laufen, samt dokumentiertem Eindämmungsschritt, bevor ein Alert geschlossen wird. Regeln je nach Kunden-Baseline anzupassen verhindert Alert-Müdigkeit: Eine Shell, die in einem CI-Runner-Namespace normal ist, ist es in einem kundenseitigen Web-Pod nicht.

Wo Falco aufhört

Falco ist eine Erkennungsschicht, kein Reaktionssystem. Es isoliert keine Workload, macht kein Deployment rückgängig und rotiert keine Zugangsdaten von selbst; diese Schritte brauchen weiterhin ein Playbook und einen menschlichen oder automatisierten Responder hinter dem Alert. Es sollte als Sensor verstanden werden, nicht als das gesamte Sicherheitsprogramm.

Für Teams, die externe Unterstützung beim Aufbau dieses Playbooks brauchen oder einen geprüften Erkennungs- und Reaktionsprozess für NIS2-, DORA- oder GDPR-Audits nachweisen müssen, bieten sich die Cybersecurity-Services von Altovar an, die Penetrationstests, Schwachstellenanalysen und Incident Response abdecken.

Ein CI-seitiger Begleiter: zizmor für GitHub Actions

Falco sieht eine Workload erst, wenn sie bereits läuft. zizmor, ein in Rust geschriebener statischer Analysator, liest GitHub-Actions-YAML-Dateien, ohne sie auszuführen, und sucht nach Problemen wie nicht gepinnten Third-Party-Actions, zu weit gefassten Berechtigungen und Mustern, die zu Cache-Poisoning führen können. Die Ergebnisse lassen sich im SARIF-Format ausgeben, sodass Funde direkt im Code-Scanning-Tab von GitHub erscheinen statt in einem separaten Dashboard.

Die aktuelle zizmor-Version, v1.30.1, folgt auf die Fixes von v1.30.0 für den Action-Pin-Abgleich und einen Parser-Absturz bei tief verschachtelten Workflow-Ausdrücken. Auf der Runtime-Seite erreichte Falco 0.45.0 am 21. September 2026 nach einem Release-Candidate-Zyklus die finale Stable-Version; Teams, die noch die frühere Kandidatenversion 0.45.0-rc4 einsetzen, sollten auf den Stable-Build wechseln, statt in Produktion auf einer Release Candidate zu bleiben.

Was zu tun ist

• Zuerst Falcos Standardregeln für interaktive Shells, sensible Mount-Zugriffe und Rechteänderungen aktivieren — sie liefern das klarste Signal.
• Jeden Alert mit Cluster, Namespace, Tenant und Pod-Identität versehen und in das bereits genutzte Bereitschafts- oder ITSM-Tool leiten.
• zizmor bei jedem Pull Request laufen lassen, der eine Workflow-Datei ändert, und die Prüfung bei neuen Findings hoher Schwere fehlschlagen lassen.
• Third-Party-Actions per SHA pinnen und permissions: auf das beschränken, was jeder Job tatsächlich braucht.
• Falco in Produktionsclustern zunächst nur mit Alert-Regeln einsetzen und erst nach Verständnis der Baseline in Richtung Blocking verschärfen.
• Die Ausgabe beider Tools in dieselbe Alert-Pipeline einspeisen, die auch für andere Sicherheitssignale genutzt wird, damit nichts in einem separaten Dashboard untergeht.

Quellen: Falco auf GitHub, Falco-Dokumentation, Release Notes zu Falco 0.45.0, zizmor-Dokumentation.