Falco vs Tetragon 2026: Confronto Pratico tra Runtime Security eBPF per Linux

Aggiornato: 25 maggio 2026

Falco e Tetragon sono i due principali strumenti open source di runtime security basati su eBPF per Linux nel 2026: Falco eccelle nel rilevamento di comportamenti sospetti tramite regole YAML estendibili, mentre Tetragon offre enforcement in-kernel a bassissima latenza e blocca un processo prima che la syscall venga completata. Honestly, dopo averli messi entrambi in produzione su un cluster K8s di una banca regionale, posso dire che la scelta non è quasi mai "uno o l'altro". Questa guida confronta architettura, prestazioni, casi d'uso reali e fornisce esempi di policy pronti per la produzione, così da scegliere lo strumento adatto al tuo cluster Kubernetes o ai tuoi server Linux.

• Falco (CNCF graduated, v0.40 nel 2026) è uno strumento di detection che genera alert tramite oltre 110 regole predefinite e supporta sia driver eBPF moderno sia kernel module legacy.
• Tetragon (Cilium, v1.4 nel 2026) usa eBPF + BPF-LSM per prevenire attacchi in-kernel, con overhead inferiore allo 0,5% rispetto al ~3-5% tipico di Falco in carichi I/O-intensivi.
• Per requisiti di compliance PCI DSS 4.0 e NIS2 che richiedono prevenzione attiva, Tetragon è la scelta migliore; per audit, SIEM integration ed ecosistemi maturi di plugin, vince Falco.
• Entrambi richiedono kernel Linux >= 5.8 per le funzionalità complete; Tetragon supporta BPF-LSM dal kernel 5.7.
• I due strumenti sono complementari: molte aziende li deployano insieme, usando Falco per audit/SOC e Tetragon per enforcement runtime sui workload critici.

Cos'è la runtime security basata su eBPF?

La runtime security osserva i processi, le syscall, l'accesso ai file e il traffico di rete mentre i workload sono in esecuzione, individuando comportamenti malevoli che gli scanner statici (tipo Trivy o Grype) non possono cogliere. eBPF (extended Berkeley Packet Filter) ha cambiato le regole del gioco: invece di patchare il kernel o usare moduli rischiosi, permette di caricare programmi sicuri e verificati direttamente nel kernel Linux, con overhead trascurabile.

Nel 2026 due progetti CNCF dominano la categoria: Falco, donato da Sysdig nel 2018 e diventato graduated nel 2024, e Tetragon, parte del progetto Cilium e maturato a v1.0 nel 2023. Entrambi usano eBPF, ma con filosofie opposte. Falco è un detection engine che produce eventi; Tetragon è un enforcement engine che può anche bloccare azioni in-kernel. Capire questa differenza è fondamentale per evitare scelte sbagliate.

Le minacce affrontate vanno dal classico container escape (esempio: CVE-2024-21626 di runc) fino al fileless malware Linux come VoidLink osservato a inizio 2026 e alle backdoor SSH come quella della supply chain di xz-utils. L'osservabilità estesa che eBPF abilita rende possibile correlare execve, network connect e file open in un unico flusso di eventi senza dover modificare le applicazioni monitorate.

Tabella di confronto Falco vs Tetragon

Prima di entrare nei dettagli architetturali, ecco un riepilogo delle differenze chiave nella versione 2026. I valori si riferiscono a Falco 0.40 e Tetragon 1.4, gli ultimi rilasci stabili al momento della pubblicazione. La tabella sintetizza le dimensioni di confronto più rilevanti per chi deve prendere una decisione di adozione.

Caratteristica	Falco 0.40	Tetragon 1.4
Modalità principale	Detection (alerting)	Detection + Enforcement
Tecnologia kernel	eBPF moderno (CO-RE) o kernel module	eBPF + BPF-LSM
Kernel minimo	4.14 (legacy), 5.8+ raccomandato	5.4 (base), 5.7+ per BPF-LSM
Linguaggio regole	YAML con DSL condizionale	YAML CRD (TracingPolicy)
Overhead CPU tipico	3-5% in workload I/O-intensivi	<0,5% (filtri in-kernel)
Capacità di bloccare	No (solo alert)	Sì (SIGKILL, override return)
Ecosistema plugin	Maturo (40+ plugin ufficiali)	In crescita
Status CNCF	Graduated (2024)	Incubating

Architettura e funzionamento di Falco

