O Supply-chain Levels for Software Artifacts (SLSA, pronuncia-se “salsa”) é uma estrutura de segurança desenvolvida pelo Google e hoje mantida pela OpenSSF que define um conjunto graduado de requisitos para proteger a integridade dos artefatos de software ao longo de todo o processo de build e distribuição. O SLSA trata de um vetor de ataque específico e cada vez mais explorado: o comprometimento do software entre o repositório de código-fonte e o artefato de software que chega aos usuários finais, ou seja, o pipeline de build, o repositório de artefatos e o canal de distribuição. Os ataques à cadeia de suprimentos da SolarWinds, do XZ Utils e da 3CX exploraram essa lacuna. O SLSA oferece uma estrutura organizada para fechá-la.
O sistema de níveis do SLSA é a chave conceitual. O SLSA define quatro níveis de garantia progressivamente mais forte sobre a proveniência do software e a integridade do build. O Nível 1 exige que o processo de build gere proveniência, isto é, documentação de como o artefato foi construído. É o nível de entrada e oferece garantia mínima de segurança: a proveniência pode ser forjada, o processo de build não é isolado e nenhuma verificação é exigida. O Nível 2 acrescenta que o serviço de build, e não o desenvolvedor, gera a proveniência, o que a torna mais confiável. O Nível 3 exige que o serviço de build gere uma proveniência que não pode ser forjada pelo desenvolvedor, porque é assinada pelo serviço de build. O Nível 4 acrescenta builds herméticos e reproduzíveis: o build é totalmente isolado da rede, as dependências são totalmente especificadas e as mesmas entradas produzem, de forma verificável, as mesmas saídas.
A importância prática dos níveis do SLSA para TPRM é que alegações de conformidade com o SLSA sem especificação do nível são essencialmente vazias. Um fornecedor em conformidade com o SLSA Nível 1 documentou seu processo de build. Um fornecedor em conformidade com o SLSA Nível 3 tem proveniência de build infalsificável, gerada por um serviço de build isolado. São posturas de segurança significativamente diferentes. A equipe de TPRM que pergunta “vocês estão em conformidade com o SLSA?” e recebe “sim” sem perguntar “em que nível?” obteve uma confirmação que pode descrever qualquer coisa, de um documento de texto sobre o processo de build a um pipeline de build isolado e verificado criptograficamente.
A perspectiva do atacante esclarece por que o nível importa. O ataque à SolarWinds comprometeu o pipeline de build, o processo entre o código-fonte e o artefato compilado. No Nível 1 do SLSA, esse ataque passa em grande parte despercebido: a proveniência é gerada pelo mesmo processo que o atacante controla, e a proveniência forjada reflete o artefato malicioso. No Nível 3 do SLSA, o serviço de build gera proveniência impossível de forjar, de modo que um artefato malicioso que não foi construído pelo serviço de build autenticado não consegue produzir uma proveniência de Nível 3 válida. Quanto mais alto o nível do SLSA, mais o atacante precisa comprometer para produzir um artefato válido com proveniência válida.
A realidade da adoção é o contexto de governança. O Nível 4 do SLSA, o nível de garantia mais alto, é extremamente difícil de alcançar em escala. Muitos dos principais fornecedores de software estão no Nível 1 ou 2. O Nível 3 é alcançável com investimento em infraestrutura de build. O Nível 4 é um compromisso arquitetônico significativo. Para fins de TPRM, a pergunta relevante não é se um fornecedor alcançou o Nível 4, mas se ele está avançando ativamente pelos níveis do SLSA e se seu nível atual é adequado ao risco do software que entrega.
Por que isso importa
O SLSA é importante para TPRM porque os ataques à cadeia de suprimentos de software, especificamente o comprometimento de pipelines de build e da distribuição de artefatos, estão entre os vetores de ataque de maior impacto e mais difíceis de detectar atualmente explorados. A empresa que confirma que um fornecedor está em conformidade com SLSA sem conhecer o nível não confirmou uma garantia significativa de integridade do build. A empresa que entende os níveis do SLSA consegue fazer as perguntas certas e definir expectativas adequadas para o software que implanta.
O raio de impacto a jusante é a preocupação específica da cadeia de suprimentos. Um software comprometido no pipeline de build contém o código do atacante em cada artefato compilado distribuído a cada cliente. Um único comprometimento do pipeline de build atinge todas as empresas que implantam esse software, como a SolarWinds demonstrou em grande escala. Os requisitos dos Níveis 3 e 4 do SLSA tornam esse ataque significativamente mais difícil de executar sem ser detectado.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar a confirmação de conformidade com o SLSA sem perguntar o nível, tratando o SLSA como uma certificação binária, e não como uma estrutura graduada. A segunda falha é não ter um requisito de nível mínimo de SLSA para fornecedores de software críticos, aceitando qualquer nível independentemente do perfil de risco do software.
- SLSA confirmado sem o nível: a pergunta binária sobre conformidade produz uma resposta sem informação
- Nenhum requisito de nível mínimo para fornecedores de software críticos
- SLSA Nível 1 aceito para software de alta criticidade com raio de impacto significativo
- Nenhuma compreensão do que cada nível impede; perspectiva do atacante não aplicada
- Nenhum requisito de progressão no SLSA; não se espera que os fornecedores melhorem ao longo do tempo
Como é uma boa prática
Programas maduros de cadeia de suprimentos de software perguntam especificamente pelo nível SLSA, definem expectativas de nível mínimo proporcionais à criticidade do software e solicitam atestados de proveniência como evidência, em vez de aceitar apenas respostas de questionário.
- Pergunte especificamente pelo nível SLSA, e não pela conformidade binária
- Defina o nível mínimo por criticidade: Nível 2 no mínimo para a maioria dos softwares comerciais, Nível 3 para os críticos
- Solicite um atestado de proveniência como evidência junto com a alegação de nível
- Solicitar o roteiro de SLSA: qual nível o fornecedor pretende atingir e em que prazo
- Verifique com ferramentas a proveniência dos artefatos de software críticos
Ferramentas
Verificação de SLSA: Sigstore/cosign para verificação de proveniência; ferramentas do framework SLSA em slsa.dev
A ferramenta cosign do Sigstore oferece o mecanismo para verificar atestados de proveniência SLSA, confirmando que a alegação de proveniência de um artefato de software é válida e corresponde ao artefato. Para profissionais de TPRM, pedir a um fornecedor o atestado de proveniência SLSA de uma versão específica e verificá-lo com o cosign é o teste prático que confirma se o nível SLSA alegado produz artefatos verificáveis.
Sistemas de build: GitHub Actions com gerador SLSA, Google Cloud Build com suporte a SLSA
As principais plataformas de CI/CD agora incluem a geração de proveniência SLSA como recurso compatível. O gerador SLSA do GitHub Actions produz proveniência compatível com o Nível 3 para builds do GitHub Actions. Em avaliações de TPRM, perguntar se o sistema de build do fornecedor permite a geração de proveniência SLSA e em que nível é uma pergunta específica sobre a infraestrutura de build.
Desafios de governança
O desafio de governança do SLSA em TPRM é a lacuna de conhecimento especializado. O SLSA é um padrão técnico que exige compreensão da infraestrutura de build para ser avaliado de forma significativa. Equipes de TPRM sem conhecimento em segurança de build podem ter dificuldade para avaliar declarações de nível SLSA sem o apoio dos desenvolvedores. A solução de governança é criar um guia de referência dos níveis do SLSA que permita aos analistas de TPRM fazer as perguntas certas e interpretar as respostas adequadamente, complementado por consulta à equipe de desenvolvimento no caso de fornecedores de software críticos.
- Defina requisitos de nível SLSA por nível de criticidade do software
- Solicitar o nível SLSA e o atestado de proveniência, não uma conformidade binária
- Solicitar o roteiro de SLSA aos fornecedores em níveis mais baixos
- Verificar os atestados de proveniência dos artefatos de software críticos
- Desenvolver nos analistas de TPRM a compreensão dos níveis do SLSA: o que cada nível impede
Se você faz parte de uma equipe pequena
Para os seus três fornecedores de software mais críticos, os produtos em que um comprometimento da cadeia de suprimentos seria mais danoso, faça duas perguntas específicas. Primeira: com qual nível SLSA o seu processo de build está em conformidade, e vocês podem fornecer um atestado de proveniência da sua versão mais recente? Segunda: o seu sistema de build está integrado ao Sigstore ou a uma estrutura equivalente de verificação de proveniência, e podemos verificar o atestado de forma independente? Essas duas perguntas dirão muito mais sobre a integridade real do build do que uma confirmação binária de conformidade com o SLSA.
- Perguntar especificamente o nível SLSA dos três fornecedores de software mais críticos
- Solicitar atestado de proveniência de uma versão recente
- Pergunte se a proveniência pode ser verificada de forma independente
- Defina um requisito de nível mínimo de SLSA para software crítico
O que exigir
Pergunte diretamente:
"Em que nível do SLSA seu processo de build está em conformidade, e você pode fornecer um atestado de proveniência verificável da sua versão principal mais recente que confirme que o artefato foi construído a partir do código-fonte declarado por um serviço de build autenticado?"
O que esperar como evidência
- Nível SLSA específico, e não conformidade binária
- Atestado de proveniência de uma versão recente
- Método de verificação do atestado
- Roteiro de SLSA se estiver abaixo do nível desejado
A um fornecedor que confirma conformidade com o SLSA, deve-se perguntar o nível. Conformidade no Nível 1 e conformidade no Nível 3 não oferecem a mesma garantia. O nível determina o que significa a confirmação de conformidade.
Como comprovar
- Requisitos de nível SLSA por criticidade do software
- Registros de atestados de proveniência
- Verificação da proveniência de software crítico
- Acompanhamento do roteiro de SLSA do fornecedor
Principal conclusão
Conformidade com SLSA: confirmada. Nível: 1. O que significa o Nível 1: o processo de build é documentado. O que ele impede: nada que interesse ao atacante. O Nível 1 do SLSA é documentação. O Nível 3 é proveniência impossível de forjar, gerada por um serviço de build isolado. O Nível 4 são builds herméticos e reproduzíveis. O ataque à SolarWinds, que comprometeu o pipeline de build para inserir código malicioso em artefatos assinados, é impedido pelo Nível 3, porque o build malicioso não consegue produzir uma proveniência de Nível 3 válida. O nível determina o que a confirmação de conformidade significa. Perguntas binárias sobre conformidade com SLSA produzem respostas binárias que nada dizem de útil sobre a integridade do build.