Falco voor MSP's: runtime-detectie van CI-pipelines tot Kubernetes-clusters

Beheerde Kubernetes-clusters en de CI-pipelines die er code naartoe sturen zijn twee verschillende aanvalsoppervlakken, en MSP's hebben steeds vaker voor allebei een apart hulpmiddel nodig. Deze gids behandelt Falco, een door de CNCF gegradueerde runtime-engine die verdacht containergedrag omzet in een afgestemde alertpipeline, en zizmor, een statische analysetool die risicovolle GitHub Actions-configuratie opspoort voordat een workflow ooit draait.

Wat Falco is, en wat het opspoort

Falco is gemaakt door Sysdig en is nu een gegradueerd project van de Cloud Native Computing Foundation. Het observeert systeemaanroepen via op eBPF gebaseerde monitoring en signaleert proces-, bestands- en netwerkactiviteit die er verdacht uitziet binnen een draaiende container. Daardoor kan een inbraak worden opgemerkt terwijl die nog bezig is, in plaats van pas bij een analyse achteraf.

Waarop je eerst moet alerten

Niet elk signaal dat Falco kan genereren rechtvaardigt een oproep aan de wachtdienst. Voor MSP's die veel tenants beheren, zijn de regels die het meest opleveren die met een lage foutpositievenratio en hoge kosten bij het missen ervan: een interactieve shell die start binnen een applicatiecontainer die er nooit een nodig zou moeten hebben, een proces dat leest vanaf een gevoelig mount-pad zoals het bestandssysteem van de host, en wijzigingen in rechten of Linux-capabilities binnen een draaiende pod. Deze drie dekken de meeste scenario's waarin er echt iets actiefs gebeurt waar operators zich zorgen over maken.

Alerts zo routeren dat ze worden opgepakt

Een detectietool helpt alleen als de alert iemand bereikt die kan ingrijpen. Falco-events moeten genoeg context meedragen — cluster, namespace, tenant en pod-identiteit — om rechtstreeks naar de wachtdienst- of ITSM-tooling van de MSP te worden gerouteerd, met een gedocumenteerde indammingsstap voordat een alert wordt gesloten. Regels afstemmen op de baseline van elke klant voorkomt alertmoeheid: een shell die normaal is in een namespace van een CI-runner is dat niet in een klantgerichte webpod.

Waar Falco stopt

Falco is een detectielaag, geen responssysteem. Het isoleert geen workload, rolt geen deployment terug en roteert geen credentials op eigen houtje; die stappen vragen nog steeds om een playbook en een menselijke of geautomatiseerde responder achter de alert. Zie het als de sensor, niet als het hele beveiligingsprogramma.

MSP's die externe hulp nodig hebben bij het opzetten van dat playbook, of bewijs van een getest detectie- en responsproces voor NIS2-, DORA- of GDPR-audits, kunnen terecht bij de cybersecuritydiensten van Altovar, die penetratietesten, kwetsbaarheidsbeoordelingen en incidentrespons omvatten.

Een aanvulling aan CI-zijde: zizmor voor GitHub Actions

Falco ziet een workload pas zodra die al draait. zizmor, een in Rust geschreven statische analysetool, leest YAML-bestanden van GitHub Actions zonder ze uit te voeren, op zoek naar problemen zoals niet-vastgezette third-party actions, te ruime permissies en patronen die tot cache-poisoning kunnen leiden. Het kan resultaten in SARIF-formaat opleveren, zodat bevindingen rechtstreeks in de code scanning-tab van GitHub verschijnen in plaats van in een apart dashboard.

De huidige zizmor-release, v1.30.1, volgt op de fixes van v1.30.0 voor het matchen van action-pins en een parsercrash bij diep geneste workflow-expressies. Aan de runtime-kant bereikte Falco 0.45.0 op 21 september 2026 de definitieve stabiele release na een release-candidate-cyclus; teams die nog op de eerdere candidate 0.45.0-rc4 draaien, kunnen beter overstappen op de stabiele build dan een release candidate in productie te houden.

Wat te doen

• Zet eerst Falco's standaardregels aan voor interactieve shells, gevoelige mount-reads en rechtenwijzigingen — dat zijn de duidelijkste signalen.
• Voorzie elke alert van cluster, namespace, tenant en pod-identiteit, en rout hem naar de wachtdienst- of ITSM-tool die het team al gebruikt.
• Draai zizmor op elke pull request die een workflowbestand raakt, en laat de check falen bij nieuwe bevindingen met hoge ernst.
• Pin third-party actions vast op een SHA-hash en beperk permissions: tot wat elke job echt nodig heeft.
• Zet Falco eerst met alert-only regels in op productieclusters, en verscherp pas richting blokkeren zodra de baseline duidelijk is.
• Stuur de output van beide tools naar dezelfde alertpipeline die ook voor andere beveiligingssignalen wordt gebruikt, zodat niets verdwijnt in een apart dashboard.

Bronnen: Falco op GitHub, Falco-documentatie, releasenotes van Falco 0.45.0, zizmor-documentatie.