Boas práticas de segurança da cadeia de abastecimento de software

Código-fonte

• Exija autenticação forte. Use autenticação multifator em todas as contas de alojamento de código.
• Proteja o branch principal. Exija revisão antes do merge e não deixe ninguém fazer push diretamente para um branch de lançamento.
• Mantenha os segredos fora do código. Procure-os em cada push e faça a rotação de tudo o que tenha ficado exposto.
• Trate os ficheiros de workflow como código. Uma alteração a um pipeline pode chegar aos seus segredos, por isso exija a revisão pelos responsáveis.

Dependências

• Inclua um lockfile no repositório e instale a partir dele. Use npm ci e os seus equivalentes, para que os builds não adotem novas versões por acidente. Um lockfile tem limites, mas é por aí que se começa.
• Acrescente um período de espera para novas versões. As versões maliciosas são muitas vezes detetadas pouco depois de surgirem, pelo que não adotar uma versão no dia em que é publicada dá margem para que isso aconteça.
• Limite os scripts de instalação. Desative-os sempre que possível. Os scripts executados na instalação são a forma como os worms de npm se propagam.
• Avalie as novas dependências. Verifique se o nome indicia typosquatting e analise a manutenção e a popularidade. O OpenSSF Scorecard automatiza parte deste trabalho.
• Proteja os nomes dos pacotes internos. Use scopes e a configuração do registo, para que um pacote público não possa ocupar o lugar de um interno através de confusão de dependências.
• Elimine aquilo de que não precisa. Cada dependência é mais uma coisa a monitorizar.

Build e CI/CD

• Fixe as GitHub Actions num hash de commit completo. As tags podem ser movidas, como mostrou o comprometimento do tj-actions.
• Limite o que cada job pode fazer. Dê ao token do workflow a permissão mínima de que precisa e use credenciais de curta duração em vez de segredos de longa duração.
• Restrinja o tráfego de saída. Um build precisa de pacotes de fontes conhecidas e publica em locais conhecidos. Bloqueie tudo o resto, e os segredos roubados ficam sem ter para onde ir. Consulte política de egress do GitHub Actions.
• Execute cada job num ambiente novo e isolado. Nada deve transitar de um job para o seguinte, muito menos de um pull request de um contribuidor externo.
• Trate as caches como uma entrada. Uma cache envenenada sobrevive entre builds, e o que ela restaura passa facilmente despercebido. Consulte cache do GitHub Actions.

Para a lista completa, consulte a lista de verificação de segurança de pipelines de CI/CD e como se compara a segurança dos runners.

Lançamento

• Gere uma SBOM para cada versão, a partir do build. Guarde-a com o artefacto. Consulte boas práticas de SBOM.
• Assine os artefactos e publique a proveniência. Os consumidores podem assim verificar de onde veio uma versão. O SLSA define os níveis.
• Compile as versões apenas na CI. Uma versão feita num portátil não tem por trás nenhum registo fiável.
• Use um único artefacto, do teste à produção. Promova o que testou em vez de o recompilar, para que o registo continue a ser verdadeiro.

Após o lançamento

• Monitorize o que distribuiu. Continue a verificar as SBOM das versões suportadas face a novas vulnerabilidades.
• Priorize com mais do que o CVSS. Use o CISA KEV, o EPSS e o contexto. Consulte como priorizar vulnerabilidades.
• Saiba durante quanto tempo esteve exposto. O histórico de builds mostra que versões continham um pacote, e desde quando.
• Tenha um plano antes de precisar dele. Decida quem faz a triagem, quem corrige e quem fala com os clientes. Consulte o ciclo de vida da gestão de vulnerabilidades.
• Treine com um cenário real. Pergunte quanto tempo levaria a encontrar todas as versões com um determinado pacote. Se a resposta for dias, comece por aí.

O que fazer primeiro

Quando	O que fazer
Esta semana	Autenticação multifator, lockfiles na CI, GitHub Actions fixadas, tokens de workflow com privilégio mínimo
Este mês	SBOM de cada build de lançamento, alertas de dependências com um responsável, deteção de segredos
Este trimestre	Regras de tráfego de saída para builds, monitorização das versões distribuídas, um plano de resposta testado
A seguir	Proveniência assinada, uma revisão formal da cobertura do SLSA ou do NIST SSDF, SBOM de fornecedores

Quais destas práticas o CRACI cobre

O CRACI cobre o build e tudo o que vem depois. Como seu runner de GitHub Actions, executa cada job na sua própria máquina virtual isolada, regista numa SBOM cada pacote que o job obtém, assinala os pacotes restaurados de caches de CI e aplica uma política de egress que bloqueia as ligações de que o seu build não precisa. Depois, continua a verificar o que foi distribuído, mostra que builds continham um pacote vulnerável e pode bloquear builds com policy gates.

O resto fica com as suas outras ferramentas: o CRACI não analisa código-fonte nem segredos, não deteta novos pacotes maliciosos pelo comportamento e não assina SBOM nem proveniência. Consulte ferramentas de segurança da cadeia de abastecimento de software comparadas para saber o que preenche cada lacuna.

Boas práticas de segurança da cadeia de abastecimento: perguntas frequentes

Como proteger uma cadeia de abastecimento de software?

Saiba o que distribui com uma SBOM de cada build de lançamento, controle o que entra com lockfiles e avaliação, proteja o build limitando os segredos e o tráfego de saída, e continue a monitorizar o que lançou.

O que deve fazer primeiro uma equipa pequena?

Ativar a autenticação multifator, instalar a partir de lockfiles na CI, fixar as GitHub Actions em hashes de commit e dar aos tokens de workflow a permissão mínima de que precisam. Estes passos demoram dias e fecham caminhos de ataque comuns.

Como evitar pacotes maliciosos?

Nenhum passo isolado o consegue. Adie a adoção de novas versões, limite os scripts de instalação e avalie as novas dependências. Restringir o tráfego de saída dos builds limita os danos se um pacote malicioso passar.

Porquê fixar as GitHub Actions num hash de commit?

Porque uma tag de versão pode ser movida para código diferente. Um hash de commit completo refere-se sempre ao mesmo código, pelo que uma tag sequestrada não chega ao seu pipeline.

Com que frequência deve rever a sua cadeia de abastecimento?

A monitorização deve ser contínua. Reveja a sua política de dependências, as permissões dos workflows e o plano de resposta pelo menos uma vez por ano e após qualquer incidente na sua stack.