Travar a exfiltração a partir do GitHub Actions com uma política de egress

Como os segredos saem de um job de CI

Um job tem acesso ao token do repositório, aos segredos que lhe são passados e a quaisquer credenciais de cloud que assuma. O código executado no job consegue lê-los. Depois, pode fazê-los sair de algumas formas:

• Pela rede. Um pedido a um servidor controlado pelo atacante. É este o canal que uma política de egress fecha.
• Através dos logs. Imprimir segredos, muitas vezes codificados, no log do job. Em março de 2025, a CISA reportou que a action comprometida tj-actions/changed-files expôs segredos desta forma.
• Através das saídas. Artefactos, caches ou commits enviados com o token do job.

O código não tem de ser um pacote malicioso. Um agente de IA no workflow pode ser desviado por prompt injection escondida num issue ou pull request, e depois usar os mesmos canais.

O que faz uma política de egress

A maioria dos jobs precisa de chegar a uma lista curta de destinos: registos de pacotes, registos de contentores, hosts de código-fonte e alguns serviços. Uma política de egress permite essa lista e bloqueia tudo o resto. Com uma política de negação por defeito, um pedido a um host desconhecido falha e os segredos ficam no job.

Não fecha todas as portas:

• Não impede que os segredos sejam impressos nos logs. Mantenha os logs privados e fixe as actions a SHA de commit.
• Um destino que permita pode, ainda assim, levar dados para fora, por isso mantenha a lista de permissões restrita.
• Não lhe diz que pacotes eram maliciosos. Essa é a função da avaliação de pacotes e de uma SBOM.

Três formas de a aplicar

• Um agente no runner. O StepSecurity Harden-Runner é adicionado como primeiro passo de um job. Associa cada ligação ao passo que a fez, constrói uma linha de base em modo de auditoria e bloqueia o egress para tudo o que esteja fora de uma lista de permissões.
• Um runner com política integrada. O CRACI aplica a política como o próprio runner. Outros fornecedores de runners também oferecem controlos de rede, como a filtragem de egress nos runners Linux do Depot e as políticas de egress de bloqueio ou consultivas do Namespace.
• A sua própria rede. Runners alojados por si atrás de uma firewall ou proxy que configura e mantém.

Implementar sem partir os builds

1. Observar. Registe cada ligação que um job faz ao longo de algumas execuções.
2. Permitir. Construa a lista de permissões a partir daquilo de que o job realmente precisa.
3. Bloquear. Mude para negação por defeito e esteja atento às violações.
4. Rever. Trate cada nova violação como uma origem em falta ou como um incidente.

Como o CRACI o faz

No CRACI, a política de egress faz parte do runner. É validada antes de o job começar, os campos desconhecidos são rejeitados e falha em modo fechado. As predefinições integradas cobrem as origens de pacotes comuns, e as origens e ligações personalizadas acrescentam o resto. O traço do job lista cada ligação, e cada ligação bloqueada como uma violação com o respetivo motivo. Como o proxy reconhece pacotes, o mesmo registo torna-se a SBOM do job. A API devolve SBOM, traços de rede e proveniência.

O CRACI ainda não tem um modo de auditoria dedicado; está no roadmap. Sem uma política de rede, o tráfego de um job é permitido e registado no traço, pelo que pode ver do que uma política precisa antes de a aplicar. O CRACI executa jobs de GitHub Actions em Linux. Consulte ferramentas de segurança de CI/CD comparadas e CRACI vs StepSecurity.

Políticas de egress na CI: perguntas frequentes

O que é uma política de egress na CI?

Um conjunto de regras para as ligações de rede de saída que um job de CI pode fazer. O job consegue chegar aos registos de pacotes e serviços de que precisa, e todos os outros destinos são bloqueados.

Uma política de egress teria travado o comprometimento do tj-actions?

Não por si só. Nesse caso, a CISA reportou que os segredos foram expostos através dos logs dos workflows, e não enviados para um servidor externo. Uma política de egress fecha o canal de rede; fixar as actions a SHA de commit e manter os logs privados resolve o canal dos logs.

Bloquear o egress parte os builds?

Pode partir, se a política deixar de fora uma origem de que o build precisa. Comece por registar a que se liga o job, construa a lista de permissões a partir daí e só depois bloqueie. No CRACI, as predefinições integradas cobrem as origens de pacotes comuns, e uma ligação bloqueada surge no traço do job com o motivo.

Posso usar uma política de egress em runners alojados no GitHub?

Sim, com um agente adicionado ao job, como o StepSecurity Harden-Runner. Ou mova o job para um runner que aplique ele próprio a política, como o CRACI.