Supply Chain Security: O que é o SLSA? (Parte I)

1 Uma rápida introdução à cadeia de suprimentos

Recentemente, o “ataque à cadeia de suprimentos de software” tem estado a dar as manchetes de todos os noticiários. Um exemplo infame é o ataque à SolarWinds ou a violação de dados do governo federal dos Estados Unidos em 2020. De fato, de acordo com um relatório do Gartner (feito em 2021, obtenha o relatório aqui):

Até 2025, 45% das organizações em todo o mundo terão sofrido ataques em suas cadeias de suprimentos de software, um aumento de três vezes em relação a 2021.

O que é uma cadeia de suprimentos de software, então?

É qualquer coisa necessária para entregar seu produto nas etapas de criação de artefatos de software.

Pode ser útil pensar na cadeia de suprimentos de um bem físico, como um carro. Uma cadeia de suprimentos para um carro pode incluir coisas como estas:

  • Componentes produzidos internamente, como motores e caixas de câmbio.
  • Componentes de terceiros, como cintos de segurança e faróis.
  • A fábrica, incluindo as instalações, máquinas e ferramentas usadas para construir os componentes e montar o carro.
  • Os trabalhadores que trabalham na unidade de produção.
  • Os processos, como acessar diferentes ferramentas e sistemas, como fazer controle de qualidade, etc.

Para uma cadeia de suprimentos de software, ela contém:

  • Todo o código, incluindo suas dependências, e o software interno e externo que você usa para desenvolver, construir, empacotar, instalar e executar seu software.
  • Sistemas
  • Povo
  • Processos e políticas que contribuem para o desenvolvimento e entrega do seu software, dentro e fora da sua organização, como processos e políticas de acesso a sistemas, teste de software, revisão (tanto de código quanto não-código), monitoramento, comunicação, aprovação, etc.

Mais algumas informações:
- No meu blog anterior, escrevi um artigo sobre SBOM (Software Bill of Materials), que é um componente crítico do gerenciamento da cadeia de suprimentos de software.
- Aqui estão mais alguns glossários.

Agora que esclarecemos a definição da cadeia de suprimentos, vamos ver alguns ataques à cadeia de suprimentos: como e de que maneira eles acontecem.

2 Ataques à cadeia de suprimentos

Dada a complexidade dos produtos e sistemas de software e o amplo alcance da cadeia de suprimentos de software, há inúmeras maneiras de introduzir modificações não autorizadas em pacotes de software em diferentes etapas do ciclo de vida de desenvolvimento de software (SDLC).

Um fluxo de trabalho típico de desenvolvimento de software tem esta aparência:

  • No ponto A do ciclo de vida de desenvolvimento, o código incorreto pode ser enviado ao repositório. Um dos exemplos mais famosos seria o Linux hypocrite commits, onde os pesquisadores tentaram introduzir vulnerabilidades intencionalmente no kernel Linux. Devido à escala de grandes projetos de código aberto, pode ser difícil discriminar entre membros da comunidade com boa ou maliciosa intenção.
  • No ponto D, uma plataforma de compilação comprometida também pode causar problemas. Por exemplo, no ataque SolarWinds mencionado no início deste artigo, os invasores comprometeram a plataforma de compilação e instalaram um implante que injetou comportamento malicioso durante cada compilação.
  • No ponto E, uma dependência prejudicial pode ser usada. Por exemplo, no incidente de vulnerabilidade de fluxo de eventos, os invasores adicionaram uma dependência e, em seguida, atualizaram a dependência para adicionar comportamento mal-intencionado. A dependência prejudicial em si pode ser atacada nos pontos A-H, e as dependências da dependência também podem ser atacadas nos pontos A-H, recursivamente.
  • No ponto F, um artefato não construído pelo sistema CI/CD poderia ser carregado. Por exemplo, no incidente CodeCov, o invasor usou credenciais vazadas para carregar um artefato mal-intencionado e os usuários o baixaram diretamente.

Eu poderia continuar, mas já falei: o desenvolvimento de software e software tem se tornado cada vez mais complicado, e há muitas etapas e aspectos relacionados a elas, e cada passo pode dar errado.

