Durante la mayoría de la última década, la seguridad en tiempo de ejecución significaba un agente. Instalabas software en cada host que se enganchaba en el sistema de alguna manera — un módulo del kernel, una derivación basada en ptrace, un daemon de espacio de usuario analizando logs — y observaba el comportamiento malo. Estos agentes funcionaban, pero tenían un costo: sobrecarga significativa de CPU y memoria, fragilidad entre versiones del kernel, y en el caso de módulos del kernel, el riesgo genuino de bloquear la máquina que suponían proteger. Para 2026 ese modelo ha sido en gran parte desplazado por uno mejor. Extended Berkeley Packet Filter — eBPF — permite que las herramientas de seguridad ejecuten programas sandboxeados dentro del kernel de Linux mismo, observando syscalls, ejecución de procesos, actividad de red y acceso a archivos en la fuente, con sobrecarga medida en fracciones de un por ciento y sin módulos de kernel personalizados para mantener.
Este cambio importa más en entornos nativos de nube, donde las cargas de trabajo son efímeras, los contenedores comparten un kernel, y el modelo antiguo de un agente pesado por host simplemente no encaja. Tres herramientas de código abierto dominan el espacio de seguridad en tiempo de ejecución eBPF, y son genuinamente diferentes en filosofía: Falco, el estándar de detección graduado CNCF; Tetragon, el motor de observabilidad y imposición del proyecto Cilium; y Tracee, la herramienta de detección y forense de Aqua Security. Esta guía explica cómo eBPF cambió el juego, luego compara los tres en detección, imposición, forense y encaje operativo para que puedas elegir deliberadamente.
Por qué eBPF ganó
Para apreciar las tres herramientas, ayuda entender por qué eBPF desplazó tan decisivamente las alternativas. Los enfoques antiguos cada uno tenía un compromiso fatal. Los módulos del kernel daban visibilidad profunda pero se ejecutaban con privilegios completos del kernel y podían entrar en pánico al sistema; un error en tu agente de seguridad se convertía en un pánico del kernel. Los agentes de espacio de usuario eran seguros pero ciegos a mucha actividad a nivel de kernel e imponían sobrecarga del 15-30% en algunas configuraciones por el cambio de contexto constante entre kernel y espacio de usuario. Los enfoques de análisis de logs eran seguros y baratos pero irremediablemente posteriores a los hechos y fáciles de evadir.
eBPF enhebró la aguja. Los programas se ejecutan en el kernel, para que vean todo en la fuente — syscalls, creación de procesos, paquetes de red, aperturas de archivo — pero se ejecutan dentro de una sandbox verificada: el verificador del kernel prueba estáticamente que un programa eBPF no puede bloquear el sistema, entrar en bucle para siempre, o acceder a memoria que no debiera antes de que se le permita cargar. El resultado es visibilidad a nivel de kernel con seguridad a nivel de espacio de usuario, con sobrecarga consistentemente medida por debajo del 1% de CPU. Sin módulos personalizados para compilar por kernel, sin pánicas, sin impuesto de cambio de contexto pesado. Para cargas de trabajo efímeras de densidad alta nativas de nube, esa combinación es exactamente lo que se necesitaba, que es por qué eBPF se convirtió en el predeterminado de seguridad en tiempo de ejecución 2026 en lugar de una opción entre varios.
La captura — y vale la pena establecerlo claramente — es que eBPF requiere un kernel razonablemente moderno, y las características más profundas (como ciertos ganchos de imposición) dependen de capacidades del kernel como soporte de BTF y LSM. En la práctica la mayoría de las distribuciones actuales califican, pero kernels muy antiguos permanecen como una restricción.
Falco: el estándar de detección
Falco es el más establecido de los tres. Creado por Sysdig, donado al CNCF en 2018, y ahora un proyecto graduado, es efectivamente la implementación de referencia de detección de amenazas en tiempo de ejecución basada en eBPF. Su modelo es alertas accionadas por reglas: Falco ingiere el flujo de eventos del kernel vía eBPF y los evalúa contra una biblioteca de reglas escritas en una sintaxis legible basada en YAML, emitiendo alertas cuando el comportamiento coincide con una regla. Una regla podría decir "alerta si un shell se inicia dentro de un contenedor," o "alerta si un proceso escribe en una ruta sensible conocida," u "alerta en una conexión saliente a un destino inesperado."
Las fortalezas de Falco son madurez y ecosistema. El lenguaje de regla es accesible, el conjunto de reglas predeterminado codifica un gran cuerpo de conocimiento comunitario sobre comportamiento sospechoso, y porque es el estándar CNCF, se integra con esencialmente todo — Kubernetes, SIEMs, canalizaciones de alertas, y el panorama más amplio de herramientas nativas de nube. Si tu objetivo es "detectar y alertar sobre comportamiento sospechoso en tiempo de ejecución con una herramienta bien entendida y ampliamente soportada," Falco es el predeterminado seguro y el con el pool más profundo de documentación, reglas y experiencia operativa para extraer.
Su limitación deliberada es que Falco está enfocado en detección. Te dice que algo malo sucedió; no está principalmente diseñado para detenerlo en el kernel. Ese es un alcance razonable — muchos equipos quieren detección alimentando un flujo de trabajo de respuesta en lugar de automatizado en el kernel — pero es la línea donde las otras dos herramientas se diferencian.
Tetragon: observabilidad e imposición en el kernel
Tetragon viene del proyecto Cilium (originalmente Isovalent, ahora parte de Cisco) y aborda la seguridad en tiempo de ejecución desde el ángulo de observabilidad profunda más imposición. Como Falco usa eBPF para observar ejecución de procesos, acceso a archivos, actividad de red y cambios de privilegios, produciendo flujos de eventos ricos y conscientes de Kubernetes. Pero su capacidad definitoria es que puede actuar en el kernel: a través de imposición de gancho LSM, Tetragon es la herramienta eBPF de código abierto con capacidades nativas de bloqueo y eliminación, capaz de terminar un proceso ofensor u anular una syscall sincrónica, en el kernel, en lugar de solo emitir una alerta para que algo reaccione más tarde.
Esto importa porque la brecha entre detección y respuesta es donde ocurre el daño. Una alerta de que un proceso está exfiltrando datos es útil; una política que mata ese proceso en el momento que hace la syscall no permitida es prevención. Las TracingPolicy de Tetragon te permiten declarar exactamente qué comportamientos del kernel observar y qué acción tomar — observar, o imponer señalizando, matando, o retornando un error. Combinado con fuerte contexto de identidad de Kubernetes (los eventos están atados a pods y etiquetas, no solo PIDs), esto hace a Tetragon especialmente fuerte para equipos que quieren tanto visibilidad profunda como la capacidad de imponer política a nivel de kernel. El hoja de referencia de Tetragon cubre el modelo de política en detalle.
El compromiso es peso conceptual. La imposición es poderosa y correspondientemente peligrosa — una política de eliminación imprudente puede derribar cargas de trabajo legítimas — y el modelo TracingPolicy tiene más superficie para aprender que las reglas de Falco. Tetragon recompensa a los equipos listos para invertir en ese modelo con prevención, no solo detección.
Tracee: detección más forense
Tracee, de Aqua Security, ocupa una tercera posición: detección basada en eBPF con un énfasis inusualmente fuerte en forense. Como los otros rastrea eventos del kernel y aplica firmas de comportamiento para marcar técnicas de ataque — anti-depuración, carga de código dinámico, inyección de LD_PRELOAD, escalada de privilegios, escape de contenedor. Donde se distingue es en lo que puede capturar para investigación: Tracee puede capturar binarios ejecutados, regiones de memoria y tráfico de red por evento a disco, dándole a un respondedor de incidentes los artefactos reales de un ataque en lugar de solo una notificación de que uno ocurrió.
Esa captura de forense es el diferenciador. Cuando una detección se dispara, la pregunta es inmediatamente "¿qué exactamente hizo?" — y Tracee está construido para responder eso preservando la evidencia. Su sistema de firma (Go y Rego) es extensible, y su filtrado de evento y ámbito es granular suficiente para enfocarse en exactamente los procesos o contenedores de interés. Para equipos cuya prioridad es no solo saber que un ataque sucedió sino poder reconstruir y analizarlo, las capacidades de captura de Tracee son convincentes. La hoja de referencia de Tracee establece los selectores de evento y opciones de captura.
El posicionamiento de Tracee significa que se superpone con Falco en detección mientras se extiende a forense, y se superpone menos con el enfoque de imposición de Tetragon. Es detección-e-investigación en lugar de detección-y-prevención.
Cómo se comparan
Las tres herramientas se entienden mejor por su centro de gravedad en lugar de una lista de verificación de características, porque todos los tres comparten la base de eBPF y todos los tres detectan comportamiento sospechoso. Falco se centra en detección y alertas, con el ecosistema más profundo y la curva de aprendizaje más suave — la opción estándar cuando quieres detección de amenazas madura y bien soportada alimentando una canalización de respuesta. Tetragon se centra en observabilidad más imposición en el kernel, el único de los tres que bloquea y mata nativamente, haciéndola la opción cuando la prevención a nivel de kernel es el objetivo y el equipo invertirá en su modelo de política. Tracee se centra en detección más captura de forense, la opción cuando reconstruir y analizar ataques importa tanto como detectarlos.
Su relación con el panorama comercial también aclara las cosas. Falco respalda la plataforma comercial CNAPP de Sysdig; Tetragon viene de la línea Cilium/Isovalent ahora dentro de Cisco; Tracee viene de Aqua. En todos los tres casos la herramienta de código abierto es genuinamente usable por su cuenta, con el proveedor ofreciendo una plataforma gestionada en capas arriba para equipos que quieren tableros centralizados, alcance CNAPP más amplio y soporte. Puedes adoptar cualquiera de las tres herramientas de código abierto sin comprar nada, que es parte de por qué este espacio se consolidó alrededor de ellas.
Un punto que vale la pena hacer es que estas herramientas no son estrictamente mutuamente excluyentes. Algunas organizaciones ejecutan Falco por su conjunto de reglas de detección maduro junto a Tetragon por imposición, aceptando algo de solapamiento a cambio de lo mejor de ambos. Más comúnmente, aunque, los equipos eligen la que su centro de gravedad coincide con su necesidad primaria, porque ejecutar múltiples agentes que instrumentan el kernel tiene su propio sobrecarga y costo operativo.
Una detección concreta, tres formas
Para hacer las diferencias tangibles, toma un escenario común de ataque — un shell inverso generado dentro de un contenedor — y ve cómo cada herramienta lo maneja. El comportamiento es inequívoco: un proceso de contenedor genera /bin/sh (o similar) con sus flujos estándar cableados a un socket de red, un patrón casi nunca visto en cargas de trabajo legítimas en contenedor, que típicamente ejecutan un proceso único definido.
Con Falco, tendrías una regla que coincida con "un shell generado en un contenedor con una conexión saliente adjunta," y cuando el shell inverso se lanza, Falco emite una alerta a través de sus canales de salida — a stdout, un archivo, un SIEM, o una canalización de alertas. La respuesta es lo que tu herramienta posterior hace con esa alerta: pagina a un humano, dispara una automatización, log para investigación. Falco lo vio y te lo dijo; actuar es trabajo de otro.
Con Tetragon, puedes hacer la misma detección, pero también puedes adjuntar una acción de imposición a la política. Una TracingPolicy que observa ese patrón de exec puede llevar una acción Sigkill, para que en el momento el proceso ofensor haga la llamada no permitida, Tetragon lo termine en el kernel — antes de que el shell sea usable. El ataque no solo es detectado sino prevenido, sincrónica, sin un viaje de ida y vuelta a espacio de usuario y atrás. El compromiso es que debes estar confiado la política nunca coincidirá con un proceso legítimo, porque la consecuencia de una coincidencia falsa es una carga de trabajo asesinada.
Con Tracee, la detección se dispara desde una firma de comportamiento, y luego sus capacidades de forense se activan: puede capturar el binario ejecutado, la memoria del proceso, y el tráfico de red de la conexión a disco. El respondedor de incidentes llega no solo a una alerta sino a un conjunto preservado de artefactos — el malware binario actual, el tráfico de exfiltración actual — listo para análisis. El énfasis está en hacer la investigación post-detección tan rica como sea posible.
Mismo ataque, tres filosofías: notificar, prevenir, o preservar-para-análisis. Ninguno es incorrecto; reflejan diferentes respuestas a la pregunta de qué debería suceder el instante algo malo es detectado, y esa pregunta es la que responder antes de elegir una herramienta.
Eligiendo e implementando
La decisión fluye de qué estás realmente intentando lograr. Si quieres detección de amenazas en tiempo de ejecución con la menor fricción y el soporte más amplio, comienza con Falco — es el estándar por buenas razones y el más fácil de personal y operar. Si tu prioridad es prevenir comportamiento malo en el kernel, no solo ser dicho sobre ello, y ejecutas Kubernetes donde su modelo de identidad brilla, elige Tetragon e presupuesta tiempo para aprender TracingPolicy y probar cuidadosamente la imposición antes de habilitar acciones de eliminación en producción. Si tu trabajo es respuesta a incidentes-pesado y necesitas capturar y analizar los artefactos de un ataque, elige Tracee por su captura de forense.
Cualquiera que escojas, algunas realidades de implementación aplican a los tres. Confirma tus kernels cumplen los requisitos, especialmente para características de imposición que dependen de LSM y BTF. Comienza en una postura de solo-detección y afina las reglas o firmas contra tus cargas de trabajo reales antes de considerar cualquier imposición, porque la forma más rápida de perder confianza en una herramienta de seguridad en tiempo de ejecución es un falso positivo que mata un proceso de producción. Cableea el flujo de evento en tu observabilidad existente y SIEM en lugar de tratarlo como una isla. Y recuerda que sobrecarga baja no es cero sobrecarga a escala extrema — valida el impacto en tus nodos de mayor throughput. La base de eBPF hace a los tres dramáticamente más ligeros que los agentes que reemplazaron, pero el despliegue disciplinado aún importa.
La conclusión
eBPF rescribió la seguridad en tiempo de ejecución dando herramientas visibilidad a nivel de kernel con seguridad verificada y sub-1%-overhead, retirando los módulos del kernel frágiles y agentes de espacio de usuario pesados que vinieron antes. Las tres herramientas de código abierto que definen el espacio cada una elige un centro de gravedad en la misma base: Falco para detección y alertas maduras, Tetragon para observabilidad e imposición en el kernel, y Tracee para detección más captura de forense. Empareja la herramienta con tu objetivo primario — detectar, prevenir, o investigar — implementa en modo solo-detección primero, afina contra tráfico real, y obtienes protección que finalmente se ajusta a cómo los sistemas nativos de nube realmente se ejecutan.
Referencias y Recursos
Herramientas
Fondo y análisis
- Herramientas de Seguridad en Tiempo de Ejecución eBPF 2026: Falco vs Tetragon vs Tracee
- Seguridad en Tiempo de Ejecución de Contenedor 2026 — NomadX
- CWPP de Código Abierto: Descripción General de Falco, Tracee, Tetragon
Hojas de referencia relacionadas de 1337skills