Segurança de CI/CD

Porque é que os pipelines são um alvo

• Guardam as chaves. Credenciais de cloud, tokens de registos e chaves de assinatura passam todos pela CI.
• Executam código de terceiros. Todas as dependências, scripts de instalação e actions de terceiros são executados no runner.
• Chegam à produção. Tudo o que sai do pipeline é considerado fiável, assinado e distribuído. Um atacante no build chega a todos os clientes de uma só vez.
• Poucos os vigiam. Os ficheiros de workflow mudam raramente e são menos revistos do que o código das aplicações.

O comprometimento do tj-actions e o worm npm Shai-Hulud visaram ambos segredos na CI. Consulte o que é um ataque à cadeia de abastecimento para ver como estes ataques se desenrolam.

Os principais riscos de segurança de CI/CD

O OWASP Top 10 CI/CD Security Risks é a referência habitual. Agrupados pelo que corre mal:

Área	Riscos OWASP	Como se manifesta
Quem pode alterar o quê	Controlo de fluxo insuficiente, gestão de identidades e acessos inadequada	O código chega à produção sem revisão, ou contas antigas mantêm os seus acessos
O que é executado no pipeline	Abuso da cadeia de dependências, execução de pipeline envenenado	Um pacote malicioso ou um workflow alterado é executado com os acessos do job
O que um job pode alcançar	Controlos de acesso insuficientes ao nível do pipeline, higiene insuficiente de credenciais	Um job consegue ler todos os segredos, e os tokens duram anos
Como está configurado	Configuração insegura de sistemas, utilização não controlada de serviços de terceiros	Runners sem correções, e integrações com mais acessos do que precisam
O que consegue provar	Validação incorreta da integridade de artefactos, registo e visibilidade insuficientes	Ninguém sabe dizer o que entrou numa versão nem a que se ligou um job

Para cada risco associado aos controlos dos runners, consulte segurança dos runners comparada.

Boas práticas de segurança de CI/CD

1. Trate as definições de pipelines como código de produção. Exija revisão dos ficheiros de workflow e mantenha os pull requests não fiáveis longe dos segredos.
2. Limite o que cada job pode fazer. Dê aos tokens as permissões mínimas de que precisam e prefira credenciais de curta duração a segredos armazenados.
3. Fixe as actions de terceiros a um hash de commit. As tags podem ser movidas para outro código.
4. Isole os jobs. Execute cada job num ambiente novo, para que nada transite para o seguinte.
5. Controle o tráfego de saída. Um build precisa de origens conhecidas e de destinos conhecidos. Bloquear tudo o resto impede que os segredos roubados saiam. Consulte política de egress do GitHub Actions.
6. Registe o que aconteceu. Guarde uma SBOM de cada build e um registo da sua atividade de rede, para poder responder a perguntas mais tarde.

Para a versão passo a passo, consulte a lista de verificação de segurança de pipelines de CI/CD.

Tipos de ferramentas de segurança de CI/CD

Tipo	O que faz	Exemplos
Segurança dos runners	Isola os jobs e controla o que podem alcançar durante a execução	CRACI, StepSecurity
Gestão de postura	Encontra definições de risco em pipelines e repositórios	Legit Security, Cycode, Apiiro, OX Security
Análise de código e de dependências	Verifica o código, as dependências e os segredos em cada alteração	GitHub Advanced Security, Snyk, Semgrep
SBOM e evidências	Regista o que entrou em cada versão	CRACI, Syft, Anchore

Estas ferramentas atuam em fases diferentes, pelo que a maioria das equipas as combina. Um scanner analisa os ficheiros antes do build, as ferramentas de postura analisam as definições e a segurança dos runners atua durante a execução do job, que é quando um pacote malicioso age. Consulte ferramentas de segurança da cadeia de abastecimento de software comparadas e ferramentas de DevSecOps comparadas.

Onde o CRACI se enquadra

O CRACI protege o build durante a sua execução. Substitui os seus runners alojados no GitHub por outros mais rápidos e de menor custo: cada job é executado na sua própria máquina virtual isolada, uma política de egress bloqueia as ligações de que o build não precisa e cada pacote que o job obtém entra numa SBOM. Como a política permite apenas aquilo de que o build precisa, protege-o mesmo contra um ataque que ninguém viu antes.

O CRACI não verifica a configuração dos seus workflows, não analisa código-fonte nem segredos e não assina proveniência, pelo que deve manter ou acrescentar ferramentas para isso. O GitHub Actions é hoje o sistema de CI suportado, e outros sistemas de CI estão no roadmap.

Segurança de CI/CD: perguntas frequentes

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

É a prática de proteger os pipelines que compilam, testam e distribuem software, incluindo as suas credenciais, o código que executam e os artefactos que produzem.

Quais são os maiores riscos de segurança de CI/CD?

Dependências e actions de terceiros maliciosas, pipelines envenenados, tokens com permissões excessivas e segredos de longa duração, e falta de visibilidade sobre o que um build fez. O OWASP Top 10 CI/CD Security Risks é a lista de referência.

O que é a execução de pipeline envenenado?

Um atacante altera o que um pipeline executa, por exemplo ao editar através de um pull request um ficheiro de workflow ou um script que este chama, para que o seu código seja executado com os acessos do pipeline.

Como proteger um pipeline de CI/CD?

Reveja as alterações aos pipelines, dê a cada job os acessos mínimos de que precisa, fixe as actions de terceiros por hash de commit, isole os jobs, restrinja o tráfego de saída e mantenha um registo do que cada build fez.

Qual é a diferença entre segurança de CI/CD e DevSecOps?

DevSecOps é a prática mais ampla de integrar a segurança na forma como o software é desenvolvido. A segurança de CI/CD centra-se no próprio pipeline, do qual as ferramentas de DevSecOps também dependem.

O GitHub Actions precisa de segurança adicional?

O GitHub disponibiliza controlos como as permissões de tokens e a deteção de segredos, mas tem de os configurar, e os runners alojados não restringem o tráfego de saída por predefinição. A maioria das equipas acrescenta fixação de versões, regras de revisão e controlos nos runners.