O Google introduziu a estrutura SLSA (Níveis da cadeia de suprimentos para artefatos de software), que resume a experiência existente na proteção da infraestrutura de desenvolvimento contra ataques realizados na fase de escrita do código, teste, montagem e distribuição de um produto.
Os processos de desenvolvimento estão se tornando cada vez mais complexos e dependentes de ferramentas de terceiros, o que cria condições favoráveis para o avanço de ataques relacionados não à identificação e exploração de vulnerabilidades no produto final, mas ao comprometimento do próprio processo de desenvolvimento (ataques à cadeia de suprimentos, geralmente direcionados a introdução de alterações maliciosas no processo de escrita de código, substituição de componentes distribuídos e dependências).
O framework leva em consideração 8 tipos de ataques relacionados à ameaça de fazer alterações maliciosas na fase de desenvolvimento do código, montagem, teste e distribuição do produto.
- A. Incluindo alterações no código-fonte que contenham backdoors ou erros ocultos que levam a vulnerabilidades.
Exemplo de ataque: “Hypocrite Commits” - uma tentativa de promover patches com vulnerabilidades no kernel Linux.
Método de segurança sugerido: revisão independente de cada alteração por dois desenvolvedores.
- B. Comprometimento da plataforma de controle do código-fonte.
Exemplo de ataque: injeção de commits maliciosos com backdoor no repositório Git de um projeto PHP após o vazamento de senhas de desenvolvedores.
Método de proteção sugerido: Aumento da segurança da plataforma de gerenciamento de códigos (no caso do PHP, o ataque foi realizado através de uma interface HTTPS pouco utilizada, que permitia o envio de alterações ao fazer login com senha sem verificar a chave SSH, apesar o fato de que MD5 não confiável foi usado para hash de senhas).
- C. Fazer alterações na fase de transferência do código para o sistema de construção ou integração contínua (é construído o código que não corresponde ao código do repositório).
Exemplo de ataque: Injetar um backdoor no Webmin fazendo alterações na infraestrutura de construção, resultando no uso de arquivos de código diferentes dos arquivos do repositório.
Método de proteção proposto: Verificação da integridade e identificação da origem do código no servidor assembly.
- D. Comprometimento da plataforma de montagem.
Exemplo de ataque: o ataque SolarWinds, durante o qual foi garantida a instalação de um backdoor no produto SolarWinds Orion durante a fase de montagem.
Método de proteção proposto: implementação de medidas avançadas de segurança para a plataforma de montagem.
- E. Promoção de código malicioso através de dependências de baixa qualidade.
Um exemplo de ataque: a introdução de um backdoor na popular biblioteca de fluxo de eventos adicionando uma dependência inofensiva e depois incluindo código malicioso em uma das atualizações dessa dependência (a alteração maliciosa não foi refletida no repositório git, mas foi presente apenas no pacote MNP finalizado).
Método de proteção sugerido: aplicar recursivamente os requisitos SLSA a todas as dependências (no caso de fluxo de eventos, a verificação revelaria a montagem de código que não corresponde ao conteúdo do repositório Git principal).
- F. Carregando artefatos não criados no sistema CI/CD.
Exemplo de ataque: adição de código malicioso ao script CodeCov, que permitiu que invasores extraíssem informações armazenadas em ambientes de sistemas de integração contínua de clientes.
Método de proteção proposto: controle sobre a origem e integridade dos artefatos (no caso do CodeCov, pode ser revelado que o script Bash Uploader enviado do site codecov.io não corresponde ao código do repositório do projeto).
- G. Comprometimento do repositório de pacotes.
Exemplo de ataque: Os pesquisadores conseguiram implantar espelhos de alguns repositórios de pacotes populares para distribuir pacotes maliciosos por meio deles.
Método de proteção sugerido: Verificação de que os artefatos distribuídos são compilados a partir dos códigos-fonte declarados.
- H. Confundir o usuário ao instalar o pacote errado.
Exemplo de ataque: uso de typosquatting (NPM, RubyGems, PyPI) para colocar pacotes em repositórios que são semelhantes em escrita a aplicativos populares (por exemplo, coffe-script em vez de coffee-script).
Para bloquear as ameaças sinalizadas, o SLSA oferece um conjunto de recomendações, bem como ferramentas para automatizar a criação de metadados de auditoria. SLSA resume métodos de ataque comuns e introduz o conceito de camadas de segurança. Cada nível impõe certos requisitos de infraestrutura para garantir a integridade dos artefatos utilizados no desenvolvimento. Quanto maior o nível de SLSA suportado, mais proteções são implementadas e melhor a infraestrutura fica protegida contra ataques comuns.
- SLSA 1 exige que o processo de construção seja totalmente automatizado e gere metadados (“proveniência”) sobre como os artefatos são construídos, incluindo informações sobre fontes, dependências e o processo de construção (um exemplo de gerador de metadados para auditoria é fornecido para GitHub Actions). O SLSA 1 não inclui elementos de proteção contra modificações maliciosas, mas simplesmente identifica o código e fornece metadados para gerenciamento de vulnerabilidades e análise de riscos.
- SLSA 2 – estende o primeiro nível exigindo o uso de controle de versão e serviços de montagem que geram metadados autenticados. O uso do SLSA 2 permite rastrear a origem do código e evita alterações não autorizadas no código no caso de serviços de construção confiáveis.
- SLSA 3 – confirma que o código fonte e a plataforma de construção atendem aos requisitos dos padrões que garantem a capacidade de auditar o código e garantir a integridade dos metadados fornecidos. Presume-se que os auditores possam certificar plataformas de acordo com os requisitos das normas.
- SLSA 4 é o nível mais alto, complementando os níveis anteriores com os seguintes requisitos:
- Revisão obrigatória de todas as alterações por dois desenvolvedores diferentes.
- Todas as etapas de construção, código e dependências devem ser totalmente declaradas, todas as dependências devem ser extraídas e verificadas separadamente e o processo de construção deve ser executado offline.
- Usar um processo de compilação repetível permite que você mesmo repita o processo de compilação e garanta que o executável seja compilado a partir do código-fonte fornecido.
Fonte: opennet.ru