Falco para MSP: deteção em runtime, das pipelines de CI às frotas Kubernetes

As frotas Kubernetes geridas e as pipelines de CI que lhes entregam código são duas superfícies de ataque distintas, e os MSP precisam cada vez mais de uma ferramenta para cada uma. Este guia aborda o Falco, um motor de runtime graduado pela CNCF que transforma comportamento suspeito de contentores numa pipeline de alertas afinada, e o zizmor, um analisador estático que deteta configurações arriscadas do GitHub Actions antes de um workflow sequer correr.

O que é o Falco e o que deteta

O Falco foi criado pela Sysdig e é hoje um projeto graduated da Cloud Native Computing Foundation. Observa as chamadas de sistema através de monitorização baseada em eBPF e sinaliza atividade de processos, ficheiros e rede que pareça anómala dentro de um contentor em execução. Isso torna-o uma forma de apanhar uma intrusão em curso, em vez de a descobrir apenas numa análise pós-incidente.

Sobre o que alertar primeiro

Nem todos os sinais que o Falco pode gerar merecem acordar a equipa de prevenção. Para MSP que gerem muitos tenants, as regras mais importantes combinam uma taxa baixa de falsos positivos com um custo elevado caso sejam ignoradas: uma shell interativa aberta dentro de um contentor de aplicação que nunca deveria precisar de uma, um processo a ler de um caminho de mount sensível como o sistema de ficheiros do host, e alterações de privilégios ou capabilities Linux dentro de um pod em execução. Estes três cobrem a maioria dos cenários em que está mesmo a acontecer algo que preocupa os operadores.

Encaminhar os alertas para que sejam tratados

Uma ferramenta de deteção só ajuda se o alerta chegar a alguém que possa agir. Os eventos do Falco devem trazer contexto suficiente — cluster, namespace, tenant e identidade do pod — para serem encaminhados diretamente para a ferramenta de prevenção ou ITSM do MSP, com um passo de contenção documentado antes de qualquer alerta ser fechado. Afinar as regras conforme a baseline de cada cliente evita a fadiga de alertas: uma shell normal num namespace de um runner de CI não é normal num pod web voltado para clientes.

Onde o Falco para

O Falco é uma camada de deteção, não um sistema de resposta. Não isola uma carga de trabalho, não reverte um deployment nem roda credenciais sozinho; esses passos continuam a exigir um playbook e um responsável humano ou automatizado por trás do alerta. Deve ser tratado como o sensor, não como todo o programa de segurança.

MSP que precisem de ajuda externa para construir esse playbook, ou de prova de um processo de deteção e resposta testado para auditorias NIS2, DORA ou GDPR, podem recorrer aos serviços de cibersegurança da Altovar, que cobrem testes de penetração, avaliação de vulnerabilidades e resposta a incidentes.

Um complemento do lado da CI: o zizmor para o GitHub Actions

O Falco só vê uma carga de trabalho depois de já estar em execução. O zizmor, um analisador estático escrito em Rust, lê ficheiros YAML do GitHub Actions sem os executar, à procura de problemas como actions de terceiros não fixadas a uma versão, permissões demasiado amplas e padrões que podem levar a envenenamento de cache. Pode produzir resultados em formato SARIF, pelo que os achados aparecem diretamente no separador de code scanning do GitHub em vez de num painel à parte.

A versão atual do zizmor, v1.30.1, sucede às correções da v1.30.0 para a correspondência de pins de actions e um crash do parser em expressões de workflow profundamente aninhadas. Do lado do runtime, o Falco 0.45.0 atingiu a versão estável final a 21 de setembro de 2026, após um ciclo de release candidate; as equipas ainda na candidata anterior 0.45.0-rc4 devem passar para a versão estável em vez de manter uma release candidate em produção.

O que fazer

• Ative primeiro as regras predefinidas do Falco para shells interativas, leituras de mounts sensíveis e alterações de privilégios — são os sinais mais claros.
• Associe a cada alerta o cluster, o namespace, o tenant e a identidade do pod, e encaminhe-o para a ferramenta de prevenção ou ITSM já usada pela equipa.
• Execute o zizmor em cada pull request que toque num ficheiro de workflow, e faça o check falhar perante novos achados de gravidade alta.
• Fixe as actions de terceiros a um hash SHA e limite permissions: ao que cada job realmente precisa.
• Implemente o Falco nos clusters de produção primeiro com regras apenas de alerta, e depois aperte rumo ao bloqueio assim que a baseline for compreendida.
• Envie a saída de ambas as ferramentas para a mesma pipeline de alertas usada para outros sinais de segurança, para que nada se perca num painel à parte.

Fontes: Falco no GitHub, documentação do Falco, notas de lançamento do Falco 0.45.0, documentação do zizmor.