3 Ataques à cadeia de suprimentos: passado e futuro

No passado, os ataques à cadeia de suprimentos de software herdado aconteciam de forma “exploradora”, onde os invasores se aproveitavam de CVEs (Common Vulnerabilities and Exposures) de código aberto não corrigidos divulgados publicamente. Por exemplo, o infame incidente Struts na Equifax.

No entanto, por outro lado, os “ataques” da cadeia de suprimentos de software de próxima geração são muito mais perigosos agora e no futuro, porque os invasores não estão mais esperando por CVEs divulgados publicamente. Em vez disso, eles estão tomando a iniciativa ativamente, injetando código malicioso em projetos de código aberto que alimentam a cadeia de suprimentos global. Ou seja, os bandidos também estão “mudando para a esquerda”, assim como o DevSecOps. Ao mudar seu foco “upstream”, os invasores podem infectar um único componente, que será distribuído “downstream” usando fluxos de trabalho de software legítimos e mecanismos de atualização.

De acordo com o estudo sobre ameaças à segurança no ecossistema npm (PDF) feito por pesquisadores da Universidade de Darmstadt em 2019, “391 mantenedores altamente influentes afetam mais de 10.000 pacotes, tornando-os alvos preferenciais para ataques”. Se um invasor comprometer com êxito projetos suportados por um desses 391 mantenedores, ele poderá ampliar drasticamente o círculo de impacto dos ataques. Por exemplo, a equipe de Darmstadt disse que, se os invasores obtivessem acesso a 20 contas populares de mantenedor npm, eles poderiam implantar código malicioso que afetaria mais da metade do ecossistema. Os riscos aumentam ainda mais porque a Core Infrastructure Initiative da Linux Foundation descobriu que sete dos 10 pacotes de software mais usados estavam hospedados em contas individuais de desenvolvedores. Os pesquisadores então questionaram: “o que acontece se uma dessas contas for hackeada? Você, mais abaixo na cadeia de suprimentos de software, saberia?”

Os ataques de próxima geração são possíveis por alguns motivos:

  • Projetos de código aberto normalmente dependem de centenas — se não milhares — de dependências de outros projetos de código aberto. Projetos de código aberto são muito usados e têm muitas dependências — o que dificulta a avaliação da segurança de cada nova versão de uma dependência. Poucos leem o código-fonte dos aplicativos nos quais confiam; Há muitos deles, suas bases de código são muito grandes, e as chances são de que a maioria das pessoas que lêem o código-fonte não poderia fazer uma análise de segurança adequada de qualquer maneira.
  • O código aberto depende de milhares de contribuidores, e discriminar entre membros da comunidade com boa ou maliciosa intenção é difícil, se possível.
  • O código aberto é construído em uma “rede de confiança”, que pode ser mais segura do que projetos de código fechado, mas ainda cria um ambiente pelo qual os invasores podem atacar.

Os ataques da próxima geração já são ruins o suficiente, mas a má notícia é que eles ainda estão em ascensão. Os ataques direcionados a código aberto aumentaram para 430% desde que o relatório de Darmstadt foi publicado (216 ataques desse tipo registrados de fevereiro de 2015 a junho de 2019, em comparação com 929 registrados de julho de 2019 a maio de 2020).

4 Introdução ao SLSA: Mitigando os problemas de segurança da cadeia de suprimentos

Como melhorar a segurança da cadeia de suprimentos, então?

Embora existam soluções “pontuais” que podem resolver uma ameaça ou vulnerabilidade específica em uma etapa específica da cadeia de suprimentos (ou o SDLC), isso não é suficiente. Falta-nos uma estrutura abrangente de ponta a ponta que governe toda a cadeia de suprimentos em todos os aspectos, defina como mitigar ameaças em toda a cadeia de suprimentos de software e forneça garantias de segurança adequadas.

Entre na estrutura SLSA.

O Supply chain Levels for Software Artifacts, ou SLSA (leia-se: salsa), é inspirado na “Autorização Binária para Borg” interna do Google, que está em uso há 8+ anos e é obrigatória para todas as cargas de trabalho de produção do Google.

