Falco para MSP: detección runtime de la CI a las flotas Kubernetes

Las flotas Kubernetes gestionadas y las pipelines de CI que despliegan código en ellas son dos superficies de ataque distintas, y los MSP necesitan cada vez más una herramienta para cada una. Esta guía cubre Falco, un motor runtime graduado por la CNCF que convierte el comportamiento sospechoso de los contenedores en una pipeline de alertas ajustada, y zizmor, un analizador estático que detecta configuraciones arriesgadas de GitHub Actions antes de que un workflow se ejecute.

Qué es Falco y qué detecta

Falco fue creado por Sysdig y hoy es un proyecto graduated de la Cloud Native Computing Foundation. Observa las llamadas al sistema mediante monitorización basada en eBPF y señala actividad de procesos, archivos y red que resulta anómala dentro de un contenedor en ejecución. Eso lo convierte en una forma de detectar una intrusión en curso, en lugar de descubrirla solo en una revisión posterior al incidente.

En qué alertas fijarse primero

No todas las señales que puede generar Falco merecen despertar al equipo de guardia. Para los MSP que gestionan muchos tenants, las reglas más importantes combinan una baja tasa de falsos positivos con un coste alto si se pasan por alto: una shell interactiva abierta dentro de un contenedor de aplicación que nunca debería necesitarla, un proceso que lee desde una ruta de montaje sensible como el sistema de archivos del host, y cambios de privilegios o capabilities de Linux dentro de un pod en ejecución. Estas tres cubren la mayoría de los escenarios en los que realmente está pasando algo que preocupa a los operadores.

Cómo enrutar las alertas para que se atiendan

Una herramienta de detección solo sirve si la alerta llega a alguien que pueda actuar. Los eventos de Falco deberían llevar suficiente contexto — clúster, namespace, tenant e identidad del pod — para enrutarse directamente a la herramienta de guardia o ITSM del MSP, con un paso de contención documentado antes de cerrar cualquier alerta. Ajustar las reglas según la línea base de cada cliente evita la fatiga de alertas: una shell normal en un namespace de un runner de CI no lo es en un pod web de cara al cliente.

Dónde termina Falco

Falco es una capa de detección, no un sistema de respuesta. No aísla una carga de trabajo, no revierte un despliegue ni rota credenciales por sí solo: esos pasos siguen necesitando un playbook y un responsable humano o automatizado detrás de la alerta. Trátalo como el sensor, no como todo el programa de seguridad.

Si necesitas ayuda externa para construir ese playbook, o pruebas de un proceso de detección y respuesta verificado para las auditorías de NIS2, DORA o GDPR, puedes recurrir a los servicios de ciberseguridad de Altovar, que cubren pentesting, evaluación de vulnerabilidades y respuesta a incidentes.

Un complemento del lado de la CI: zizmor para GitHub Actions

Falco solo ve una carga de trabajo cuando ya está en ejecución. zizmor, un analizador estático escrito en Rust, lee los archivos YAML de GitHub Actions sin ejecutarlos, buscando problemas como acciones de terceros sin fijar a una versión, permisos demasiado amplios y patrones que pueden derivar en envenenamiento de caché. Puede generar resultados en formato SARIF, así que los hallazgos aparecen directamente en la pestaña de code scanning de GitHub en lugar de en un panel aparte.

La versión actual de zizmor, v1.30.1, sigue a las correcciones de v1.30.0 para el emparejamiento de pines de acciones y un fallo del parser en expresiones de workflow muy anidadas. En el lado runtime, Falco 0.45.0 alcanzó su versión estable final el 21 de septiembre de 2026 tras un ciclo de release candidate; los equipos que sigan en la anterior 0.45.0-rc4 deberían pasar a la versión estable en lugar de quedarse con una release candidate en producción.

Qué hacer

• Activa primero las reglas por defecto de Falco para shells interactivas, lecturas de mounts sensibles y cambios de privilegios: son las señales más claras.
• Etiqueta cada alerta con clúster, namespace, tenant e identidad del pod, y enrútala a la herramienta de guardia o ITSM que ya use el equipo.
• Ejecuta zizmor en cada pull request que toque un archivo de workflow, y haz fallar la comprobación ante nuevos hallazgos de severidad alta.
• Fija las acciones de terceros a un hash SHA y limita permissions: a lo que cada job realmente necesita.
• Despliega Falco en los clústeres de producción primero con reglas de solo aviso, y luego endurécelas hacia el bloqueo cuando entiendas la línea base.
• Envía la salida de ambas herramientas a la misma pipeline de alertas que usas para otras señales de seguridad, para que nada se pierda en un panel aparte.

Fuentes: Falco en GitHub, documentación de Falco, notas de la versión 0.45.0 de Falco, documentación de zizmor.