Análise de commits públicos, ambientes internos e incidentes de cadeia de suprimentos aponta 29 milhões de novos segredos hardcoded em 2025 e mostra que rotação continua sendo o principal gargalo defensivo.
| Componente | Segredos hardcoded em GitHub público, repositórios internos, ferramentas de colaboração, registros Docker, instâncias GitLab auto-hospedadas, arquivos de configuração de MCP e máquinas de desenvolvimento ou CI/CD. |
| Vetor | Credenciais são incorporadas em commits, imagens de contêiner, arquivos .env, histórico de shell, configurações de IDE, artefatos de build, chats corporativos e arquivos JSON locais usados por integrações de IA e agentes. |
| Impacto | Foram identificados 29 milhões de novos segredos hardcoded em 2025, alta anual de 34%; 64% dos segredos validados em 2022 continuavam exploráveis quatro anos depois, indicando falha persistente de revogação e rotação. |
| Prioridade | Tratar segredos como identidades não humanas governadas, reduzir credenciais estáticas de longa duração, ampliar varredura para fora do código e automatizar rotação sem interromper produção. |
| Versões | O levantamento compara dados de 2025 com 2024 e também retesta segredos confirmados como válidos em 2022. |
| Artefatos | Arquivos .env, caches de tokens, configurações de IDE, variáveis de CI/CD, imagens Docker, repositórios GitLab auto-hospedados, arquivos de configuração relacionados a MCP e registros de ferramentas colaborativas. |
A expansão de segredos hardcoded deixou de ser um problema concentrado em repositórios públicos e passou a refletir a forma como software, automação e IA são entregues dentro das organizações. Em 2025, foram encontrados 29 milhões de novos segredos em commits públicos no GitHub, uma alta de 34% em relação ao ano anterior e o maior salto anual registrado no conjunto analisado. Desde 2021, o volume de segredos vazados cresceu 152%, enquanto a base pública de desenvolvedores no GitHub aumentou 98%. A diferença entre esses percentuais indica que o crescimento não é apenas consequência de mais pessoas escrevendo código; há também mais integrações, mais identidades de máquina e mais pontos onde credenciais acabam sendo copiadas para lugares errados.
O vetor mais visível é a IA aplicada ao desenvolvimento. Foram detectados 1.275.105 segredos associados a serviços de IA em 2025, aumento de 81% sobre 2024. O problema não se limita a chaves de provedores de modelos. As categorias que mais cresceram incluem APIs de recuperação, ferramentas de orquestração e backends gerenciados usados para compor aplicações com LLMs. Exemplos citados incluem Brave Search com crescimento de 1.255%, Firecrawl com 796% e Supabase com 992%. Cada integração desse tipo normalmente exige tokens, chaves de API, contas de serviço ou credenciais de acesso, o que amplia a superfície de exposição quando esses valores são colocados em código, configuração local ou artefatos de build.
O fluxo de exposição começa quando uma credencial operacional é usada como atalho de desenvolvimento. Em vez de ser obtida de um cofre, de uma identidade federada ou de um mecanismo de emissão curta, ela é gravada em um arquivo de configuração, copiada para uma variável local, usada em um exemplo de teste ou compartilhada em uma ferramenta de colaboração durante suporte, onboarding ou resposta a incidente. A partir desse ponto, o segredo passa a se replicar: entra em commits, fica em histórico de shell, aparece em configurações de IDE, é empacotado em imagens Docker, permanece em caches e pode ser capturado por pipelines ou runners de CI/CD.
A pesquisa sobre sistemas comprometidos no ataque de cadeia de suprimentos Shai-Hulud 2 mostra como essa replicação ocorre na prática. Em 6.943 sistemas, foram observadas 294.842 ocorrências de segredos, correspondentes a 33.185 segredos únicos. Em média, cada segredo vivo aparecia em oito locais no mesmo sistema. O dado mais relevante para defesa é que 59% das máquinas comprometidas eram runners de CI/CD, não laptops pessoais. Isso desloca o risco de higiene individual para exposição organizacional: quando um runner acumula tokens de build, credenciais de nuvem e permissões de publicação, a presença de segredos em múltiplos caminhos locais pode transformar uma infecção de estáção ou ambiente de build em acesso persistente a sistemas de entrega.
Outro padrão aparece em ataques de cadeia de suprimentos envolvendo ferramentas usadas em desenvolvimento de IA. No caso LiteLLM citado no contexto, pacotes comprometidos foram associados à coleta de chaves SSH, credenciais de nuvem e tokens de API em máquinas de desenvolvedores. A informação importante para operadores defensivos é o ponto de concentração: ambientes onde ferramentas de IA são testadas, empacotadas e integradas tendem a reunir credenciais de múltiplos serviços. Se esses ambientes não tiverem isolamento, escopo mínimo e rotação automatizada, uma dependência maliciosa ou comprometida pode encontrar segredos reutilizáveis em arquivos e caches locais sem precisar explorar uma vulnerabilidade separada no provedor de destino.
Repositórios internos aparecem como área de maior densidade de credenciais sensíveis. Enquanto 5,6% dos repositórios públicos analisados continham ao menos um segredo hardcoded, 32,2% dos repositórios internos apresentavam pelo menos um segredo. O contraste é relevante porque esses repositórios costumam armazenar ativos mais próximos de produção, como tokens de CI/CD, credenciais de acesso à nuvem e senhas de banco de dados. A suposição de que o repositório interno é suficientemente protegido falha quando um invasor já obteve acesso inicial por identidade, endpoint, cadeia de suprimentos ou credencial reutilizada.
A superfície também se estende para fora do código. Em 2025, 28% dos incidentes relacionados a segredos tiveram origem exclusivamente fora de repositórios, em ferramentas como Slack, Jira, Confluence e plataformas similares. Os segredos vistos apenas nessas ferramentas foram classificados como críticos em 56,7% dos casos, contra 43,7% nos incidentes observados apenas em código. Isso sugere que mensagens de troubleshooting, documentação operacional e conversas de resposta a incidente podem carregar credenciais de maior privilégio do que exemplos acidentais em código-fonte.
Infraestrutura auto-hospedada e contêineres acrescentam outra camada. Foram encontrados milhares de GitLabs auto-hospedados e registros Docker expostos de forma não intencional. A varredura desses sistemas revelou 80.000 credenciais, das quais 10.000 ainda eram válidas. Entre imagens Docker analisadas, 18% continham segredos, e 15% desses segredos eram válidos. Em repositórios GitLab, 12% continham segredos e 12% desses eram válidos. O ponto operacional é que imagens de contêiner podem guardar credenciais próximas de runtime, artefatos de build e configuração de produção, o que torna a exposição particularmente sensível.
- Repositórios internos com tokens de CI/CD, credenciais de nuvem e senhas de banco de dados gravadas no código ou em arquivos auxiliares.
- Ferramentas de colaboração contendo segredos compartilhados durante troubleshooting, onboarding e resposta a incidente.
- Registros Docker e imagens de contêiner com segredos válidos preservados em camadas, configurações ou artefatos de build.
- Arquivos de configuração relacionados a MCP, nos quais foram encontrados 24.008 segredos únicos em GitHub público, com 2.117 verificados como válidos.
A detecção precisa cobrir o ciclo de vida do segredo, não apenas o commit público. Equipes devem correlacionar achados em repositórios, CI/CD, artefatos de build, imagens de contêiner, ferramentas colaborativas e endpoints de desenvolvimento. Um segredo encontrado em um arquivo .env local deve ser tratado como indicador de propagação, não como evento isolado. A média de oito locais por segredo em máquinas comprometidas mostra que remover apenas o arquivo onde o alerta apareceu não elimina o risco se o mesmo valor também estiver em cache, histórico, configuração de IDE ou variável de pipeline.
Para ambientes com IA e agentes, a telemetria deve incluir arquivos de configuração locais, parâmetros de inicialização, integrações com backends gerenciados e conectores que acessam ferramentas externas. O MCP é um exemplo relevante porque normaliza a ligação entre agentes, ferramentas e fontes de dados. Em 2025, foram observados 24.008 segredos únicos em arquivos de configuração relacionados a MCP no GitHub público, com 2.117 válidos. A defesa deve interpretar esse padrão como crescimento de identidades não humanas: cada agente, serviço de recuperação, backend e conector precisa de inventário, proprietário, escopo e data de expiração.
A caça também deve separar segredo exposto de segredo ainda explorável. O dado de que 64% dos segredos validados em 2022 continuavam exploráveis quatro anos depois mostra que alertas antigos não podem ser simplesmente arquivados como risco histórico. Sem revogação confirmada no provedor original, rotação da dependência consumidora e validação de ausência em artefatos derivados, o segredo permanece útil para acesso indevido. Logs de uso de API, eventos de autenticação, alterações em permissões de contas de serviço e acessos fora do padrão são essenciais para medir se houve uso após a exposição.
- Ocorrência do mesmo segredo em múltiplos locais, como
.env, histórico de shell, cache de token, configuração de IDE e artefatos de build. - Segredos detectados em imagens Docker, registros expostos ou camadas antigas que continuam distribuídas em ambientes de execução.
- Mensagens, tickets ou páginas internas contendo chaves de API, senhas de banco de dados ou tokens de CI/CD compartilhados fora de cofres oficiais.
- Uso de credenciais antigas após a data de detecção, especialmente em provedores de nuvem, backends gerenciados, APIs de IA e pipelines de entrega.
A resposta deve começar pela validação de escopo e pela revogação controlada. Segredos confirmados como válidos precisam ser rotacionados no sistema emissor, removidos dos locais onde foram copiados e substituídos por mecanismos de acesso de menor duração. Em ambientes de produção, a rotação deve considerar dependências de build, variáveis de CI/CD, integrações de fornecedores e serviços que consomem a credencial. O risco operacional de quebrar produção é justamente uma das razões para segredos permanecerem exploráveis por anos; por isso, o processo precisa ser testado, documentado e automatizado, não tratado como exceção manual.
A mitigação estrutural é governança de identidades não humanas. Contas de serviço, jobs de CI, agentes de IA, conectores MCP, backends gerenciados e integrações de busca ou orquestração devem ter proprietário, escopo mínimo, validade definida e trilha de auditoria. Onde possível, credenciais estáticas longas devem ser substituídas por acesso baseado em identidade, emissão curta e políticas condicionais. O fluxo padrão de desenvolvimento precisa direcionar segredos para cofres e mecanismos de injeção segura, reduzindo a necessidade de copiar valores para arquivos locais, documentação ou mensagens.
Também é necessário ampliar a cobertura de varredura. Repositórios públicos continuam relevantes, mas não bastam. Repositórios internos, ferramentas colaborativas, registros Docker, GitLab auto-hospedado, endpoints de desenvolvimento e runners de CI/CD devem entrar no programa de detecção e resposta. Para imagens de contêiner, a revisão deve incluir camadas, metadados e artefatos gerados durante build. Para ferramentas colaborativas, a resposta deve incluir remoção do conteúdo exposto, rotação do segredo e orientação de processo para evitar compartilhamento de credenciais em canais de suporte.
- Inventariar segredos e identidades não humanas por serviço, proprietário, escopo, validade e ambiente consumidor.
- Rotacionar e revogar credenciais confirmadas como válidas, validando que o segredo antigo não funciona mais no provedor de origem.
- Aplicar cofre de segredos e emissão curta como fluxo padrão para desenvolvimento, CI/CD, agentes de IA e integrações de backend.
- Expandir varredura para colaboração, contêineres, runners, infraestrutura auto-hospedada e arquivos de configuração usados por agentes e ferramentas de IA.
- Monitorar uso pós-exposição em logs de autenticação, APIs de nuvem, serviços de IA, backends gerenciados e pipelines de entrega.
0 Comentários