O Supply chain Levels for Software Artifacts (SLSA) é um framework de segurança que ajuda a fornecer confiança de que um conjunto de insumos como código-fonte, bibliotecas e pacotes de software leva a um conjunto de saídas bem definidas como um binário e um bill of materials de software. É um conjunto estruturado de requisitos técnicos para ajudar um produtor a confiar nas partes da cadeia de fornecimento que estão sob seu controle direto e ajuda a fornecer confiança no processo de build para detectar quaisquer ataques de cadeia de fornecimento upstream.
O Adoptium avaliou as práticas de engenharia segura do nosso projeto para determinar o nível apropriado de atestação SLSA. Detalhes dos requisitos de nível SLSA e como eles estão sendo atendidos pelo Adoptium são fornecidos abaixo. Observe que o SLSA ainda está em estado "alpha" e os requisitos estão sujeitos a mudanças, especialmente para os Níveis SLSA 3 e 4.
SLSA Nível Um
Os seguintes requisitos para o build do Eclipse Temurin pelo Adoptium foram alcançados e satisfazem os requisitos necessários para atender ao SLSA Nível 1.
Este nível significa que o processo de build do Adoptium é totalmente scripted e automatizado, e publica atestações de bill of material de software (SBOM) formalmente estruturadas listando os componentes, bibliotecas e módulos necessários para construir cada binário.
- Build - Scripted build
-
Todos os passos para produzir o Eclipse Temurin são definidos por pipelines Jenkins com controle de versão que invocam scripts de build armazenados no repositório adoptium/temurin-build. Os pipelines e scripts de build estão disponíveis para qualquer pessoa ver e verificar, e as execuções do sistema Jenkins estão abertas ao escrutínio. A documentação para usar os scripts de build está disponível no arquivo readme do repositório de build.
- Proveniência - Available
-
O Adoptium fornece atestações SBOM para a proveniência dos builds do Eclipse Temurin. O SBOM está no formato OWASP CycloneDX e disponível junto com cada um de nossos artefatos de lançamento Temurin.
O SBOM inclui as informações necessárias para recriar o build, se necessário, incluindo as tags do repositório de origem usadas pelo processo de build, o conjunto completo de parâmetros usados, a saída das etapas de configuração e várias outras informações. Estamos evoluindo continuamente os detalhes específicos incluídos no SBOM.
SLSA Nível Dois
Os seguintes requisitos adicionais para o build do Eclipse Temurin pelo Adoptium foram alcançados e satisfazem os requisitos necessários para atender ao SLSA Nível 2.
Este nível adiciona requisitos adicionais para fornecer alguma resistência à adulteração do processo de build, principalmente nas áreas de ter todo o código com controle de versão e usar um serviço de build para produzir e distribuir builds.
- Source - Version controlled
-
O Adoptium espelha o código-fonte de referência Java SE do OpenJDK em nosso repositório local no Github (por exemplo, adoptium/jdk17u). Cada alteração no código-fonte que construímos e nos scripts que usamos é rastreada pelo sistema de controle de versão do Github. Isso garante um registro do histórico de alterações que foram para cada revisão. Cada alteração contém as identidades do uploader e dos revisores, timestamps das revisões e submissão, a descrição/justificativa da alteração, o conteúdo da alteração e as revisões pai. Todos os committers e revisores passam por forte autenticação, e todos os contribuidores devem executar e cumprir o Eclipse Contributor Agreement.
Cada revisão imutável do código sob nosso controle tem uma referência única com vida útil indefinida via Github (URL do repositório + branch/tag/ref + commit ID). O Eclipse Temurin é construído a partir de revisões marcadas do nosso mirror, e disponibilizamos arquivos de código-fonte para cada lançamento.
- Build - Build service
-
Todos os passos de build do Adoptium são executados em nosso próprio serviço de build Jenkins gerenciado e no serviço de assinatura de código da Eclipse Foundation. Esses serviços realizam os builds, geram os SBOMs e constroem os instaladores quando aplicável. A saída dos builds é enviada para repositórios de lançamento no GitHub pelo sistema Jenkins CI. Nenhuma parte do processo é executada em uma estação de trabalho de desenvolvedor.
O acesso aos serviços de build é cuidadosamente gerenciado pelo projeto. O sistema de build é tão aberto quanto possível para permitir o escrutínio pela comunidade sem comprometer a segurança.
- Proveniência - Authenticated
-
TODO: A autenticidade e integridade da proveniência podem ser verificadas pelo consumidor. Isso DEVE ser por meio de uma assinatura digital de uma chave privada acessível apenas ao serviço que gera a proveniência.
- Proveniência - Service generated
-
Todos os dados de proveniência do Adoptium são gerados diretamente pelos sistemas de build e teste contínuos do projeto. Os usuários do serviço não podem injetar ou alterar o conteúdo da proveniência. As assinaturas de código GNU Privacy Guard (GPG) do Eclipse Temurin são geradas pelo serviço de assinatura de código da Eclipse, outros dados de proveniência incluindo o bill of materials de software, hashes criptográficos, metadados de build, etc. são emitidos diretamente pelo sistema de build do projeto.
SLSA Nível Três - Em andamento
Alguns dos seguintes requisitos adicionais para o build do Eclipse Temurin pelo Adoptium foram alcançados. O trabalho continua nos itens restantes à medida que buscamos alcançar o SLSA Nível 3.
- Source - Retained 18mo
-
Todas as revisões do código-fonte e seu histórico de alterações são preservadas indefinidamente e não podem ser excluídas, exceto quando sujeitas a uma política estabelecida e transparente de obliteração, como um requisito legal ou de política da Eclipse Foundation. Este nível de controle de superusuário para alterar ou excluir o histórico é mantido direta e exclusivamente pela Eclipse Foundation em nome do projeto.
Como armazenamos todo o nosso código no GitHub, não é possível para pessoas excluir ou modificar o histórico, mesmo com aprovação de múltiplas partes, exceto por administradores de plataforma confiáveis da Eclipse Foundation com aprovação de duas partes seguindo a política de obliteração da foundation. Perguntas sobre esta política devem ser endereçadas à Eclipse Foundation.
- Build - Build as code
-
A definição e configuração de build do Adoptium executadas pelo serviço de build são verificavelmente derivadas das definições de arquivo de texto armazenadas em nosso sistema de controle de versão.
- Build - Ephemeral environment
-
Builds em ambiente efêmero como um contêiner ou VM, provisionado exclusivamente para este build e não reutilizado de um build anterior, estão disponíveis para builds Linux x86, ARM32 e aarch64. Outras plataformas ainda estão em andamento no projeto.
- Build - Isolated
-
O serviço de build do Adoptium garante que cada etapa de build seja executada em um ambiente isolado, livre de influência de outras instâncias de build, sejam anteriores ou simultâneas.
Não é possível que um build acesse quaisquer segredos do serviço de build, como a chave de assinatura de proveniência, pois estes são armazenados fora do sistema de build e acessados por uma chamada remota a um sistema separado. Não é possível que dois builds que se sobrepõem no tempo se influenciem mutuamente. Cada etapa de build é executada em um ambiente de máquina isolado orquestrado pelo sistema Jenkins CI, e as etapas de cada build são montadas por meio de pipelines gerenciados. Os caches de build, quando usados, são puramente endereçáveis por conteúdo para evitar adulterações.
Continuamos trabalhando para garantir que não seja possível que um build persista ou influencie o ambiente de build de um build subsequente. Cada parte do ambiente é especificada nos scripts de build. Isso será garantido executando builds em máquinas efêmeras em todos os lugares e verificando se os resultados são idênticos.
- Proveniência - Non-falsifiable
-
As informações de proveniência do SBOM não podem ser falsificadas por usuários do serviço, pois são geradas por máquina pelo processo de build e assinadas criptograficamente pelo serviço de assinatura de código da Eclipse Foundation para evitar adulterações. O serviço de assinatura de código não é acessível a committers regulares do projeto ou usuários do Jenkins.
SLSA Nível Quatro - Em andamento
O Adoptium está trabalhando nos itens necessários para atender aos requisitos do SLSA Nível 4. Eles estão sendo rastreados por meio de nosso sistema de rastreamento de issues, e contribuições são bem-vindas para essas tarefas.
