Per la maggior parte dell''ultimo decennio, la sicurezza runtime ha significato un agente. Installavi software su ogni host che si integrava nel sistema in qualche modo — un modulo kernel, uno shim basato su ptrace, un daemon in userspace che parseava i log — e osservava il comportamento cattivo. Questi agenti funzionavano, ma avevano un costo: significativo overhead di CPU e memoria, fragilità tra versioni del kernel, e nel caso di moduli kernel, il rischio genuino di crashare la macchina che erano destinati a proteggere. Entro il 2026 quel modello è stato ampiamente soppiantato da uno migliore. Extended Berkeley Packet Filter — eBPF — consente ai tool di sicurezza di eseguire programmi sandboxati dentro il kernel Linux stesso, osservando syscall, esecuzione di processo, attività di rete e accesso ai file alla fonte, con overhead misurato in frazioni di percento e nessun modulo kernel personalizzato da mantenere.
Questo cambio è più importante negli ambienti cloud-native, dove i carichi di lavoro sono effimeri, i container condividono un kernel, e il vecchio modello di un agente pesante per host semplicemente non si adatta. Tre tool open-source dominano lo spazio runtime security eBPF, e sono genuinamente diversi in filosofia: Falco, lo standard di rilevamento CNCF-graduated; Tetragon, il motore di osservabilità-e-enforcement del progetto Cilium; e Tracee, lo strumento di rilevamento-e-forensics di Aqua Security. Questa guida spiega come eBPF ha cambiato il gioco, poi confronta i tre attraverso rilevamento, enforcement, forensics e fitness operazionale così puoi scegliere deliberatamente.
Perché eBPF ha vinto
Per apprezzare i tre tool, aiuta capire perché eBPF ha soppiantato le alternative così decisamente. Gli approcci più vecchi avevano ognuno un compromesso fatale. I moduli kernel davano profonda visibilità ma funzionavano con pieni privilegi kernel e potevano pancake il sistema; un bug nel tuo agente di sicurezza diventava un crash del kernel. Gli agenti in userspace erano sicuri ma ciechi a molta attività a livello kernel e imponevano 15-30% di overhead in alcune configurazioni a causa del costante context switching tra kernel e userspace. Gli approcci di log-parsing erano sicuri e economici ma senza speranza after-the-fact e facili da eludere.
eBPF ha filato l''ago. I programmi corrono nel kernel, così vedono tutto alla fonte — syscall, creazione di processo, pacchetti di rete, aperture di file — ma corrono dentro una sandbox verificata: il verifier del kernel staticamente prova che un programma eBPF non può crashare il sistema, eseguire un loop infinito, o accedere a memoria che non dovrebbe prima che gli sia mai permesso di caricare. Il risultato è visibilità a livello kernel con sicurezza a livello userspace, con overhead consistentemente misurato sotto l''1% di CPU. Nessun modulo personalizzato da compilare per kernel, nessun panic, nessuna tassa di heavy context-switching. Per carichi di lavoro cloud-native effimeri e ad alta densità, quella combinazione è esattamente quello di cui c''era bisogno, il che è il motivo per cui eBPF è diventato lo standard di runtime-security del 2026 piuttosto che una opzione tra molte.
L''avvertenza — e vale la pena dirlo chiaramente — è che eBPF richiede un kernel ragionevolmente moderno, e le funzionalità più profonde (come alcuni hook di enforcement) dipendono da capacità kernel come BTF e LSM support. In pratica la maggior parte delle distribuzioni attuali si qualificano, ma kernel molto vecchi rimangono un vincolo.
Falco: lo standard di rilevamento
Falco è il più stabilito tra i tre. Creato da Sysdig, donato al CNCF nel 2018, e ora un progetto graduated, è effettivamente l''implementazione di riferimento di rilevamento di minacce runtime basato su eBPF. Il suo modello è alerting rule-driven: Falco ingesta lo stream di eventi kernel via eBPF e li valuta contro una libreria di regole scritte in una sintassi YAML leggibile, emettendo alert quando il comportamento corrisponde a una regola. Una regola potrebbe dire "alert se una shell è spawned dentro un container," o "alert se un processo scrive a un percorso noto sensibile," o "alert su una connessione outbound a una destinazione inattesa."
I punti di forza di Falco sono maturità ed ecosistema. Il linguaggio di regola è accessibile, il ruleset di default codifica un ampio corpo di conoscenza della comunità su comportamento sospetto, e perché è lo standard CNCF, si integra con essenzialmente tutto — Kubernetes, SIEM, pipeline di alerting, e il più ampio panorama di tooling cloud-native. Se il tuo obiettivo è "rilevare e alert su comportamento runtime sospetto con uno strumento well-understood e ampiamente supportato," Falco è il default sicuro e il con il più ampio pool di documentazione, regole e esperienza operazionale da cui attingere.
La sua limitazione deliberata è che Falco è focalizzato su rilevamento. Ti dice che qualcosa di cattivo è accaduto; non è principalmente progettato per fermarlo nel kernel. Questo è uno scope ragionevole — molti team vogliono il rilevamento che alimenta un workflow di risposta piuttosto che l''uccisione automatizzata in-kernel — ma è la linea dove gli altri due strumenti si differenziano.
Tetragon: osservabilità e enforcement in-kernel
Tetragon viene dal progetto Cilium (originariamente Isovalent, ora parte di Cisco) e affronta la sicurezza runtime dall''angolo di osservabilità profonda più enforcement. Come Falco usa eBPF per osservare esecuzione di processo, accesso ai file, attività di rete e cambiamenti di privilegio, producendo stream di eventi ricchi e consapevoli di Kubernetes. Ma la sua capacità definitoria è che può agire nel kernel: attraverso LSM hook enforcement, Tetragon è lo strumento eBPF open-source con capacità native di block e kill, in grado di terminare un processo offensivo o sovrascrivere una syscall sincronamente, in-kernel, piuttosto che solo emettere un alert per che qualcosa possa reagire più tardi.
Questo importa perché il gap tra rilevamento e risposta è dove accade il danno. Un alert che un processo sta exfiltrando dati è utile; una policy che uccide quel processo nel momento in cui fa la syscall non consentita è prevenzione. I TracingPolicy custom resource di Tetragon ti permettono di dichiarare esattamente quale comportamento kernel osservare e quale azione intraprendere — osserva, o enforza con signal, kill o error return. Combinato con forte contesto di identità Kubernetes (gli eventi sono legati a pod e label, non solo PID), questo rende Tetragon particolarmente forte per team che vogliono sia visibilità profonda che la capacità di enforza policy a livello kernel. La cheatsheet Tetragon copre il modello di policy in dettaglio.
Il trade-off è peso concettuale. L''enforcement è potente e corrispondentemente pericoloso — una policy di kill sconsiderata può abbattere carichi di lavoro legittimi — e il modello TracingPolicy ha più surface area da imparare di quello delle regole Falco. Tetragon ripaga team pronti a investire in quel modello con prevenzione, non solo rilevamento.
Tracee: rilevamento più forensics
Tracee, da Aqua Security, occupa una terza posizione: rilevamento basato su eBPF con un inusuale enfasi su forensics. Come gli altri traccia gli eventi kernel e applica firme comportamentali per segnalare tecniche di attacco — anti-debugging, caricamento di codice dinamico, iniezione LD_PRELOAD, privilege escalation, container escape. Dove si differenzia è in ciò che può catturare per l''investigazione: Tracee può catturare binari eseguiti, regioni di memoria e traffico di rete per-evento su disco, dando a un incident responder gli artefatti effettivi di un attacco piuttosto che solo una notifica che uno si è verificato.
Quella cattura forense è il differenziatore. Quando un rilevamento si attiva, la domanda è immediatamente "esattamente cosa ha fatto?" — e Tracee è costruito per rispondere a ciò preservando le prove. Il suo sistema di firma (Go e Rego) è estensibile, e il suo filtraggio di evento e scope è granulare abbastanza da focalizzarsi esattamente sui processi o container di interesse. Per team la cui priorità è non solo sapere che un attacco è accaduto ma essere in grado di ricostruire e analizzarlo, le capacità di cattura di Tracee sono convincenti. La cheatsheet Tracee espone i selettori di evento e le opzioni di cattura.
Il positioning di Tracee significa che si sovrappone a Falco su rilevamento mentre estendosi in forensics, e si sovrappone meno al focus di enforcement di Tetragon. È rilevamento-e-investigazione piuttosto che rilevamento-e-prevent.
Come si confrontano
I tre strumenti sono meglio compresi dal loro centro di gravità piuttosto che da una checklist di feature, perché tutti e tre condividono la fondazione eBPF e tutti e tre rilevano il comportamento sospetto. Falco si concentra su rilevamento e alerting, con il più ampio ecosistema e la curva di apprendimento più dolce — la scelta standard quando vuoi rilevamento di minacce maturo e well-supported che alimenta una pipeline di risposta. Tetragon si concentra su osservabilità più enforcement in-kernel, l''unico dei tre che nativamente blocca e uccide, rendendolo la scelta quando la prevenzione a livello kernel è l''obiettivo e il team investirà nel suo modello di policy. Tracee si concentra su rilevamento più cattura forense, la scelta quando la ricostruzione e analisi di attacchi importa tanto quanto rilevarli.
La loro relazione al panorama commerciale chiarisce anche le cose. Falco sustain la piattaforma CNAPP commerciale di Sysdig; Tetragon viene dalla lineage Cilium/Isovalent ora dentro Cisco; Tracee viene da Aqua. In tutti e tre i casi lo strumento open-source è genuinamente usabile da solo, con il vendor che offre una piattaforma gestita su aggiunto in cima per team che vogliono dashboard centralizzate, scope CNAPP più ampio e support. Puoi adottare qualsiasi dei tre strumenti open-source senza comprare nulla, il che è parte di perché questo spazio si è consolidato attorno ad essi.
Un punto che vale la pena fare è che questi strumenti non sono strettamente mutuamente esclusivi. Alcune organizzazioni eseguono Falco per il suo ruleset di rilevamento maturo insieme a Tetragon per l''enforcement, accettando un po'' di sovrapposizione in cambio di best-of-both. Più comunemente, però, i team scelgono quello il cui centro di gravità corrisponde alla loro necessità primaria, perché eseguire multipli agent di kernel-instrumenting ha il suo overhead e costo operazionale.
Un rilevamento concreto, tre modi
Per rendere le differenze tangibili, prendi uno scenario di attacco comune — una reverse shell spawned dentro un container — e vedi come ogni strumento la gestisce. Il comportamento è inequivocabile: un processo container spawna /bin/sh (o simile) con i suoi stream standard wired a un socket di rete, un pattern quasi mai visto in carichi di lavoro containerizzati legittimi, che tipicamente eseguono un singolo processo definito.
Con Falco, avresti una regola che corrisponde a "una shell spawned in un container con una connessione outbound allegata," e quando la reverse shell lancia, Falco emette un alert attraverso i suoi canali di output — a stdout, un file, un SIEM o una pipeline di alerting. La risposta è quello che il tuo tooling downstream fa con quel alert: pagina un umano, trigger un''automazione, loggalo per l''investigazione. Falco ha visto e detto; agire è il lavoro di qualcun altro.
Con Tetragon, puoi fare lo stesso rilevamento, ma puoi anche allegare un''azione di enforcement alla policy. Una TracingPolicy che guarda per quel exec pattern può portare un''azione Sigkill, così il momento in cui il processo offensivo fa la syscall non consentita, Tetragon lo termina in-kernel — prima che la shell sia utilizzabile. L''attacco non è solo rilevato ma prevenuto, sincronamente, senza un round-trip a userspace e ritorno. Il trade-off è che devi essere fiducioso che la policy non matcherà mai un processo legittimo, perché la conseguenza di un match falso è un carico di lavoro ucciso.
Con Tracee, il rilevamento si attiva da una firma comportamentale, e poi le sue capacità forensiche si engaged: può catturare il binario eseguito, la memoria del processo, e il traffico di rete della connessione su disco. L''incident responder arriva non solo a un alert ma a un set preservato di artefatti — il malware binario effettivo, il traffico di exfiltrazione effettivo — pronto per l''analisi. L''enfasi è su rendere l''investigazione post-rilevamento il più ricca possibile.
Stesso attacco, tre filosofie: notifica, prevenzione, o preserve-for-analysis. Nessuno è sbagliato; riflettono risposte diverse a la domanda di cosa dovrebbe accadere l''istante in cui qualcosa di cattivo è rilevato, e quella domanda è la da rispondere prima di scegliere uno strumento.
Scegliere e deployare
La decisione scorre da cosa stai effettivamente cercando di realizzare. Se vuoi il rilevamento di minacce runtime con il minimo attrito e il supporto più ampio, inizia con Falco — è lo standard per buone ragioni e il più facile da staffare e operare. Se la tua priorità è prevenire il comportamento cattivo nel kernel, non solo esserne detto, e stai eseguendo Kubernetes dove il suo modello di identità brilla, scegli Tetragon e bilancia il tempo per imparare TracingPolicy e testare l''enforcement attentamente prima di abilitare le azioni di kill in produzione. Se il tuo lavoro è incident-response-heavy e hai bisogno di catturare e analizzare gli artefatti di un attacco, scegli Tracee per la sua cattura forense.
Qualunque tu scelga, alcune realtà di deployment si applicano a tutti e tre. Conferma che i tuoi kernel incontrino i requisiti, specialmente per feature di enforcement che dipendono da LSM e BTF. Inizia in una postura detect-only e sintonizza le regole o firme contro i tuoi carichi di lavoro reali prima di considerare qualsiasi enforcement, perché il modo più veloce per perdere fiducia in uno strumento di runtime security è un falso positivo che uccide un processo di produzione. Wire lo stream di evento nel tuo osservabilità esistente e SIEM piuttosto che trattarlo come un''isola. E ricorda che basso overhead non è zero overhead a scala estrema — valida l''impatto sui tuoi nodi più ad alto throughput. La fondazione eBPF rende tutti e tre drammaticamente più leggeri degli agenti che hanno sostituito, ma il rollout disciplinato rimane importante.
Il bottom line
eBPF ha riscritto la runtime security dando ai tool visibilità a livello kernel con sicurezza verified e safety sub-1%-overhead, andando in pensione i moduli kernel fragili e heavy userspace agent che è venuto prima. I tre strumenti open-source che definiscono lo spazio ognuno scelgono un centro di gravità sulla stessa fondazione: Falco per la rilevamento maturo e alerting, Tetragon per l''osservabilità e enforcement in-kernel, e Tracee per il rilevamento plus cattura forense. Corrisponde lo strumento al tuo obiettivo primario — rilevare, prevenire o investigare — deployalo in modalità detect-only prima, sintonizza contro il traffico reale, e ottieni una protezione che finalmente si adatta come i sistemi cloud-native effettivamente corrono.
Riferimenti e Risorse
Tool
Sfondo e analisi
- eBPF Runtime Security Tools 2026: Falco vs Tetragon vs Tracee
- Container Runtime Security 2026 — NomadX
- Open Source CWPP: Falco, Tracee, Tetragon Overview
Cheatsheet 1337skills correlati