Lista de verificação de segurança de pipelines de CI/CD

Workflows

• Fixe as actions de terceiros a um SHA de commit completo. Segundo o GitHub, esta é atualmente a única forma de usar uma action como versão imutável. Uma tag pode ser alterada para apontar para outro código. Em março de 2025, a CISA reportou que todas as versões de tj-actions/changed-files estiveram comprometidas durante três dias.
• Dê ao GITHUB_TOKEN o privilégio mínimo. Use por defeito apenas leitura para o conteúdo e conceda mais por job.
• Nunca faça checkout de código não fidedigno em pull_request_target. Estes workflows são executados com segredos e permissões elevadas.
• Mantenha as entradas não fidedignas fora dos scripts. Passe títulos, nomes de branches e outros valores controlados por utilizadores através de uma variável de ambiente, em vez de os expandir num comando de shell.
• Reveja as alterações aos ficheiros de workflow. Exija a revisão por um code owner para .github/workflows.

Segredos

• Prefira credenciais de curta duração. Use OpenID Connect para que os jobs obtenham do seu fornecedor de cloud tokens de curta duração e âmbito limitado, em vez de chaves de longa duração guardadas como segredos.
• Limite os segredos a ambientes. Coloque as credenciais de produção atrás de um ambiente com revisores obrigatórios.
• Faça a rotação dos segredos após um incidente. O conselho da CISA após o comprometimento do tj-actions foi tratar os segredos expostos como comprometidos e fazer a sua rotação de imediato.

Runners

• Use runners efémeros. Uma máquina nova por job não deixa nada para o job seguinte.
• Mantenha os runners self-hosted fora dos repositórios públicos. O GitHub diz que quase nunca devem ser usados nesses repositórios, porque qualquer pessoa pode abrir um pull request contra o repositório.
• Isole os jobs. Um job não deve conseguir ler o espaço de trabalho nem as credenciais de outro job.

Rede

• Controle o egress. Permita as fontes de pacotes e os serviços de que um job precisa e bloqueie o resto, para que uma dependência comprometida não consiga enviar segredos para fora. Como uma política de egress impede a exfiltração
• Registe as ligações. Guarde um traço daquilo a que cada job se ligou, para poder investigar mais tarde.

Dependências

• Faça commit dos lockfiles. Os builds devem resolver sempre as mesmas versões.
• Reveja as novas dependências. Verifique o que um pull request acrescenta antes de ser integrado.
• Condicione os builds às conclusões. Bloqueie um build quando este trouxer um pacote com uma vulnerabilidade crítica conhecida, antes de o artefacto ser distribuído.

Evidências do build

• Registe uma SBOM do que o build obteve. Uma análise posterior dos ficheiros descreve o que foi declarado, não o que o build usou.
• Assine a proveniência. Ligue cada artefacto ao build que o produziu, para poder verificar mais tarde que o que está em execução é o que foi compilado.
• Monitorize o que foi distribuído. Volte a verificar os builds lançados quando são publicadas novas vulnerabilidades.

Que ferramentas cobrem que itens

Os scanners cobrem os itens de dependências, as ferramentas de reforço de pipelines cobrem os itens de workflows, e os agentes no runner ou um runner seguro cobrem os itens de rede e de evidências. O CRACI é o runner: aplica uma política de egress que falha em modo fechado, regista uma SBOM do que cada job obteve, permite que os policy gates bloqueiem um build com base em conclusões e devolve SBOM, traços de rede e proveniência através da sua API. Não analisa código nem workflows. Consulte ferramentas de segurança de CI/CD comparadas para ver que ferramenta cobre o quê.

Segurança de pipelines de CI/CD: perguntas frequentes

O que é a segurança de pipelines de CI/CD?

É a proteção dos sistemas que compilam e distribuem o seu software: as definições dos workflows, os segredos que usam, os runners que os executam, as dependências que descarregam e os artefactos que produzem. Um pipeline comprometido pode distribuir código malicioso em seu nome sem tocar no seu código-fonte.

Porquê fixar as GitHub Actions a um SHA de commit?

As tags podem ser alteradas para apontar para outro código. O GitHub afirma que fixar uma action a um SHA de commit completo é atualmente a única forma de usar uma action como versão imutável. Em março de 2025, a CISA reportou que todas as versões de tj-actions/changed-files estiveram comprometidas durante três dias.

Que permissões deve ter o GITHUB_TOKEN?

O mínimo de que cada job precisa. Defina a predefinição como apenas de leitura para o conteúdo do repositório e conceda mais por job, só onde um job precisar.

Preciso de controlo de egress de rede na CI?

Se os seus jobs têm acesso a segredos e executam código de terceiros, sim. A maioria dos jobs só precisa de chegar a um conjunto conhecido de registos de pacotes e serviços. Uma política de egress bloqueia tudo o resto, pelo que uma dependência comprometida não consegue enviar segredos para o servidor de um atacante.