Um dos riscos da cadeia de fornecimento de software é o vazamento de segredos. Os segredos estão por toda a cadeia de fornecimento de software; os desenvolvedores e os pipelines de CI\CD precisam usar segredos para acessar o SCM, o pipeline, os registros de artefatos, os ambientes de nuvem e os serviços externos. E quando os segredos estão por toda parte, é uma questão de tempo até que vazem.
Esse risco é bem identificado e muitas estruturas da cadeia de fornecimento de software abordam-no exigindo verificação de segredos e autoexpiração de segredos.
Então, o que poderia dar errado se você, como profissional de segurança, colocasse essas proteções no lugar?
Esta semana, enquanto pesquisava ferramentas secretas de digitalização, encontrei uma resposta. Esta resposta é simples: como os scanners secretos procuram padrões de segredos, quando o formato do segredo muda, a detecção pode falhar. E foi exatamente isso que aconteceu quando o GitHub introduziu um novo recurso de segurança – o tokens refinados. Este recurso beta é uma das maneiras do GitHub de reduzir os riscos de vazamento de segredos; limitar as permissões dos tokens de acesso pessoal também limita os riscos caso esses segredos tenham sido comprometidos.
Acontece que o formato dos novos tokens é um pouco diferente, enquanto o formato dos tokens antigos era algo como:
ghp_123456789012345678901234567890123456
O novo formato do token é semelhante a:
github_pat_123456789012345678901234567890123456789012345678901234567890…
Tanto o prefixo quanto o comprimento do segredo são diferentes.
E, de fato, alguns scanners secretos não conseguem detectar o novo formato;
Para experimentar, criei um repositório com um Dockerfile com segredo e um fluxo de trabalho que executa a ação Trivy. Esta é a aparência do Dockerfile no início do experimento:
A seguir está um instantâneo do GitHub Secret Scanner, que detecta o segredo recém-formatado:
Como podemos ver, o scanner secreto do GitHub detecta o segredo, mas nenhum alerta aparece na seção Verificação de código.
Para verificar se as ferramentas estão configuradas corretamente, adicionarei agora um segredo clássico ao Dockerfile (veja abaixo) e executarei a verificação novamente. Agora recebemos um alerta de verificação de código (apenas no segredo clássico!)
O scanner do Github, por outro lado, agora detecta dois segredos:
Abri um problema de segurança para Trivy; A equipe de Trivy respondeu que esta não é uma vulnerabilidade nem um problema de segurança. O que faltou fazer foi abrir um fascículo.
Esta experiência levanta muitas preocupações;
- Por que um usuário do GitHub deveria suspeitar que o formato do token seria modificado devido a um novo recurso?
- Dado que os segredos devem parecer strings aleatórias, por que um usuário do GitHub deveria se preocupar com o formato dos segredos?
- O GitHub deveria ser responsável por atualizar seus clientes sobre tal mudança?
- Essa falha na detecção de segredos é uma vulnerabilidade dos segredos refinados do GitHub, uma vulnerabilidade do Trivy ou, na opinião da Aqua Security, não é uma vulnerabilidade?
- A Aqua Security, empresa por trás do Trivy, deveria ser responsável por atualizá-lo?
- Como o Trivy é um projeto de código aberto, fornecido como está, alguém seria responsável se os segredos vazassem de um pipeline protegido pelo Trivy? Quem seria? GitHub? Segurança Aqua? O usuário Trivy?
- O que esta experiência nos ensina sobre a confiança nas ferramentas de segurança instaladas para proteger as cadeias de fornecimento de software?
Deixarei essas questões em aberto.
Porém, uma coisa é clara; proteger a cadeia de fornecimento de software é complicado e precisamos de uma comunidade altamente profissional para ter sucesso duradouro nesta tarefa.
Esta postagem foi escrita em coautoria por Avi Waxman, estagiário da Scribe Security
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
