O que é a segurança da cadeia de abastecimento de software?

O que é a cadeia de abastecimento de software?

A cadeia de abastecimento de software é tudo e todos os que intervêm para levar o software do editor de um programador até à produção. Pense nela em quatro fases, cada uma com os seus próprios riscos.

Fase	O que inclui	O que corre mal
Código-fonte	O seu código, repositórios e contas de programadores	Credenciais roubadas, commits maliciosos, segredos expostos
Dependências	Pacotes open source, imagens base, código de terceiros	Versões vulneráveis, versões maliciosas, typosquatting
Build	Runners de CI, GitHub Actions, ferramentas de build, caches	Actions comprometidas, caches envenenadas, segredos do pipeline roubados
Lançamento	Artefactos, registos, implementações, atualizações	Artefactos trocados, atualizações adulteradas, nenhum registo do que foi distribuído

Porque é importante agora

A maior parte do que distribui não foi escrita por si. Uma aplicação moderna é maioritariamente open source, e cada dependência direta traz outras que ninguém na sua equipa escolheu. Esses pacotes são executados com os mesmos acessos que o seu próprio código, e os respetivos scripts de instalação podem ser executados dentro do seu pipeline de CI, ao lado dos seus segredos.

O historial dos últimos anos mostra como isso é aproveitado:

• SolarWinds: o build foi comprometido, pelo que uma árvore de código-fonte limpa produziu uma versão envenenada.
• Log4Shell: uma falha numa única biblioteca de registo chegou a produtos que nem sabiam que a usavam.
• xz utils: um colaborador de confiança introduziu uma backdoor num projeto presente em distribuições Linux.
• tj-actions: uma GitHub Action sequestrada executou código do atacante nos pipelines que a usavam, com os segredos ao alcance.
• Shai-Hulud: um worm propagou-se através de pacotes npm, roubando tokens das máquinas e dos jobs de CI que os instalavam.

Para saber como estes ataques funcionam passo a passo, consulte o que é um ataque à cadeia de abastecimento.

Como funciona a segurança da cadeia de abastecimento de software

Um programa precisa de quatro coisas. Tudo o resto é pormenor.

1. Saber o que distribui. Mantenha uma SBOM exata para cada versão, proveniente do build que a produziu, incluindo as dependências transitivas.
2. Controlar o que entra. Fixe as versões, use um lockfile, limite as origens de onde os builds podem obter pacotes e avalie os novos pacotes.
3. Proteger o build. Isole os jobs, limite os segredos, fixe as actions por commit e restrinja o tráfego de saída, para que um pacote comprometido não consiga enviar os seus tokens para lado nenhum. Consulte segurança dos runners e porque é que a segurança da cadeia de abastecimento pertence à CI.
4. Continuar a vigiar o que foi distribuído. As novas vulnerabilidades afetam software já em produção. Monitorize-o, identifique que versões estão afetadas e acompanhe cada correção até uma nova versão.

Para a lista de verificação detalhada, consulte as boas práticas de segurança da cadeia de abastecimento de software.

Referenciais e regulamentos

Nome	O que é	Ideal para
SLSA	Níveis de integridade do build e de proveniência	Reforçar a forma como o software é compilado
NIST SSDF	Práticas de desenvolvimento seguro, SP 800-218	Um programa completo de desenvolvimento seguro
NIST SP 800-161	Gestão do risco de cibersegurança da cadeia de abastecimento	Gestão do risco em toda a organização
OpenSSF Scorecard	Verificações automáticas da saúde de projetos open source	Avaliar dependências
Cyber Resilience Act	Lei da UE para produtos com elementos digitais	Vender na UE. Consulte o que é o CRA

Que ferramentas estão envolvidas?

Nenhum produto cobre tudo isto sozinho. A categoria divide-se em ferramentas de SCA, ferramentas de SBOM, segurança de CI/CD e de runners, firewalls de pacotes, gestão da postura de segurança de aplicações e análise de binários. Para saber o que cada uma faz e quem a vende, consulte ferramentas de segurança da cadeia de abastecimento de software comparadas e quanto custam.

Por onde começar

1. Gere uma SBOM do seu produto mais importante a partir do respetivo build de CI e leia-a.
2. Ative os alertas de vulnerabilidades de dependências e decida quem é responsável por eles.
3. Fixe as suas GitHub Actions por commit e reveja os segredos a que os seus workflows têm acesso.
4. Restrinja o tráfego de saída dos seus builds aos hosts de que realmente precisam.
5. Configure a monitorização do que distribuiu, não apenas do que está a compilar.

Como o CRACI aborda o tema

O CRACI começa no build, porque o build é o único sítio que vê tudo. Substitui os seus runners alojados no GitHub por outros mais rápidos e de custo mais baixo, que registam cada pacote que cada job obtém, a qualquer profundidade da árvore e incluindo pacotes restaurados de caches de CI. A política de egress bloqueia as ligações de que o seu build não precisa, pelo que o protege até contra um ataque que ninguém viu antes. O CRACI continua depois a verificar o que foi distribuído face a novas vulnerabilidades e acompanha cada uma, da triagem até uma versão corrigida. Consulte segurança da cadeia de abastecimento de software com o CRACI.

Segurança da cadeia de abastecimento de software: perguntas frequentes

O que é a segurança da cadeia de abastecimento de software?

É a prática de proteger tudo o que entra no seu software antes de chegar aos utilizadores: dependências open source, sistemas de build, ferramentas do pipeline e versões.

Pode dar um exemplo de ataque à cadeia de abastecimento de software?

No ataque à SolarWinds, o build foi comprometido, pelo que os clientes receberam uma atualização envenenada de um fornecedor de confiança. Nos ataques Shai-Hulud, um worm propagou-se através de pacotes npm e roubou tokens das máquinas que os instalaram.

Qual é a diferença entre segurança da cadeia de abastecimento e segurança aplicacional?

A segurança aplicacional analisa falhas no código que escreve. A segurança da cadeia de abastecimento analisa o que não escreveu e a forma como o seu software é compilado e lançado. Um programa precisa de ambas.

Uma SBOM é suficiente para a segurança da cadeia de abastecimento?

Não. Uma SBOM diz-lhe o que distribui, e essa é a base. Precisa também de controlar o que entra, proteger o build e continuar a monitorizar o que lançou.

Quais são os principais referenciais?

O SLSA para a integridade do build, o NIST SSDF para as práticas de desenvolvimento seguro e o NIST SP 800-161 para a gestão do risco da cadeia de abastecimento. Na UE, o Cyber Resilience Act estabelece requisitos legais para produtos com elementos digitais.

Quem é responsável pela segurança da cadeia de abastecimento de software?

Normalmente, cabe à segurança aplicacional ou de produto, em articulação com as equipas de plataforma e de DevOps que gerem os pipelines. As correções seguem depois para as equipas de engenharia responsáveis por cada serviço.