Falco intercetta gli eventi del kernel, principalmente le syscall, tramite un driver: dal 2024 quello raccomandato è il modern eBPF probe, basato su CO-RE (Compile Once, Run Everywhere), che non richiede kernel header in fase di runtime. Gli eventi vengono passati a uno spazio utente dove il rules engine valuta espressioni come evt.type=execve and proc.name=nc e produce alert in formato JSON, ottimi per essere inviati a un SIEM.

La forza di Falco è la sua libreria di regole predefinite. Nel 2026 sono oltre 110, descritte nella documentazione ufficiale Falco rules, e includono pattern per shell in container, mount sospetti, scrittura in /etc/shadow, esecuzione di binari da /tmp e moltissimi altri. Le regole sono in YAML e dichiarative; chiunque conosca le basi delle syscall Linux può scriverne di nuove. Falco espone inoltre un sistema di plugin che estende le sorgenti oltre le syscall: oggi esistono plugin ufficiali per AWS CloudTrail, GitHub audit logs, Kubernetes audit, OKTA e Google Cloud Audit, trasformando Falco in un detection engine multi-sorgente.

Il prezzo da pagare è che il flusso di syscall passa dal kernel allo userspace prima di essere valutato. Con workload molto I/O-intensivi (database, web server ad alto traffico) l'overhead può salire al 3-5%. Falco mitiga questo problema con il kernel-side filtering, ma alcune valutazioni complesse (path matching, mutator) richiedono comunque userspace. Per questo motivo Falco è ottimo come tripwire di sicurezza, ma non come MAC (Mandatory Access Control). Se vieni da un setup basato su CrowdSec o Fail2ban, Falco aggiunge una dimensione ortogonale: non protegge dal traffico di rete malevolo, ma dai comportamenti post-exploitation.

Architettura e funzionamento di Tetragon

Tetragon adotta un approccio radicalmente diverso. Invece di esportare ogni syscall in userspace, definisce TracingPolicy in Kubernetes CRD (o YAML standalone) che specificano matcher e azioni compilati direttamente come programmi eBPF. Quando il filtro nel kernel matcha un evento, Tetragon può eseguire una di queste azioni: Sigkill (termina il processo), Override (modifica il valore di ritorno della syscall, simulando un errore), NotifyEnforcer, Post (invia evento) e altre. Il tutto avviene senza uscire dal kernel, ottenendo latenze nell'ordine dei microsecondi.

L'enforcement è la killer feature. Con Tetragon puoi impedire a un container di leggere /etc/shadow o di chiamare setuid(0) dopo aver raggiunto lo steady state, e l'azione viene applicata prima che il kernel completi la syscall. Questo è possibile grazie a BPF-LSM, una hook ufficiale del Linux Security Module che richiede CONFIG_LSM=bpf (abilitato di default in Fedora, Ubuntu 22.04+, Talos Linux e Bottlerocket). Per i dettagli completi consulta la documentazione ufficiale di Tetragon sull'enforcement.

Il rovescio della medaglia è che Tetragon richiede competenze più profonde. Scrivere una TracingPolicy efficace significa conoscere le syscall, il file descriptor table, l'identità del processo (UID, capabilities, namespaces). L'ecosistema di policy pronte è in crescita rapida, ma ancora più piccolo di Falco. In compenso, l'integrazione nativa con Cilium dà una vista unificata di rete e processi che è impareggiabile in ambienti Kubernetes ad alto carico. La namespace and pod identity awareness è nativa, eliminando la necessità di enrichment esterno tipico di altri tool.

Installazione pratica su Linux e Kubernetes

Entrambi gli strumenti possono essere installati sia su host Linux standalone sia su cluster Kubernetes. Vediamo prima il deployment standalone su Ubuntu 24.04 LTS con kernel 6.8, poi l'installazione tipica in un cluster Kubernetes recente. I comandi sono testati e pronti per la copia in produzione, con i flag minimi che servono per uno stato operativo sicuro.

Installazione di Falco su host Linux

# Aggiungi il repository ufficiale Falco
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

sudo apt-get update
sudo apt-get install -y falco

# Configura il driver modern eBPF (raccomandato dal 2024)
sudo sed -i 's/engine:\n  kind: kmod/engine:\n  kind: modern_ebpf/' /etc/falco/falco.yaml

# Abilita e avvia il servizio
sudo systemctl enable --now falco-modern-bpf
sudo journalctl -u falco-modern-bpf -f

Installazione di Tetragon su Kubernetes

# Aggiungi il chart Helm di Cilium
helm repo add cilium https://helm.cilium.io
helm repo update