O objetivo do SLSA é melhorar o estado da indústria, particularmente de código aberto, para se defender contra as ameaças de integridade mais urgentes.

Para quem é o SLSA, então? Seja você um desenvolvedor, uma empresa ou uma empresa, o SLSA fornece um padrão do setor, um nível reconhecível e acordado de proteção e conformidade.

Em seu estado atual, o SLSA é uma estrutura de segurança, um conjunto de diretrizes de segurança adotáveis incrementalmente sendo estabelecidas por consenso do setor. Considere-a uma lista de verificação de padrões e controles para evitar adulterações, melhorar a integridade e proteger pacotes e infraestrutura em seus projetos, negócios ou empresas. É assim que você passa de “seguro o suficiente” para “ser o mais resiliente possível” em qualquer elo da cadeia de suprimentos de software.

Os padrões estabelecidos pelo SLSA são princípios orientadores para produtores e consumidores de software: os produtores podem seguir as diretrizes para tornar seu software mais seguro e os consumidores podem tomar decisões com base na postura de segurança de um pacote de software.

5 Quatro níveis de segurança do SLSA

O SLSA projetou quatro níveis de segurança, que são incrementais e acionáveis, para proteger contra ataques de integridade específicos. Os níveis de SLSA são como uma linguagem comum para discutir como o software seguro, as cadeias de suprimentos e suas partes são. O SLSA 4 representa o estado final ideal, e os níveis inferiores representam marcos com garantias de integridade correspondentes.

Aqui está uma introdução rápida:

  • SLSA 1: documentação do processo de construção. O processo de compilação deve ser totalmente roteirizado/automatizado e gerar proveniência (os metadados sobre como um artefato foi criado, incluindo o processo de compilação, a origem de nível superior e as dependências). Conhecer a procedência permite que os consumidores de software tomem decisões de segurança baseadas em riscos. A procedência no SLSA 1 não protege contra adulteração, mas oferece um nível básico de identificação do código-fonte e pode ajudar no gerenciamento de vulnerabilidades. O SLSA 1 é fácil de adotar, dando visibilidade à cadeia de suprimentos e sendo capaz de gerar procedência.
  • SLSA 2: resistência à violação do serviço de construção. Ele requer controle de versão e um serviço de compilação hospedado que gera proveniência autenticada. Esses requisitos adicionais dão ao consumidor de software maior confiança na origem do software. Nesse nível, a procedência impede a adulteração na medida em que o serviço de compilação é confiável. O SLSA 2 começa a proteger contra violação de software e adiciona garantias mínimas de integridade de compilação.
  • SLSA 3: resistência extra a ameaças específicas. As plataformas de origem e construção atendem a padrões específicos para garantir a auditabilidade da fonte e a integridade da procedência, respectivamente. Prevemos um processo de acreditação em que os auditores certificam que as plataformas atendem aos requisitos nos quais os consumidores podem confiar. O SLSA 3 fornece proteções muito mais robustas contra adulteração do que os níveis anteriores, evitando classes específicas de ameaças, como a contaminação entre construções. O SLSA 3 protege a infraestrutura contra ataques, e mais confiança é integrada a sistemas complexos.
  • SLSA 4: o mais alto nível de confiança e confiança. Requer uma revisão de duas pessoas de todas as alterações e um processo de construção hermético e reproduzível. A revisão em duas pessoas é uma prática recomendada do setor para detectar erros e dissuadir comportamentos prejudiciais. As construções herméticas garantem que a lista de dependências da proveniência esteja completa. Embora não sejam estritamente necessárias, as compilações reprodutíveis oferecem muitos benefícios de auditabilidade e confiabilidade. No geral, o SLSA 4 dá ao consumidor a confiança de que o software não foi adulterado. SLSA 4, as mais altas garantias de integridade de construção, medidas para gerenciamento de dependência estão em vigor.

Nota: às vezes também falamos sobre SLSA 0, com o nível 0 significando que não há garantia. SLSA 0 representa a ausência de qualquer nível de SLSA.

