Durante a maioria da última década, segurança em tempo de execução significava um agente. Você instalava software em cada host que se conectava ao sistema de alguma forma — um módulo do kernel, um shim baseado em ptrace, um daemon em userspace que analisava logs — e observava comportamento ruim. Esses agentes funcionavam, mas tinham um custo: sobrecarga significativa de CPU e memória, fragilidade entre versões de kernel, e no caso de módulos do kernel, o risco genuíno de derrubar a máquina que deveriam proteger. Por 2026 esse modelo foi amplamente substituído por um melhor. Extended Berkeley Packet Filter — eBPF — permite que ferramentas de segurança executem programas em sandbox dentro do próprio kernel Linux, observando syscalls, execução de processo, atividade de rede e acesso a arquivo na origem, com sobrecarga medida em frações de um por cento e nenhum módulo de kernel personalizado para manter.
Essa mudança importa mais em ambientes cloud-native, onde cargas de trabalho são efêmeras, contêineres compartilham um kernel, e o modelo antigo de um agente pesado por host simplesmente não se encaixa. Três ferramentas de código aberto dominam o espaço de segurança em tempo de execução com eBPF, e são genuinamente diferentes em filosofia: Falco, o padrão de detecção graduado da CNCF; Tetragon, a engine de observabilidade e imposição do projeto Cilium; e Tracee, a ferramenta de detecção e perícia da Aqua Security. Este guia explica como eBPF mudou o jogo, depois compara os três entre detecção, imposição, perícia e ajuste operacional para que você possa escolher deliberadamente.
Por que eBPF venceu
Para apreciar as três ferramentas, ajuda entender por que eBPF deslocou as alternativas tão decisivamente. As abordagens mais antigas cada uma tinha um compromisso fatal. Módulos do kernel deram visibilidade profunda mas executavam com privilégios totais do kernel e poderiam derrubar o sistema; um bug em seu agente de segurança se tornava uma falha do kernel. Agentes em userspace eram seguros mas cegos para muita atividade em nível de kernel e impunham sobrecarga de 15-30% em algumas configurações por causa do context switching constante entre kernel e userspace. Abordagens de análise de log eram seguras e baratas mas desesperadamente pós-fato e fáceis de evadir.
eBPF costurou a agulha. Os programas executam dentro do kernel, então eles veem tudo na origem — syscalls, criação de processo, pacotes de rede, aberturas de arquivo — mas executam dentro de um sandbox verificado: o verificador do kernel prova estaticamente que um programa eBPF não pode derrubar o sistema, ficar em loop infinito, ou acessar memória que não deveria antes de ser sempre permitido carregar. O resultado é visibilidade em nível de kernel com segurança em nível de userspace, com sobrecarga consistentemente medida abaixo de 1% de CPU. Nenhum módulo personalizado para compilar por kernel, nenhuma falha, nenhum custo pesado de context-switching. Para cargas de trabalho cloud-native efêmeras e de alta densidade, essa combinação é exatamente o que era necessário, o que é por que eBPF se tornou o padrão de segurança em tempo de execução de 2026 em vez de uma opção entre várias.
A pegadinha — e vale a pena declarar claramente — é que eBPF requer um kernel razoavelmente moderno, e as características mais profundas (como certos hooks de imposição) dependem de capacidades do kernel como BTF e suporte LSM. Na prática a maioria das distribuições atuais se qualifica, mas kernels muito antigos permanecem uma restrição.
Falco: o padrão de detecção
Falco é a mais estabelecida das três. Criada pela Sysdig, doada à CNCF em 2018, e agora um projeto graduado, é efetivamente a implementação de referência de detecção de ameaça em tempo de execução baseada em eBPF. Seu modelo é alerta orientado por regras: Falco ingere o stream de eventos do kernel via eBPF e avalia contra uma biblioteca de regras escritas em sintaxe YAML legível, emitindo alertas quando comportamento corresponde a uma regra. Uma regra poderia dizer "alerte se um shell é iniciado dentro de um contêiner," ou "alerte se um processo escreve em um caminho conhecido sensível," ou "alerte em uma conexão outbound para um destino inesperado."
Os pontos fortes do Falco são maturidade e ecossistema. A linguagem de regra é acessível, o ruleset padrão codifica um grande corpo de conhecimento da comunidade sobre comportamento suspeito, e como é o padrão da CNCF, se integra com essencialmente tudo — Kubernetes, SIEMs, pipelines de alerta e o landscape de tooling cloud-native mais amplo. Se seu objetivo é "detectar e alertar em comportamento suspeito em tempo de execução com uma ferramenta bem-entendida e amplamente suportada," Falco é o padrão seguro e o com o pool mais profundo de documentação, regras e experiência operacional para usar.
Sua limitação deliberada é que Falco é focado em detecção. Ele diz que algo ruim aconteceu; não é primariamente desenhado para parar isso no kernel. Esse é um escopo razoável — muitos times querem detecção alimentando um fluxo de trabalho de resposta em vez de automatizado em-kernel — mas é a linha onde as outras duas ferramentas se diferenciam.
Tetragon: observabilidade e imposição em-kernel
Tetragon vem do projeto Cilium (originalmente Isovalent, agora parte da Cisco) e aborda segurança em tempo de execução do ângulo de observabilidade profunda mais imposição. Como Falco usa eBPF para observar execução de processo, acesso a arquivo, atividade de rede e mudanças de privilégio, produzindo streams de evento ricos cientes de Kubernetes. Mas sua capacidade definidora é que pode agir no kernel: através de imposição de hook LSM, Tetragon é a ferramenta eBPF de código aberto com capacidades nativas de bloquear e matar, capaz de terminar um processo infrator ou sobrescrever uma syscall sincronamente, em-kernel, em vez de apenas emitir um alerta para algo reagir depois.
Isso importa porque a lacuna entre detecção e resposta é onde o dano acontece. Um alerta que um processo está exfiltrando dados é útil; uma política que mata esse processo no momento em que faz a syscall desabilitada é prevenção. O TracingPolicy recursos personalizados do Tetragon deixam você declarar exatamente quais comportamentos do kernel assistir e que ação tomar — observar, ou impor assinando, matando, ou retornando um erro. Combinado com contexto de identidade Kubernetes forte (eventos são amarrados a pods e rótulos, não apenas PIDs), isso torna o Tetragon especialmente forte para times que querem visibilidade profunda e a habilidade de impor política em nível de kernel. O cheatsheet do Tetragon cobre o modelo de política em detalhe.
O trade-off é peso conceitual. Imposição é poderosa e correspondentemente perigosa — uma política de matar descuidada pode derrubar workloads legítimas — e o modelo TracingPolicy tem mais área de superfície para aprender que as regras do Falco. Tetragon recompensa times prontos a investir nesse modelo com prevenção, não apenas detecção.
Tracee: detecção mais perícia
Tracee, da Aqua Security, ocupa uma terceira posição: detecção baseada em eBPF com ênfase de perícia incomumente forte. Como os outros rastreia eventos de kernel e aplica assinaturas comportamentais para sinalizar técnicas de ataque — anti-debugging, carregamento dinâmico de código, injeção LD_PRELOAD, escalação de privilégio, fuga de contêiner. Onde se diferencia é no que pode capturar para investigação: Tracee pode capturar binários executados, regiões de memória e tráfego de rede por-evento para disco, dando ao respondente de incidente os artefatos reais de um ataque em vez de apenas uma notificação que um ocorreu.
Essa captura forense é o diferenciador. Quando uma detecção dispara, a pergunta imediatamente é "o que exatamente ele fez?" — e Tracee é construído para responder isso preservando a evidência. Seu sistema de assinatura (Go e Rego) é extensível, e sua filtragem de evento e escopo é granular o bastante para focar exatamente nos processos ou contêineres de interesse. Para times cuja prioridade é não apenas saber que um ataque aconteceu mas ser capaz de reconstruir e analisar, as capacidades de captura do Tracee são convincentes. O cheatsheet do Tracee expõe os seletores de evento e opções de captura.
O posicionamento do Tracee significa que sobrepõe com Falco em detecção enquanto se estende para perícia, e sobrepõe menos com o foco de imposição do Tetragon. É detecção-e-investigação em vez de detecção-e-prevenção.
Como se comparam
As três ferramentas são melhor compreendidas por seu centro de gravidade em vez de uma checklist de recurso, porque todas as três compartilham a fundação eBPF e todas as três detectam comportamento suspeito. Falco se centra em detecção e alerta, com o mais profundo ecossistema e a curva de aprendizado mais gentil — a escolha padrão quando você quer detecção de ameaça madura e bem suportada alimentando um pipeline de resposta. Tetragon se centra em observabilidade mais imposição em-kernel, a única das três que nativamente bloqueia e mata, tornando-a a escolha quando prevenção em nível de kernel é o objetivo e o time investirá em seu modelo de política. Tracee se centra em detecção mais captura forense, a escolha quando reconstruir e analisar ataques importa tanto quanto detectá-los.
Seu relacionamento com o landscape comercial também esclarece as coisas. Falco sustenta a plataforma comercial CNAPP da Sysdig; Tetragon vem da lineagem Cilium/Isovalent agora dentro da Cisco; Tracee vem da Aqua. Em todos os três casos a ferramenta de código aberto é genuinamente usável por conta própria, com o fornecedor oferecendo uma plataforma gerenciada em camadas para times que querem dashboards centralizados, escopo CNAPP mais amplo e suporte. Você pode adotar qualquer uma das três ferramentas de código aberto sem comprar nada, o que é parte de por que esse espaço consolidou ao redor delas.
Um ponto que vale a pena fazer é que essas ferramentas não são estritamente mutuamente exclusivas. Algumas organizações executam Falco para seu ruleset de detecção maduro junto com Tetragon para imposição, aceitando alguma sobreposição em troca de melhor-dos-dois. Mais comumente, porém, times escolhem aquela cujo centro de gravidade corresponde à sua necessidade primária, porque executar múltiplos agentes de instrumentação de kernel tem sua própria sobrecarga e custo operacional.
Uma detecção concreta, três maneiras
Para tornar as diferenças tangíveis, pegue um cenário de ataque comum — um shell reverso iniciado dentro de um contêiner — e veja como cada ferramenta a trata. O comportamento é inequívoco: um processo de contêiner inicia /bin/sh (ou similar) com seus streams padrão cabeados para um socket de rede, um padrão quase nunca visto em workloads contêinerizados legítimos, que típicamente executam um único processo definido.
Com Falco, você teria uma regra combinando "um shell iniciado em um contêiner com uma conexão outbound anexada," e quando o shell reverso inicia, Falco emite um alerta através de seus canais de saída — para stdout, um arquivo, um SIEM ou um pipeline de alerta. A resposta é o que sua ferramenta downstream faz com esse alerta: pague um humano, dispare uma automação, registre para investigação. Falco o viu e disse; agir é trabalho de alguém.
Com Tetragon, você pode fazer a mesma detecção, mas você também pode anexar uma ação de imposição à política. Um TracingPolicy observando esse padrão de exec pode carregar uma ação Sigkill, então no momento em que o processo infrator faz a chamada desabilitada, Tetragon a termina em-kernel — antes do shell ser usável. O ataque não é apenas detectado mas prevenido, sincronamente, sem uma volta para userspace e volta. O trade-off é que você deve estar confiante que a política nunca fará match de um processo legítimo, porque a consequência de um match falso é um workload morto.
Com Tracee, detecção dispara de uma assinatura comportamental, e depois suas capacidades forenses se engajam: pode capturar o binário executado, a memória do processo e o tráfego de rede da conexão para disco. O respondente de incidente chega não apenas a um alerta mas a um conjunto preservado de artefatos — o malware binário real, o tráfego de exfiltração real — pronto para análise. A ênfase é em tornar a investigação pós-detecção tão rica quanto possível.
Mesmo ataque, três filosofias: notifique, previna, ou preserve-para-análise. Nenhuma está errada; elas refletem respostas diferentes à pergunta de o que deveria acontecer no instante em que algo ruim é detectado, e essa pergunta é aquela a responder antes de escolher uma ferramenta.
Escolhendo e implantando
A decisão flui do que você realmente está tentando realizar. Se você quer detecção de ameaça em tempo de execução com a menor fricção e o suporte mais amplo, comece com Falco — é o padrão por boas razões e o mais fácil para staffar e operar. Se sua prioridade é prevenir comportamento ruim no kernel, não apenas ser informado, e você executa Kubernetes onde seu modelo de identidade brilha, escolha Tetragon e orçamento tempo para aprender TracingPolicy e testar imposição cuidadosamente antes de habilitar ações de matar em produção. Se seu trabalho é pesado em resposta de incidente e você precisa capturar e analisar artefatos de um ataque, escolha Tracee por sua captura forense.
Qualquer que você escolha, algumas realidades de implantação se aplicam entre todos os três. Confirme que seus kernels encontram os requisitos, especialmente para recursos de imposição que dependem de LSM e BTF. Comece em uma postura apenas-detecta e ajuste as regras ou assinaturas contra seus workloads reais antes de considerar imposição, porque a maneira mais rápida de perder confiança em uma ferramenta de segurança em tempo de execução é um falso positivo que mata um processo de produção. Cabeie o stream de evento em sua observabilidade existente e SIEM em vez de tratá-lo como uma ilha. E lembre que baixa sobrecarga não é zero sobrecarga em escala extrema — valide o impacto em seus nós de maior throughput. A fundação eBPF torna todos os três dramaticamente mais leves que os agentes que substituíram, mas lançamento disciplinado ainda importa.
A linha de fundo
eBPF reescreveu segurança em tempo de execução dando a ferramentas visibilidade em nível de kernel com segurança verificada e sub-1%-overhead, aposentando os módulos de kernel frágeis e agentes em userspace pesados que vieram antes. As três ferramentas de código aberto que definem o espaço cada uma escolhem um centro de gravidade na mesma fundação: Falco para detecção e alerta maduros, Tetragon para observabilidade e imposição em-kernel, e Tracee para detecção mais captura forense. Corresponda a ferramenta ao seu objetivo primário — detecte, previna ou investigue — implante-a em modo apenas-detecção primeiro, ajuste contra tráfego real, e você obtém proteção que finalmente se encaixa em como sistemas cloud-native realmente executam.
Referências e Recursos
Ferramentas
Fundo e análise
- eBPF Runtime Security Tools 2026: Falco vs Tetragon vs Tracee
- Container Runtime Security 2026 — NomadX
- Open Source CWPP: Falco, Tracee, Tetragon Overview
Cheatsheets relacionados 1337skills