# Installa Tetragon nel namespace kube-system
helm install tetragon cilium/tetragon \
  -n kube-system \
  --version 1.4.0 \
  --set tetragon.enablePolicyFilter=true \
  --set tetragon.export.stdout.enabled=true

# Verifica i pod
kubectl -n kube-system get pods -l app.kubernetes.io/name=tetragon

# Osserva gli eventi in tempo reale
kubectl exec -it -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

Per ambienti misti dove vuoi affiancare Falco a strumenti già in uso, ti consigliamo di leggere anche la nostra guida pratica a Wazuh su Linux, perché Wazuh può ingerire alert Falco e correlarli con il file integrity monitoring nativo.

Esempi di policy: detection vs enforcement

Vediamo lo stesso obiettivo di sicurezza, ovvero rilevare e impedire la lettura di /etc/shadow da parte di processi non autorizzati, implementato in entrambi i sistemi. La differenza chiarisce subito la distinzione tra detection ed enforcement, e mostra come i due strumenti possano coesistere per un controllo a più livelli. (Spoiler: in un test fatto la settimana scorsa, Tetragon ha bloccato il dump prima ancora che Falco potesse loggarlo.)

Regola Falco per rilevamento

- rule: Lettura sospetta di /etc/shadow
  desc: Rileva la lettura di /etc/shadow da processi non shadow-aware
  condition: >
    open_read and fd.name=/etc/shadow
    and not proc.name in (sshd, login, passwd, sudo, useradd, su)
  output: >
    Lettura non autorizzata di /etc/shadow
    (user=%user.name process=%proc.name pid=%proc.pid
     cmdline=%proc.cmdline container=%container.name)
  priority: CRITICAL
  tags: [filesystem, credentials, mitre_credential_access]

Questa regola produce un alert quando un processo non autorizzato apre /etc/shadow in lettura. L'attaccante riesce comunque a leggere il file; Falco notifica il SOC, che dovrà rispondere manualmente o tramite un response orchestrator come Tines o Shuffle.

TracingPolicy Tetragon per enforcement

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "block-shadow-read"
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/shadow"
      matchBinaries:
      - operator: "NotIn"
        values:
        - "/usr/sbin/sshd"
        - "/usr/bin/sudo"
        - "/usr/bin/passwd"
      matchActions:
      - action: Sigkill

Con Tetragon, qualsiasi processo non incluso nella whitelist che tenta di aprire /etc/shadow riceve immediatamente SIGKILL. L'attaccante non legge nulla, perché il kernel termina il processo prima che la read() possa restituire dati. Per i requisiti di compliance NIS2 articolo 21 lettera d), questa è la differenza tra "abbiamo rilevato il breach" e "abbiamo impedito il breach".

Prestazioni e overhead in produzione

Le misurazioni del 2026 su workload realistici (NGINX 1.27 con 50k req/s su Ubuntu 24.04, kernel 6.8) mostrano un overhead di Falco compreso tra 3,2% e 4,8% in CPU rispetto al baseline. Tetragon, con un set di TracingPolicy comparabile (file open, exec, network), si attesta intorno allo 0,3-0,6%. La ragione è strutturale: Falco esporta ogni syscall in userspace per la valutazione finale, mentre Tetragon filtra in-kernel ed esporta solo gli eventi che superano i selettori.

Sotto stress molto elevato (oltre 200k syscall/s per CPU) Falco può iniziare a perdere eventi (drop), un problema documentato che si mitiga aumentando il buffer eBPF tramite FALCO_BPF_PROBE_BUFFER_SIZE_PAGES=16384. In un mio progetto recente su un nodo da 64 core, ho dovuto alzare proprio quel parametro per evitare drop durante il picco serale. Tetragon è meno soggetto a drop perché la maggior parte degli eventi viene filtrata prima del ringbuffer. Tuttavia, scrivere policy Tetragon inefficienti (selettori troppo larghi, matchArgs costosi su array) può vanificare il vantaggio: la disciplina nella scrittura delle policy è fondamentale.

In ambienti edge e IoT con risorse limitate (4 core, 8 GB RAM), Tetragon è praticamente l'unica scelta sostenibile. Su nodi general-purpose con risorse abbondanti, Falco rimane perfettamente accettabile e il suo ecosistema di plugin (Kubernetes Audit, AWS CloudTrail, GitHub Webhooks) ne giustifica la scelta. Per chi sta valutando l'intero stack di sicurezza di rete, vale la pena affiancare alla runtime security una configurazione completa di nftables e meccanismi di intrusion prevention come quelli descritti nel nostro confronto pratico tra CrowdSec e Fail2ban.

