Segredos no código-fonte (credenciais embutidas no código, chaves de API, strings de conexão com bancos de dados, chaves privadas e tokens de autenticação incluídos em repositórios de controle de versão) representam uma das vulnerabilidades mais frequentes e de maior consequência na cadeia de suprimentos de software. São frequentes porque os fluxos de trabalho dos desenvolvedores sob pressão de prazo muitas vezes recorrem a atalhos que incluem credenciais diretamente no código ou em arquivos de configuração. São de grande consequência porque, uma vez incluídas em um repositório, as credenciais se tornam acessíveis a todos que têm acesso ao repositório e, em repositórios públicos ou semipúblicos, a qualquer pessoa que possa acessar ou clonar o repositório, mesmo depois que as credenciais são removidas da base de código atual.
O problema do histórico do git é o mecanismo específico de persistência que torna “remover as credenciais do código” uma resposta insuficiente. Os sistemas de controle de versão git mantêm um histórico completo de cada commit feito em um repositório. Uma credencial incluída em um commit e depois removida em um commit posterior continua presente no histórico git do repositório, acessível a qualquer pessoa que clone o repositório e examine os commits anteriores. A credencial pode ter sido removida da ponta do branch atual, mas permanece no histórico imutável de commits. A remediação adequada exige não apenas remover a credencial do código atual, mas também reescrever o histórico git para eliminar o commit (o que é destrutivo e disruptivo) ou rotacionar imediatamente a credencial exposta.
A ameaça da varredura de repositórios públicos é o mecanismo de descoberta automatizada. Ferramentas automatizadas examinam continuamente repositórios públicos do GitHub, GitLab e Bitbucket em busca de padrões de credenciais, pesquisando os históricos de commits, incluindo commits antigos, por formatos de chaves de API, cabeçalhos de chaves privadas, strings de conexão e outros padrões de credenciais. Uma credencial incluída em um repositório público em 2021 e “removida” por um commit posterior em 2021 ainda pode ser descoberta em 2024 por qualquer pessoa que execute uma varredura do repositório. O tempo decorrido não reduz a validade da credencial, a menos que ela tenha sido rotacionada.
Por que isso importa
Os segredos no código-fonte são importantes para TPRM porque os repositórios de desenvolvimento dos seus fornecedores podem conter credenciais que dão acesso a sistemas que tratam os seus dados: credenciais de bancos de dados de produção, chaves de provedores de nuvem, tokens de API de serviços que lidam com os seus dados. Uma credencial comprometida no repositório de um fornecedor é um vetor de ataque à cadeia de suprimentos que não exige a exploração de nenhuma vulnerabilidade no software em execução do fornecedor.
- Confirmação da política aceita sem verificação técnica
- Histórico do git não incluído no escopo da varredura de segredos
- Varredura de repositórios públicos não realizada como parte da avaliação do fornecedor
- Rotação de credenciais não confirmada como resposta a exposições passadas
- Controle de acesso aos repositórios não avaliado junto com a gestão de segredos
Como é uma boa prática
Programas maduros de gestão de segredos implementam hooks de detecção de segredos no pré-commit que impedem que segredos cheguem ao controle de versão, varredura contínua dos históricos de repositórios em busca de padrões de credenciais, rotação imediata como resposta obrigatória a qualquer exposição de credenciais descoberta e revisão explícita do histórico do git como parte da avaliação de fornecedores.
- Hooks de pré-commit que impedem que segredos cheguem ao controle de versão
- Varredura contínua de repositórios, incluindo o histórico do git
- Rotação imediata de credenciais como resposta obrigatória a qualquer exposição
- Revisão do histórico do git em busca de credenciais expostas, e não apenas do código atual
- Varredura de repositórios públicos como parte da avaliação da cadeia de suprimentos de software do fornecedor
Ferramentas
Detecção de segredos: GitLeaks, TruffleHog, GitHub Secret Scanning para varredura de repositórios e históricos
As ferramentas de detecção de segredos podem examinar históricos inteiros de repositórios, e não apenas o código atual, em busca de padrões de credenciais. GitLeaks e TruffleHog oferecem suporte à varredura de commits históricos. Os alertas de varredura de segredos do GitHub estão disponíveis para repositórios públicos. Para profissionais de TPRM, executar GitLeaks ou TruffleHog nos repositórios públicos de um fornecedor como parte da avaliação da cadeia de suprimentos de software oferece uma verificação específica de exposição de credenciais que a confirmação por questionário não substitui.
Hooks de pré-commit: detect-secrets, git-secrets para detecção de credenciais no pré-commit
Hooks de pré-commit que examinam as alterações preparadas em busca de padrões de credenciais antes do commit fornecem o mecanismo de prevenção que impede que as credenciais cheguem ao controle de versão. Para profissionais de TPRM, perguntar se os fornecedores usam hooks de detecção de segredos no pré-commit junto com a varredura pós-commit é uma pergunta específica sobre prevenção versus detecção.
Desafios de governança
O desafio de governança com segredos no código-fonte é a complexidade de remediar o histórico do git. Depois que uma credencial foi incluída em um repositório com vários colaboradores, reescrever o histórico do git para removê-la é disruptivo: exige que todos os colaboradores façam rebase ou clonem novamente. A solução pragmática é a rotação imediata da credencial, que torna inútil a credencial incluída no histórico, independentemente de o histórico do git ter sido limpo, combinada com hooks de pré-commit para impedir futuros commits.
- Implementar detecção de segredos no pré-commit: prevenção antes do controle de versão
- Examinar todo o histórico do repositório, e não apenas o código atual
- Exigir a rotação imediata de credenciais para qualquer exposição descoberta
- Realizar varreduras de repositórios públicos de fornecedores de software crítico
- Incluir o escopo do histórico do git na avaliação da gestão de segredos do fornecedor
Se você faz parte de uma equipe pequena
Execute o GitLeaks nos repositórios públicos do GitHub dos seus três fornecedores de software mais críticos. O comando leva minutos por repositório e pesquisa todo o histórico do git em busca de padrões de credenciais. Revise os achados: qualquer padrão de credencial encontrado no histórico deve ser tratado como uma possível exposição e verificado com o fornecedor quanto à rotação da credencial. Essa varredura dirá mais sobre a higiene histórica de credenciais do fornecedor do que qualquer confirmação por questionário.
- Executar o GitLeaks nos repositórios públicos de fornecedores críticos
- Revisar os achados e verificar a rotação de credenciais para quaisquer exposições descobertas
- Perguntar ao fornecedor sobre a implementação de hooks de pré-commit nos repositórios de desenvolvimento
- Exigir a divulgação da rotação de credenciais como parte da avaliação do fornecedor
O que exigir
Pergunte diretamente:
“Vocês usam hooks de detecção de segredos no pré-commit em todos os seus repositórios de desenvolvimento, e já examinaram os históricos dos seus repositórios, incluindo commits antigos, em busca de credenciais expostas? E vocês podem confirmar que todas as credenciais descobertas no histórico dos repositórios foram rotacionadas?”
O que esperar como evidência
- Implementação de hooks de detecção de segredos no pré-commit
- Cobertura da varredura do histórico de repositórios
- Confirmação da rotação de credenciais para quaisquer exposições históricas
- Política de gestão de segredos e sua aplicação
Um fornecedor que confirma não ter credenciais embutidas no código deve ser questionado especificamente sobre o escopo do histórico do git e a implementação de hooks de pré-commit. A política proíbe. Os hooks de pré-commit previnem. A varredura do histórico detecta. A rotação remedia. Os quatro são necessários para uma cobertura completa da gestão de segredos.
Como comprovar
- Registros de varredura de repositórios públicos de fornecedores críticos
- Verificação da implementação de hooks de pré-commit
- Processo de confirmação da rotação de credenciais
- Cobertura da varredura do histórico de repositórios
Principal conclusão
Política: nenhuma credencial embutida no código. Código: credenciais removidas. Histórico do git: chave de AWS, string de conexão com banco de dados, chave privada RSA, 31 meses, ainda acessíveis a qualquer pessoa que clone o repositório. A política era real. A remoção foi incompleta. Remover credenciais do código atual as deixa no histórico do git. A varredura do histórico do git as encontra. Os hooks de pré-commit impedem o próximo commit. A rotação imediata torna inútil a credencial histórica, independentemente da limpeza. Política, prevenção, detecção e rotação formam uma cobertura completa da gestão de segredos. Política e remoção do código atual formam uma cobertura incompleta.