Este artigo foi escrito em parceria com Viktor Kartashov e Daniel Nebenzahl.
O teste decisivo do auditor: você consegue provar suas construções?
“Você pode provar, definitivamente, que cada imagem de contêiner que você envia foi construída exatamente da maneira que você afirma?”
A maioria dos auditores espera uma resposta rápida e confiável – não semanas de refatoração frenética de YAML. A estrutura SLSA (Níveis da Cadeia de Suprimentos para Artefatos de Software) fornece o modelo para essa comprovação: procedência estruturada e inviolável.
Mas aqui está o problema: tradicionalmente, conectar um gerador de procedência em cada fluxo de trabalho de CI rapidamente se transforma em um jogo de acertar a toupeira:
- Dezenas de repositórios? Isso significa inúmeros PRs para revisar e mesclar.
- Mudanças no pipeline? Manutenção manual constante.
- Construções históricas? Não há uma maneira direta de recriar evidências de lançamentos anteriores.
O Scribe Security elimina esse atrito com o SLSA on Scale. Impulsionado por nosso nível superior Plataformas CLI, ele coleta de forma inteligente seus logs de CI existentes, detecta automaticamente cada criação de imagem e emite uma procedência completa e abrangente (não assinada para SLSA Nível 1 ou assinada para SLSA Nível 2) — tudo a partir de um único comando que não requer nenhuma configuração preliminar.
Plataformas CLI: A mudança de paradigma sem toque na procedência
| Abordagem tradicional | Plataformas Scribe CLI |
| Incorpore uma etapa do gerador em cada tarefa de CI | Nenhuma edição de pipeline — analisa logs depois de a construção é concluída |
| Difícil preencher construções antigas | Cria proveniência retroativamente de execuções de fluxo de trabalho anteriores |
| Esforço linear por repositório | Uma escala de comando para 10 → mais de 1,000 repositórios |
Como a mágica acontece: automatizando a confiança
O Scribe Platforms CLI executa uma dança sofisticada nos bastidores para fornecer procedência SLSA automatizada, tudo isso sem interferir em suas compilações existentes:
- Ele colhe toras: O Scribe se conecta ao seu sistema de CI/CD (atualmente GitHub Actions, com suporte para GitLab e Jenkins em breve) para buscar logs de compilação.
- Ele detecta cada compilação: Sem nenhuma configuração especial em seus pipelines, o Scribe identifica de forma inteligente os comandos Docker, Podman ou Buildah para localizar cada criação de imagem.
- Ele extrai metadados importantes: Detalhes críticos como tags de imagem, resumos criptográficos, IDs de execução, argumentos de compilação e registros de data e hora são extraídos diretamente desses logs.
- Ele gera SBOMs vinculados: Para rastreabilidade completa, o Scribe cria automaticamente ambos fonte Lista de materiais de software (SBOMs) e imagem SBOMs, vinculando-os diretamente à procedência da construção.
- Proveniência do SLSA: Com esses dados valiosos, o Scribe constrói uma declaração de procedência SLSA totalmente compatível para cada imagem.
- Ele assina (opcionalmente) para o nível 2: Ao simplesmente adicionar um sinalizador, o Scribe se integra à sua capacidade de assinatura (X509, Pub-Priv, Sigstore ou seu KMS preferido) para assinar criptograficamente a procedência, elevando-a ao Nível 2 do SLSA.
- Ele valida e relata: Fundamentalmente, o Scribe executa automaticamente programas predefinidos SLSA.l1 or SLSA.l2 iniciativas baseadas em evidências. Isso valida sua integridade e gera um relatório SARIF abrangente, que também é assinado para conformidade com o Nível 2.
Todos os artefatos gerados podem permanecer locais ou ser enviados com segurança para o Scribe Hub para armazenamento de longo prazo e à prova de violação.
Além da Geração: Comprovando a Conformidade com a Política como Código
Gerar a procedência é fundamental, mas comprovar sua conformidade é o que realmente satisfaz os auditores. Imediatamente após o Scribe gerar a procedência do SLSA, ele executa automaticamente iniciativas com base nessas evidências.
Essas iniciativas atuam como auditores automatizados, verificando coisas como:
- A procedência está bem formada e completa?
- Todos os campos necessários estão presentes e corretos?
- Os SBOMs vinculados são válidos e acessíveis?
- A procedência foi assinada criptograficamente pelas identidades esperadas?
O resultado? Um relatório SARIF abrangente detalhando seu status de conformidade. Para o Nível 2, este relatório também é assinado, fornecendo uma resposta clara, legível por máquina e verificável para qualquer auditor.
Um exemplo rápido: obtendo procedência SLSA com Scribe-Security 🚀
A CLI de Plataformas da Scribe-Security simplifica a geração de proveniência SLSA para suas compilações, oferecendo um comando unificado para alcançar garantia de Nível 1 (não assinado) e Nível 2 (assinado). O diferencial crítico é a presença do argumento –valint.sign.
Para obter a procedência do SLSA para todas as compilações baseadas em tags no seu repositório scribe-security/valint no GitHub, você executaria o seguinte comando:
Bater
plataformas descobrir \ --valint.sign \ # Incluir isso para SLSA Nível 2 (assinado), omitir para SLSA Nível 1 (não assinado) github \ --token EXAMPLE_GH_TOKEN \ --scope.organization example-org \ --scope.repository example-repo \ --repository.mapping *::example_slsa::v1 \ --commit.skip \ --slsa-enable \ --slsa.tags-only
O Scribe então entra em ação: ele verifica os fluxos de trabalho recentes do GitHub, detecta de forma inteligente suas compilações de imagens, coleta todos os dados necessários e grava uma procedência SLSA completa e abrangente com SBOMs vinculados.
--valint.sign: Sua opção para SLSA Nível 1 ou 2 🔑 A flag --valint.sign atua como sua alternância simples: Omita --valint.sign para SLSA Nível 1 (Não Assinado): O Scribe gera procedência fundamental e não assinada para rastreabilidade básica. Inclua --valint.sign para SLSA Nível 2 (Assinado): O Scribe assina criptograficamente os arquivos de procedência e o relatório de conformidade SARIF, proporcionando um nível mais alto de garantia verificável.
Este comando unificado, controlado por um único sinalizador, simplifica a obtenção de conformidade robusta com SLSA em escala sem modificar seus pipelines de CI/CD existentes.
Geração de proveniência SLSA de código aberto
A geração de proveniência SLSA não se limita a repositórios privados. Muitos projetos de código aberto têm logs públicos de CI/CD, possibilitando a geração de procedência para suas compilações. Embora esses registros de procedência possam inicialmente conter informações menos extensas (como segredos de repositório e organização), melhorias futuras, potencialmente por meio da Fonte SBOM, poderia abordar isso.
Por exemplo, você pode facilmente gerar a proveniência SLSA Nível 1 para o go-gitea/gitea projeto usando o descoberta da plataforma comando:
plataformas descobrir github \ --token EXAMPLE_GH_TOKEN \ # Qualquer token funcionará, desde que o alvo seja público --scope.organization go-gitea \ --scope.repository gitea \ --repository.mapping *gitea*::gitea_demo::v1 \ --scope.workflow.past_days 30 \ # Escopo de fluxos de trabalho a serem revisados nos últimos 30 dias --slsa-enable \ --scope.workflow.name "*release-tag*" \ # Foco da análise em fluxos de trabalho de lançamento --exclude.types member commit secret \ # Exclui grandes conjuntos de dados e APIs não autenticadas --slsa.tags-only # Foco da análise em execuções de fluxos de trabalho marcados
Depois de executar este comando, você verá um log indicando a solicitação SLSA e uma tabela resumindo as compilações de imagens detectadas e suas procedências associadas:
Como você pode ver, no momento da redação deste texto, a versão mais recente de `gitea/gitea` encontrada era a **v1.24.2**. As duas imagens para as quais a proveniência do SLSA e suas evidências relacionadas foram emitidas são `gitea/gitea:1.24.2` e `gitea/gitea:1.24.2-rootless`. Como exemplo, a proveniência do SLSA pode ser referenciada no seguinte: link,
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
