Falco per gli MSP: rilevamento a runtime dalle pipeline CI alle flotte Kubernetes

Le flotte Kubernetes gestite e le pipeline CI che ci distribuiscono codice sono due superfici d'attacco distinte, e gli MSP hanno sempre più bisogno di uno strumento per ciascuna. Questa guida copre Falco, un motore runtime graduated della CNCF che trasforma comportamenti sospetti dei container in una pipeline di alert calibrata, e zizmor, un analizzatore statico che individua configurazioni GitHub Actions rischiose prima ancora che un workflow venga eseguito.

Cos'è Falco, e cosa rileva

Falco è stato creato da Sysdig ed è oggi un progetto graduated della Cloud Native Computing Foundation. Osserva le chiamate di sistema tramite il monitoraggio basato su eBPF e segnala attività di processi, file e rete che appaiono anomale dentro un container in esecuzione. Questo lo rende un modo per cogliere un'intrusione in corso, invece di scoprirla solo durante un'analisi post-incidente.

Su cosa attivare gli alert per primi

Non tutti i segnali che Falco può generare meritano una chiamata al reperibile. Per gli MSP che gestiscono molti tenant, le regole più importanti uniscono un basso tasso di falsi positivi a un costo elevato se ignorate: una shell interattiva avviata dentro un container applicativo che non dovrebbe mai averne bisogno, un processo che legge da un percorso di mount sensibile come il filesystem dell'host, e modifiche ai privilegi o alle capability Linux dentro un pod in esecuzione. Queste tre coprono la maggior parte degli scenari in cui sta succedendo qualcosa di attivo a cui gli operatori tengono davvero.

Instradare gli alert perché vengano gestiti

Uno strumento di rilevamento serve solo se l'alert raggiunge qualcuno che può intervenire. Gli eventi Falco dovrebbero portare con sé abbastanza contesto — cluster, namespace, tenant e identità del pod — da poter essere instradati direttamente negli strumenti di reperibilità o ITSM dell'MSP, con un passaggio di contenimento documentato prima che un alert venga chiuso. Calibrare le regole sulla baseline di ogni cliente evita l'affaticamento da alert: una shell normale in un namespace di un runner CI non lo è in un pod web rivolto ai clienti.

Dove si ferma Falco

Falco è un livello di rilevamento, non un sistema di risposta. Non isola un carico di lavoro, non esegue il rollback di un deployment né ruota le credenziali da solo: questi passaggi richiedono comunque un playbook e un risponditore umano o automatizzato dietro l'alert. Trattalo come il sensore, non come l'intero programma di sicurezza.

Se hai bisogno di supporto esterno per costruire quel playbook, o di una prova di un processo di rilevamento e risposta testato per gli audit NIS2, DORA o GDPR, puoi rivolgerti ai servizi di cybersecurity di Altovar, che coprono penetration testing, vulnerability assessment e incident response.

Un compagno lato CI: zizmor per GitHub Actions

Falco vede un carico di lavoro solo quando è già in esecuzione. zizmor, un analizzatore statico basato su Rust, legge i file YAML di GitHub Actions senza eseguirli, cercando problemi come action di terze parti non bloccate a una versione specifica, permessi eccessivamente ampi e pattern che possono portare ad avvelenamento della cache. Può generare risultati in formato SARIF, così le segnalazioni compaiono direttamente nella scheda di code scanning di GitHub invece che in una dashboard separata.

La versione attuale di zizmor, v1.30.1, segue le correzioni di v1.30.0 per il matching dei pin delle action e un crash del parser su espressioni di workflow profondamente annidate. Sul fronte runtime, Falco 0.45.0 ha raggiunto la release stabile finale il 21 settembre 2026 dopo un ciclo di release candidate; i team che usano ancora la precedente candidate 0.45.0-rc4 dovrebbero passare alla build stabile invece di restare su una release candidate in produzione.

Cosa fare

• Attiva per prime le regole predefinite di Falco su shell interattive, letture da mount sensibili e cambi di privilegi: sono i segnali più chiari.
• Assegna a ogni alert cluster, namespace, tenant e identità del pod, e instradalo verso lo strumento di reperibilità o ITSM già in uso dal team.
• Esegui zizmor su ogni pull request che tocca un file di workflow e fai fallire il controllo in caso di nuove segnalazioni di gravità alta.
• Blocca le action di terze parti a un hash SHA specifico e limita permissions: a ciò di cui ogni job ha davvero bisogno.
• Distribuisci Falco sui cluster di produzione prima con regole di solo avviso, poi restringi verso comportamenti di blocco una volta compresa la baseline.
• Inoltra l'output di entrambi gli strumenti alla stessa pipeline di alert usata per gli altri segnali di sicurezza, così non ti sfugge nulla in una dashboard separata.

Fonti: Falco su GitHub, documentazione Falco, note di rilascio di Falco 0.45.0, documentazione di zizmor.