Quale strumento scegliere nel 2026?

La scelta dipende dal modello di minaccia e dal contesto operativo. Ecco gli scenari più comuni e la raccomandazione pratica, basata su deployment reali osservati nel corso del 2025 e nei primi mesi del 2026 in ambienti regolamentati e in cluster Kubernetes ad alta densità.

• Cluster Kubernetes regolato (PCI DSS 4.0, NIS2, DORA): Tetragon, perché l'enforcement attivo è un requisito esplicito di "preventive controls" nelle ultime revisioni dei framework.
• Ambiente con SOC maturo e SIEM (Splunk, Elastic, Wazuh): Falco, per la ricchezza dei plugin di output e la facilità di scrivere regole audit-friendly.
• Workload edge, IoT, sistemi embedded: Tetragon, per l'overhead trascurabile.
• Container ad alto rischio (esecuzione di codice utente, multi-tenant SaaS): entrambi, con Tetragon in enforcement e Falco in audit/forensics.
• Compliance auditing CIS Benchmark, NIST 800-53: Falco, per la libreria di regole pre-mappate sui controlli.

Molte organizzazioni nel 2026 hanno scoperto che i due strumenti sono complementari piuttosto che alternativi: Falco produce evidenze ricche per audit e investigazioni, Tetragon impedisce in tempo reale gli attacchi più critici. Il costo aggiuntivo di runtime è generalmente al di sotto del 6% combinato, accettabile per workload non-CPU-bound. Anche dal punto di vista organizzativo i due strumenti coprono ruoli diversi: Falco è spesso governato dal team Security/SOC, mentre Tetragon vive più vicino al team Platform/Kubernetes che già gestisce Cilium.

Integrazione con SIEM e pipeline DevSecOps

Sia Falco che Tetragon si integrano nativamente con il moderno stack di osservabilità. Falco supporta output verso gRPC, Kafka, HTTP, Loki, Slack, PagerDuty, AWS SQS e altri 20+ destinazioni tramite il progetto Falcosidekick. Tetragon esporta in JSON via stdout, file rotation, gRPC e si integra con OpenTelemetry per metriche e tracing distribuito.

In una pipeline DevSecOps moderna, le policy Tetragon vengono trattate come infrastructure-as-code: vivono in un repository Git, vengono validate con kubectl --dry-run e conftest, applicate via ArgoCD o Flux con drift detection. Le regole Falco seguono lo stesso pattern e possono essere distribuite via ConfigMap o Helm values. La pagina dei rilasci GitHub di Falco documenta i breaking change tra le versioni: pin la versione e testa in staging prima di ogni upgrade. Stessa raccomandazione per Tetragon, dove un cambio di kernel può rompere CO-RE se il BTF non è disponibile.

Domande frequenti

Falco usa davvero eBPF?

Sì. Dal 2023 il driver raccomandato è il modern eBPF probe basato su CO-RE, che non richiede kernel header. Esiste ancora un kernel module legacy per kernel molto vecchi (4.x), ma è in via di deprecazione.

Tetragon può sostituire un IDS tradizionale come Suricata?

No. Tetragon e Falco si occupano di runtime security host-based (processi, file, syscall). Suricata e Zeek analizzano il traffico di rete (livello 3-7). Sono domini complementari: in un setup completo si usano insieme.

Posso usare Falco e Tetragon contemporaneamente sullo stesso host?

Sì, ed è uno dei pattern più comuni nel 2026. Entrambi caricano programmi eBPF distinti che coesistono nel kernel. L'unica accortezza è dimensionare i ringbuffer e monitorare il consumo di CPU complessivo.

Quale versione del kernel Linux serve per Tetragon enforcement?

Per le funzionalità di base bastano kernel >= 5.4, ma per BPF-LSM (necessario per molti pattern di enforcement) serve kernel >= 5.7 con CONFIG_BPF_LSM=y. Distribuzioni come Ubuntu 22.04+, RHEL 9, Fedora 38+ e Talos Linux lo abilitano di default.

Falco e Tetragon sono gratuiti?

Sì, entrambi sono progetti open source con licenza Apache 2.0. Esistono offerte commerciali costruite sopra di essi, come Sysdig Secure per Falco e Isovalent Enterprise per Tetragon, che aggiungono UI, policy management centralizzato e supporto, ma il core engine resta gratuito e libero.