Também vale a pena notar que o nível SLSA, por design, não é transitivo para tornar o problema tratável. Isso torna a classificação SLSA de cada artefato independente uma da outra, permitindo progresso paralelo e priorização com base no risco (se o SLSA 4 exigisse dependências para ser SLSA 4, teríamos que fazer todas as dependências SLSA 4, que podem não ser de alto risco, portanto, não são de alta prioridade). O nível descreve as proteções de integridade do processo de compilação de um artefato e da origem de nível superior, mas nada sobre as dependências do artefato. As dependências têm classificações SLSA e um artefato SLSA 4 pode ser criado a partir de dependências SLSA 0.

Embora, para a maioria dos projetos, alcançar o mais alto nível de segurança do SLSA possa ser difícil e levar anos, vale a pena mencionar que as melhorias incrementais e marcos intermediários reconhecidos por níveis mais baixos de SLSA também são essenciais e já ajudarão muito a melhorar a segurança do ecossistema.

6 Como o SLSA ajuda

O SLSA ajuda a proteger contra ataques comuns à cadeia de suprimentos. Vamos rever alguns dos exemplos mencionados na seção 2 e ver como o SLSA pode ajudar:

O hipócrita do Linux comete é onde os pesquisadores tentaram introduzir intencionalmente vulnerabilidades no kernel do Linux por meio de patches na lista de discussão. O princípio de revisão de duas pessoas do SLSA 4 poderia mitigar isso. A revisão de duas pessoas pode detectar a maioria (mas não todas) das vulnerabilidades.

O ataque do SolarWinds aconteceu por causa da plataforma de compilação comprometida, que pode ser mitigada pela regra de ambiente efêmero do SLSA 3, que garante que cada ambiente de compilação seja efêmero, sem nenhuma maneira de persistir alterações entre compilações subsequentes. Além disso, o SLSA 3 requer controles de segurança mais fortes para a plataforma de compilação, tornando mais difícil comprometer e ganhar persistência.

No incidente do CodeCov, o invasor carregou um artefato malicioso. Isso pode ser atenuado pelo SLSA 1 e 2: o SLSA 1 requer procedência mostrando que o pacote veio do pipeline de CI/CD esperado e proveniência com um ‘assunto’ correspondente ao hash do pacote; O SLSA 2 aceita proveniência que foi assinada criptograficamente pela chave pública correspondente a um construtor aceitável. Se o SLSA fosse aplicado no caso CodeCov, a procedência do artefato teria mostrado que o artefato não foi construído de forma esperada a partir do repositório de origem esperado.

7 Resumo

O SLSA é uma estrutura prática para a integridade da cadeia de suprimentos de software de ponta a ponta com base em um modelo que comprovadamente funciona no Google. Ele orienta você a melhorar gradualmente a segurança do seu software. Os artefatos usados em infraestrutura crítica ou operações vitais de negócios podem querer atingir um nível mais alto de segurança, enquanto o software que representa um baixo risco pode parar quando estiver confortável.

O SLSA foi projetado para ser incremental e acionável e fornecer benefícios de segurança em todas as etapas. Uma vez que um artefato se qualifica no mais alto nível, os consumidores podem ter confiança de que ele não foi adulterado e pode ser rastreado com segurança até a origem – algo que é difícil, se não impossível, de fazer com a maioria dos softwares atuais.

Em sua encarnação atual, o SLSA não é mais do que um conjunto de diretrizes, mas vale a pena mencionar que, no estado final do SLSA, ele não será mais apenas uma lista de melhores práticas; seu forte ponto forte reside na aplicabilidade: o SLSA apoiará a criação automática de metadados auditáveis que podem ser alimentados em mecanismos de políticas para dar “certificação SLSA” a um pacote ou plataforma de compilação em particular.

No artigo a seguir da série, veremos a ferramenta, que oferece suporte à assinatura, verificação e armazenamento de contêiner em um registro OCI. A Cosign tem como objetivo tornar as assinaturas invisíveis na infraestrutura. Fique atento e até a matéria a seguir!sigstore/cosign

Autor: Tiexin Guo

Artigo Original