O que você precisa fazer para atingir os níveis de SLSA – um guia muito prático

BACKGROUND

SLSA (Níveis da cadeia de suprimentos para artefatos de software) é uma estrutura de segurança que visa prevenir adulterações, melhorar a integridade e proteger pacotes e infraestrutura. O conceito central do SLSA é que um artefato de software só pode ser confiável se atender a três requisitos:

1. O artefato deverá possuir documento de procedência descrevendo sua origem e processo de construção (L1).
2. O documento de proveniência deve ser confiável e verificado a jusante (L2).
3. O sistema de construção deve ser confiável (L3).

A estrutura SLSA define níveis, que representam o quão segura é a cadeia de fornecimento de software. Estes níveis correspondem ao nível de implementação destes requisitos (indicados como L1-L3 acima).

Escriba valint slsa O comando pode ser usado para produzir documentos de proveniência. A seguir, descrevemos como atingir os níveis de SLSA usando esta ferramenta.

Nota: Referimo-nos aqui à estrutura SLSA V1.0.

SLSA L1

O requisitos para SLSA L1 incluem:

• Os produtores de software seguem um processo de construção consistente.
• A plataforma de construção gera automaticamente dados de proveniência que descrevem como o artefato foi construído.
• Os produtores de software distribuem dados de proveniência aos consumidores.

Lista de verificação para alcançar SLSA L1:

• Construa seu software usando um sistema CI. De preferência, use um script de construção com controle de origem.
• Ative o valint slsa comando como parte de seu script de construção para criar um documento de proveniência. Observe que o valint slsa  O comando permite adicionar informações adicionais ao documento de proveniência – você pode adaptar o conteúdo do documento de proveniência às suas necessidades.

SLSA L2

O requisitos para SLSA L2 incluem:

• Os requisitos SLSA L1.
• A construção é executada em uma plataforma de construção hospedada que gera e assina a própria procedência.
• A verificação a jusante da proveniência inclui a validação da autenticidade da proveniência.

Lista de verificação para alcançar SLSA L2:

• A lista de verificação SLSA L1.
• Use um serviço de compilação hospedado (em vez de executar a compilação na máquina do desenvolvedor).
• Crie um documento de proveniência assinado (em vez de um não assinado, o que é suficiente para SLSA L1). Isso pode ser feito executando valint slsa ... -o attest. Escriba valente a ferramenta possui um amplo conjunto de recursos de assinatura; para uma empresa, recomendamos o uso de chaves e certificados PKI X.509. 
• Verifique a autenticidade do documento de proveniência a jusante utilizando o valint verifycomando. A verificação pode incluir assinatura e assinatura de identidade, bem como outras regras de verificação que garantam o conteúdo do documento de proveniência SLSA. Alguns exemplos podem ser encontrados no livro do Scribe catálogo de políticas.

Nota: A verificação deverá ser feita pelo consumidor do software construído; para conformidade interna, a verificação pode ser feita como parte de um pipeline de testes.

SLSA L3

Requisitos SLSA L3

O requisitos para SLSA L3 incluem:

• Os requisitos SLSA L2.
• A plataforma Build implementa controles fortes para:
  • Evite que as execuções influenciem umas às outras, mesmo dentro do mesmo projeto.
  • Evite que os segredos usados ​​para assinar a procedência sejam acessíveis nas etapas de criação definidas pelo usuário.

Além disso, para confiar na plataforma de construção, é necessário verifique a plataforma de construção. A plataforma de construção deve ser confiável no sentido de que o documento de proveniência será infalsificável e a construção será isolado. Tal verificação deriva dos seguintes requisitos:

• Verifique se o uso da plataforma não quebra a impossibilidade de forjabilidade e o isolamento .
  • A verificação do isolamento, por exemplo, pode ser feita avaliando o uso de cache no pipeline.
  • Para garantir a impossibilidade de falsificação do documento de proveniência, recomendamos gerá-lo e assiná-lo em um pipeline de construção dedicado.
• Verifique o confiabilidade da plataforma de construção.
  •  Para ICs SaaS, uma verificação deve ser feita com o fornecedor da plataforma de construção. Nos casos em que o produtor de software é responsável pela implantação do sistema de construção, recomenda-se uma combinação de auto-atestado do fornecedor e realização de uma análise dos aspectos de implantação.
  • Por exemplo, ao implantar um CI auto-hospedado, o atestado do fornecedor deve declarar como as construções são isoladas umas das outras, e a análise de implantação deve verificar as permissões de acesso e a auditoria de log do sistema de CI.

Esses requisitos são desafiadores porque satisfazê-los depende da plataforma de CI, não pode ser totalmente automatizado e requer uma análise de segurança profissional dos sistemas de construção e pipelines. É por isso que a estrutura SLSA sugere especificamente que as organizações evoluam gradualmente da conformidade com SLSA L2 para SLSA L3.

