Cadeia de Suprimentos de Software: Parte 3
Como parte da minha série de cadeia de suprimentos de software, quero passar para a área de assinatura e implantação de código. Um novo padrão que está começando a ganhar força é chamado Sigstoreliderado pela Linux Foundation, mas com contribuições de muitos líderes da indústria.
Sigstore é um assunto um pouco complicado, mas está ganhando muita popularidade. É usado em gigantes da tecnologia como o Google e tem 2.000 usuários em seu canal Slack corporativo. A ideia é bastante direta e simplesmente descrita como “o novo padrão para assinatura, verificação e proteção de software”. Em termos básicos, isso permitirá que você verifique a integridade do software sem gerenciar manualmente todas as outras despesas gerais.
Por que precisamos disso de qualquer maneira? Bem, quando você olha para o ciclo de vida de desenvolvimento de software, o processo de construção é muitas vezes visto como algo que só precisa funcionar. Se isso soa familiar, você deve se lembrar desse tipo de ataque do hack SolarWinds em 2020.
Aqui está um exemplo de fluxo de trabalho de software em que os invasores podem invadir:
Com esse pano de fundo, vamos mergulhar um pouco mais na pilha de tecnologia. No processo de desenvolvimento de software atual, cada desenvolvedor não tem a capacidade de assinar o código, e a maioria das organizações o implementa no processo de lançamento antes de ser enviado. Os certificados precisam ser mantidos e protegidos, que geralmente recaem sobre um grupo seleto de engenheiros ou membros da segurança.
Sigstore oferece uma ferramenta de assinatura gratuita e de código aberto por meio de certificados efêmeros (pares de chaves públicas/privadas) e links para um endereço de e-mail corporativo ou outra conta para fins de rastreamento, simplificando e reduzindo o nível de exigência para que mais desenvolvedores usem a ferramenta. Ademais, o ecossistema sigstore é capaz de centralizar e verificar todos os metadados de todas essas assinaturas de código no processo. Isso permite mais transparência e distribui a responsabilidade por toda a organização.
Seguro por padrão é muito importante e não deve ser subestimado. Precisamos de mais verificações durante nosso ciclo de vida de desenvolvimento para garantir a integridade do software do início ao fim. A meu ver, ainda existem algumas coisas que impedem a adoção mais ampla da sigstore:
- A CA raiz do Sigstore é uma fonte única de falha – não foi testada para escala e pode bloquear implantações de código. O site atualmente reivindica 99,5% de disponibilidade, o que significa 1d 19h 28m de tempo de inatividade por ano. O maior problema é que há pouco recurso se eles não cumprirem o SLO.
- Aumento de dados – Você acabou de passar de algumas chaves para potencialmente milhares. Isso significa que há muito mais dados para filtrar e entender. Mesmo que a solução seja de código aberto, você provavelmente precisará gastar dinheiro em infraestrutura para poder usar os dados, como uma ferramenta de agregação de log.
- Está escrito em Golang – Isso não é necessariamente uma desvantagem, mas pode ser se você precisar oferecer suporte a um novo idioma em seu ambiente. O projeto é fortemente apoiado pelo Google e existem versões estáveis para outras linguagens, mas as principais ramificações são desenvolvidas em Go, o que significa que você precisa garantir que seu ambiente suporte essa integração.
A assinatura de código é muito importante para se defender contra ataques à cadeia de suprimentos, mas também é uma das mais complicadas de implementar para o desenvolvimento interno. Embora o sigstore possa não ser perfeito, os ganhos de segurança são substanciais. Para setores altamente direcionados e regulamentados, considere o valor de implementar esse processo no início do ciclo de vida do código para obter o máximo de benefícios.