Se você leu este artigo até aqui e decidiu que SLSA L3 é a coisa certa para você, arregace as mangas – aqui está nossa recomendação para uma lista de verificação:

Lista de verificação para alcançar SLSA L3:

• A lista de verificação SLSA L2.
• Avalie o sistema CI. O objetivo é responder às seguintes questões:
  • Sob quais condições uma entidade não autorizada pode escapar do sistema de construção?
  • Sob quais condições as construções podem afetar umas às outras?

Uma vez respondida – gerencie os riscos restantes.

• Isole a geração do documento de Procedência:
  • Separe a criação do documento de proveniência para um pipeline diferente, de preferência em um serviço de build separado.
    • Expor a este pipeline apenas os segredos utilizados para assinatura do documento de Procedência.
    • Crie ou verifique o conteúdo do documento de proveniência neste pipeline. No caso de verificação, verifique todos os campos possíveis de um documento de proveniência gerado no pipeline com dados coletados diretamente da plataforma de construção ou de outras fontes confiáveis.
• Isole e verifique o isolamento do pipeline de build de outras execuções de pipeline:
  • Verifique o uso de caches e volumes compartilhados.
  • Verifique se os segredos partilhados com outros pipelines não podem permitir que os pipelines afetem uns aos outros.
  • Verifique se as execuções do pipeline não podem afetar umas às outras
    • Por exemplo, evite que instalações feitas através de um pipeline afetem outras execuções de pipeline. Isso pode ser feito usando executores de build efêmeros (como um contêiner criado para cada build) ou verificando se os executores de build iniciam sempre a partir de um estado predeterminado.

Para obter SLSA L3 com ferramentas Scribe, recomendamos o seguinte:

• Instrumente o pipeline de construção para gerar todos os atestados que serão necessários para preencher o documento de proveniência. Por exemplo, você pode decidir que deseja uma lista das dependências instaladas durante a construção. Esta lista pode ser gerada por um valint bom dir:comando. Além disso, crie um atestado de proveniência no pipeline usando o método valint slsa comando.
• Crie um pipeline separado de geração de origem confiável que executará o seguinte:
  • Gere um documento de proveniência confiável com base naquele criado no pipeline de construção;
    • Colete dados do serviço de build e use-os para verificar e atualizar o documento de proveniência.
    • Verifique o conteúdo dos atestados criados no pipeline de build. Por exemplo, verifique o conteúdo do executor de build comparando um atestado SBOM do pipeline de build com um atestado SBOM que foi amostrado separadamente.
    • Utilize atestados recolhidos do pipeline de construção para atualizar o documento de proveniência.
    • A atualização do documento de proveniência pode ser feita através do valint slsa comando.
  • Verifique se o build foi isolado avaliando os dados coletados do serviço de build. Por exemplo – verifique o uso de caches e segredos.

Para realizar essa coleta e avaliação de dados, o Scribe fornece ferramentas que criam atestados para a execução do build e realizam as verificações necessárias.

---

Tudo bem. Parece que você está pronto para ir. Claro, se você precisar de alguma ajuda, entre em contato conosco. Estamos aqui para ajudar e adoraríamos aconselhar ou ajudar ativamente.

Artigos Relacionados

SPDX vs. CycloneDX: formatos SBOM comparados

Apesar da crescente adoção da Lista de Materiais de Software (SBOM) para servir como uma ferramenta de gerenciamento de vulnerabilidades e segurança cibernética, muitas organizações ainda lutam para compreender os dois formatos SBOM mais populares em uso atualmente, SPDX e CycloneDX. Neste artigo, compararemos esses dois formatos para ajudá-lo a escolher o certo para […]

Como o Scribe Security se alinha com o Guia do Líder da Gartner para Segurança da Cadeia de Suprimentos de Software

Em 20 de junho de 2024, a Gartner lançou seu influente Guia do Líder para Segurança da Cadeia de Suprimentos de Software, destacando a crescente necessidade de se defender contra ataques à cadeia de suprimentos de software. Com a frequência e a sofisticação crescentes desses ataques, as organizações enfrentam riscos significativos que devem gerenciar de forma eficaz. Esta publicação interpreta as descobertas críticas do relatório da Gartner. Ela explica como a Scribe […]

Comparando ASPM e CSPM: Compreendendo as diferenças e aplicações

É extremamente importante proteger ambientes e aplicações em nuvem, uma vez que o mundo é agora uma aldeia global. Duas soluções críticas para esses fins nas organizações são o Application Security Posture Management (ASPM) e o Cloud Security Posture Management (CSPM). Cada um desempenha uma função de segurança, embora desempenhem a função em diferentes ambientes e [...]