O cenário dos segredos: por que 28 milhões de credenciais vazaram no GitHub em 2025 e o que fazer a respeito

“Como sua empresa gerencia chaves de API?”

Essa foi a pergunta feita à comunidade de desenvolvedores no Hacker News. Uma das respostas mais votadas foi uma única palavra: “mal.”

Os dados confirmam isso: o relatório State of Secrets Sprawl 2026 da GitGuardian constatou que 28,65 milhões de novos segredos codificados diretamente foram adicionados a repositórios públicos do GitHub só em 2025 — um aumento de 34% em relação ao ano anterior. O próprio relatório de segurança do GitHub contabilizou 39 milhões de vazamentos de segredos em 2024. Um estudo acadêmico publicado no IEEE S\&P 2025, que analisou mais de 80 milhões de arquivos, constatou que até 30% dos projetos estão em risco.

Esse padrão se repete em todos os níveis de experiência e em organizações de todos os portes. Vamos analisar as consequências legais e financeiras que se seguiram a violações de credenciais desse tipo.

Este é um guia completo para entender por que as credenciais vazam, quais ferramentas existem para detectar e prevenir vazamentos e como criar uma defesa prática em camadas. Seja você uma pessoa desenvolvedora independente tentando organizar seus arquivos .env ou uma equipe de segurança implementando a análise em toda a organização, este guia é para você.

O que é considerado um “segredo”

Um segredo é qualquer dado que conceda acesso a um sistema ou recurso. Os exemplos mais óbvios são chaves de API, senhas de banco de dados e chaves privadas SSH. Mas essa definição se expandiu bastante:

• Credenciais de IAM na nuvem (chaves de acesso da AWS, JSON de contas de serviço do GCP, segredos de cliente do Azure)

• Tokens OAuth e tokens de atualização

• URLs de webhook (que muitas vezes contêm dados de autenticação)

• Strings de conexão (bancos de dados, filas de mensagens, cache)

• Chaves de criptografia e certificados de assinatura

• Chaves de API de serviços de IA (OpenAI, Anthropic, Hugging Face, DeepSeek)

• Tokens de configuração de servidores MCP (uma categoria que cresce rapidamente; falaremos mais sobre isso adiante)

O Guia de gerenciamento de segredos da OWASP apresenta uma taxonomia detalhada. O ponto principal é que qualquer dado usado por uma máquina para se autenticar é um segredo — e os aplicativos modernos envolvem muitas máquinas se comunicando entre si.

Como os segredos vazam

Entender como os segredos acabam expostos é o primeiro passo para evitar vazamentos. Com base em discussões da comunidade, pesquisas acadêmicas e dados do setor, estas são as formas mais comuns.

Commits acidentais

Este é o cenário mais comum: durante o desenvolvimento, uma pessoa desenvolvedora adiciona credenciais ao código-fonte (“só para testar”) e envia o arquivo para o controle de versão. Mesmo que o segredo seja removido em um commit posterior, ele permanece indefinidamente no histórico do git. O modelo de dados somente de acréscimo do Git significa que um git rm não remove nada de fato. Atacantes podem — e costumam — analisar todo o histórico de repositórios públicos.

Um exemplo real de uma discussão no r/aws: uma equipe inseriu chaves de acesso do IAM com permissões completas de Delete no S3 diretamente em JavaScript no front-end. Em poucos dias, um agente desconhecido apagou os buckets do S3.

O problema dos arquivos .env

Os arquivos .env são uma conveniência de desenvolvimento que muita gente entende, equivocadamente, como uma barreira de segurança. Eles nunca foram projetados para isso. Os riscos são bem conhecidos:

• Arquivos .env acabam incluídos em commits por acidente quando desenvolvedores usam git add . em vez de adicionar os arquivos pelo nome

• Eles são compartilhados em mensagens do Slack, capturas de tela e aplicativos de notas, ou colados no ChatGPT para pedir ajuda na depuração

• Eles são incorporados a imagens Docker por causa de instruções COPY . . usadas sem cuidado

O próprio canal SnykSec da Snyk abordou esse tema em detalhes:

Play Video: YouTube Video: pcbRwwaCPUg

Por que não armazenar segredos em arquivos .env. Apresenta alternativas práticas com Doppler e 1Password CLI para injetar segredos em tempo de execução.

O vídeo apresenta ataques à cadeia de suprimentos que visam especificamente arquivos .env (pacotes NPM comprometidos, como tinyColor e ngx-bootstrap) e mostra como substituir arquivos .env estáticos pela injeção de segredos em tempo de execução com Doppler e o comando op run do 1Password CLI.

A cadeia de suprimentos como vetor de ataque

Pacotes maliciosos que roubam credenciais de ambientes de desenvolvimento não são algo hipotético. A Snyk acompanhou vários incidentes reais:

• O worm Shai-Hulud do NPM foi criado para procurar e exfiltrar tokens do NPM e do GitHub em grande escala

• O comprometimento do tinyColor/ngx-bootstrap inseriu malware que rouba credenciais em pacotes com milhões de downloads semanais

• Em um caso particularmente notável, atacantes transformaram o próprio TruffleHog em arma, usando-o como payload em um pacote NPM comprometido (@ctrl/tinycolor, com 2,2 milhões de downloads semanais) e aproveitando os recursos de análise da própria ferramenta de segurança para localizar e exfiltrar segredos

Superfícies fora do código

A pesquisa da GitGuardian mostra que 28% dos incidentes com credenciais têm origem totalmente fora dos repositórios de código. Os segredos vazam por meio de:

• Mensagens do Slack (2,4% dos canais contêm pelo menos um segredo vazado)

• Tickets do Jira (6,1% expõem credenciais, muitas vezes em registros de relatórios de bugs)

• Páginas do Confluence (documentação com strings de conexão)

• Imagens do Docker Hub (mais de 10 mil imagens encontradas com credenciais incorporadas)

• Plataformas de formatação de código (quando desenvolvedores colam código em formatadores on-line)

• Preprints no arXiv (milhares de chaves de API na nuvem encontradas em arquivos-fonte LaTeX, segundo Dubniczky et al., 2025)

O impacto do desenvolvimento com assistência de IA

Este é o vetor de vazamento que mais cresce. O relatório de 2026 da GitGuardian constatou que commits com assistência de IA vazam segredos a uma taxa de 3,2%, cerca de duas vezes a média. Vários fatores contribuem para isso:

• Ferramentas de programação com IA podem gerar código funcional que inclui credenciais codificadas diretamente

• Recursos de preenchimento automático de código podem memorizar e reproduzir credenciais dos dados de treinamento (Huang et al., 2023, 39 citações)

• Um incidente de 2024 revelou que o Cursor (editor de código com IA) enviava o conteúdo de arquivos .env para seus servidores para completar código, mesmo quando os arquivos estavam listados em .cursorignore

• Ferramentas neurais de preenchimento automático de código não entendem, por si só, o que é um segredo

As credenciais de serviços de IA são a categoria de segredos vazados que mais cresce: em 2025, houve um aumento de 81% em relação ao ano anterior. Entre os tipos mais vazados estão tokens do Hugging Face, chaves do Azure OpenAI e credenciais do Weights & Biases. Só em 2025, foram detectadas 113 mil chaves de API da DeepSeek.

O problema das credenciais do MCP

Se você trabalha com servidores do Model Context Protocol (MCP), precisa ficar atento a uma nova superfície de credenciais. A GitGuardian encontrou 24.008 segredos únicos em arquivos de configuração relacionados ao MCP no GitHub público, dos quais 2.117 ainda são válidos.

A causa principal é reveladora: a documentação oficial de início rápido do MCP muitas vezes mostra chaves de API codificadas diretamente nos exemplos de configuração. Desenvolvedores copiam esses modelos, substituem os espaços reservados pelas próprias chaves e enviam o arquivo de configuração para o repositório. O ecossistema MCP está crescendo rapidamente, e esse padrão se espalha na mesma velocidade.

A Snyk publicou bastante conteúdo sobre como proteger servidores MCP e os riscos do cenário de desenvolvimento de IA agentiva. Pesquisas sobre servidores MCP maliciosos e vazamentos de credenciais em ecossistemas de Agent Skills acrescentam contexto: as ferramentas que usamos para criar aplicativos de IA também estão se tornando vetores de exposição de credenciais.

Play Video: YouTube Video: wIvoefvBpWE

O segredo para um código de IA seguro. Como a Snyk se integra aos fluxos de trabalho de desenvolvimento com IA para detectar problemas de segurança no código gerado.

SAST e análise de segredos: disciplinas relacionadas, mas distintas

Uma das confusões mais citadas nas comunidades de desenvolvimento é a suposição de que uma ferramenta de SAST (teste estático de segurança de aplicativos) também cobre a análise de segredos. São disciplinas complementares, mas distintas, e vale a pena entender a diferença.

Ferramentas de SAST, como o Snyk Code, analisam o código-fonte em busca de vulnerabilidades de segurança, incluindo falhas de injeção, desserialização insegura, desvios de autenticação e outros problemas semelhantes no código. Em geral, elas analisam a árvore de trabalho (o estado atual dos arquivos).

Ferramentas dedicadas à análise de segredos têm um escopo diferente: analisam o histórico completo do git, incluindo cada commit, cada branch e cada arquivo excluído que ainda exista no armazenamento de objetos. Isso é importante porque:

1. Um segredo incluído em um commit e removido no seguinte ainda permanece no histórico do git

2. Consolidar commits não elimina dados “órfãos” acessíveis pelo hash SHA-1

3. Arquivos excluídos ainda podem ser analisados em arquivos .pack

4. Um relato de bug bounty documentou US$ 64 mil ganhos exclusivamente pela análise de arquivos excluídos e objetos órfãos em repositórios públicos

Na prática, as organizações se beneficiam tanto do SAST, para encontrar vulnerabilidades de segurança no código, quanto de ferramentas dedicadas para detectar credenciais expostas. Cada uma cobre uma superfície de risco diferente. Como observou um profissional no r/devsecops: “Uma ferramenta de análise de segredos também procura segredos no histórico do git, o que pode levar tempo dependendo do tamanho dos repositórios.”

O cenário das ferramentas de análise de segredos

O ecossistema de código aberto para análise de segredos amadureceu bastante. Veja como está o cenário em 2026, com uma avaliação franca dos pontos fortes e das limitações de cada ferramenta.

TruffleHog

O TruffleHog (cerca de 25.300 estrelas, Go, AGPL-3.0) foi criado por Dylan Ayrey em 2016 e hoje é mantido pela Truffle Security Co., que captou US$ 25 milhões em uma rodada Série B em novembro de 2025.

Um recurso de destaque é a verificação de credenciais ativas. Além de comparar padrões com regras de expressões regulares, o TruffleHog pode validar as credenciais encontradas diretamente nas APIs dos provedores para confirmar se ainda estão ativas. Isso pode reduzir bastante os falsos positivos. A ferramenta inclui mais de 800 detectores e a opção --only-verified, que filtra os resultados para mostrar apenas credenciais confirmadas como ativas.

O TruffleHog analisa o histórico do git, buckets do S3, organizações do GitHub/GitLab (incluindo issues, pull requests e comentários), imagens Docker, Jira, Confluence, Slack e Syslog, cobrindo uma ampla variedade de superfícies onde credenciais podem aparecer.

Limitações: A licença AGPL-3.0 é um impedimento documentado para a adoção por empresas; várias discussões no Hacker News e no Reddit observam que as equipes jurídicas podem rejeitá-la. O TruffleHog também consome muitos recursos em análises de grande escala e é mais lento do que alternativas que usam apenas expressões regulares.

Gitleaks

O Gitleaks (cerca de 25.700 estrelas, Go, MIT) é uma das ferramentas de análise de segredos de código aberto mais usadas. Criado por Zach Rice, oferece análises rápidas e configuráveis por meio de regras personalizadas baseadas em TOML.

Os pontos fortes do Gitleaks são a velocidade e a possibilidade de configuração. Ele é ideal para hooks de pré-commit, nos quais a latência de milissegundos faz diferença. A licença MIT facilita sua adoção por empresas.

A contrapartida são os falsos positivos. O Gitleaks usa correspondência por expressões regulares, sem verificação em tempo real, então sinaliza padrões que parecem segredos, mas não são. Profissionais no r/devsecops recomendam consistentemente executar o Gitleaks primeiro no modo de linha de base e ajustar os falsos positivos sem bloquear o fluxo antes de ativá-lo como uma verificação bloqueante. A regra generic-api-key costuma gerar muito ruído.

Vale destacar que o próprio Zach Rice (u/Phorcez) reconheceu essa contrapartida: “O Gitleaks é leve, rápido e altamente configurável, mas não verifica as credenciais. Para fazer essa verificação, você vai precisar de algo como o TruffleHog ou, melhor ainda, o TruffleHog Enterprise.”

Outras ferramentas de destaque

• Nosey Parker (2.300 estrelas, Rust, Apache 2.0). Desenvolvido pela empresa de pentest Praetorian. Usa um algoritmo de entropia de strings, considerado superior à análise baseada apenas em expressões regulares para detectar segredos genéricos. Rápido e desenvolvido em Rust.

• Kingfisher (876 estrelas, Rust, Apache 2.0). Lançado pela MongoDB em 2025, afirma ser de 2 a 5 vezes mais rápido que o Gitleaks. Adiciona verificação em tempo real e mapeamento do raio de impacto (que acesso uma chave vazada realmente permite?). Derivado do Nosey Parker. Usa tree-sitter para entender o contexto da linguagem. O recurso de raio de impacto é realmente inovador.

• git-secrets (13.200 estrelas, Shell, Apache 2.0). Hook leve baseado em bash, da AWS Labs. Focado em credenciais da AWS e considerado "completo" dentro do seu escopo.

• ggshield (1.900 estrelas, Python, MIT). CLI da GitGuardian com mais de 500 tipos de segredos, integrada a uma plataforma comercial. Em março de 2026, adicionou hooks para assistentes de programação com IA, com suporte a Cursor e Claude.

• Talisman (2.100 estrelas, Go, MIT). Desenvolvido pela ThoughtWorks. É instalado como hook global do Git em todos os repositórios, sendo uma boa opção para aplicar políticas em toda a organização.

• ripsecrets (900 estrelas, Rust, MIT). Hook de pré-commit rápido e especializado, com baixa taxa de falsos positivos graças a regras conservadoras.

O que dizem os benchmarks acadêmicos

Pesquisadores da NC State University publicaram o primeiro estudo comparativo rigoroso de ferramentas de detecção de segredos, usando o conjunto de dados SecretBench (97.479 instâncias classificadas de 818 repositórios). Os resultados são esclarecedores:

• Gitleaks: 88% de revocação (a maior), 46% de precisão

• GitHub Secret Scanner: 75% de precisão (a maior), menor revocação

• TruffleHog: 52% de revocação, precisão intermediária

• Sobreposição entre ferramentas: apenas 76% entre os verdadeiros positivos do ggshield e do TruffleHog. Apenas 18% entre o ggshield e o Gitleaks.

A equipe de pesquisa recomenda explicitamente o uso combinado de várias ferramentas, já que nenhuma das ferramentas avaliadas detectou todos os tipos de segredo. Esses dados reforçam a importância de uma abordagem em camadas.

A abordagem emergente baseada em LLMs

A FuzzingLabs comparou a detecção de segredos baseada em LLMs com ferramentas tradicionais em bases de código reais. Resultado: o GPT-5-mini alcançou 84,4% de revocação, contra 37,5% do Gitleaks. Pesquisas acadêmicas confirmam essa tendência: modelos de código aberto ajustados, como LLaMA-3.1 8B e Mistral-7B, alcançaram pontuações F1 de 0,985 no conjunto de dados SecretBench.

LLMs conseguem detectar padrões que ferramentas baseadas em expressões regulares costumam não encontrar, como segredos divididos (quando uma chave é concatenada a partir de várias variáveis), tokens ofuscados, variáveis decodificadas e credenciais comentadas no código. Essa provavelmente será a próxima geração de ferramentas de detecção.

Uma observação para quem mantém projetos de código aberto

Muitas das ferramentas abordadas neste artigo também são projetos de código aberto, e o ecossistema de soluções para gerenciamento de credenciais continua crescendo. Se você mantém um projeto de código aberto nessa área (ou em qualquer outra), o Snyk Secure Developer Program oferece análise de segurança gratuita de nível empresarial, incluindo SAST, SCA, contêineres e IaC, para projetos de código aberto que atendam aos requisitos. É uma forma de aplicar às próprias ferramentas a mesma abordagem de segurança em camadas que discutimos.

Ferramentas de gerenciamento de segredos: onde os segredos devem ficar?

Detectar segredos vazados resolve apenas uma parte do problema. A outra é garantir que os segredos sejam armazenados e distribuídos com segurança desde o início.

HashiCorp Vault

O Vault (35.300 estrelas) continua sendo o padrão empresarial para gerenciamento de segredos. Seu grande diferencial são os segredos dinâmicos, que geram credenciais de curta duração sob demanda, em vez de armazenar credenciais permanentes. O Vault também oferece criptografia como serviço, PKI e assinatura de certificados SSH.

Dois pontos importantes de contexto: a licença do Vault mudou de MPL para BSL 1.1 em 2023, o que impulsionou o interesse pelo fork comunitário OpenBao. Além disso, a IBM adquiriu a HashiCorp por aproximadamente US$ 6,4 bilhões, e o Vault passou a fazer parte da plataforma da IBM.

Profissionais da área observam que o Vault é poderoso, mas complexo. Um comentário revelador no r/devops: "cerca de 2/3 dos clientes que implementaram [o Vault] por conta própria fizeram isso errado e, na prática, gerenciam segredos de forma equivalente ou menos segura do que se não usassem nada." O Vault funciona melhor quando é tratado como uma questão de infraestrutura, com suporte dedicado de operações.

Infisical

O Infisical (25.600 estrelas, MIT) é a plataforma de gerenciamento de segredos de código aberto que mais cresce. Está unificando gerenciamento de segredos, varredura de segredos e PKI em um único produto, com lançamentos diários. YC W23. Disponível para hospedagem própria ou na nuvem.

Desde a mudança de licença do Vault para BSL, discussões da comunidade mostram um interesse crescente em alternativas com licença MIT. O Infisical oferece recursos empresariais (RBAC, logs de auditoria, separação de ambientes e operador do Kubernetes) e mantém uma licença de código aberto. É frequentemente mencionado junto com Vault e Doppler em discussões da comunidade de 2024 e 2025.

SOPS

O SOPS (21.300 estrelas, MPL 2.0) segue uma abordagem diferente: criptografa segredos diretamente em arquivos YAML, JSON ou ENV e permite que os arquivos criptografados sejam enviados ao Git. Os nomes das chaves continuam legíveis (o que é importante para comparar diferenças e fazer linting), enquanto os valores são criptografados usando AWS KMS, GCP KMS, Azure Key Vault ou age.

O SOPS é frequentemente citado em discussões sobre fluxos de trabalho de GitOps e é uma recomendação comum em conversas do tipo "como vocês gerenciam segredos?". Combinado com direnv para desenvolvimento local, é uma opção prática para equipes que querem armazenar segredos com segurança no controle de versão.

Outras ferramentas de gerenciamento

• Doppler: SaaS comercial frequentemente recomendado em discussões recentes da comunidade. Gerenciamento de segredos sem infraestrutura própria, com separação de ambientes.

• 1Password CLI (op run): injeta segredos em tempo de execução sem gravá-los no disco. A autenticação biométrica (solicitação do Touch ID antes da injeção do segredo) é uma melhoria significativa de segurança em relação a arquivos estáticos.

• dotenvx (5.300 estrelas): criado pelo autor do dotenv original. Arquivos .env.vault criptografados, que conectam padrões simples de desenvolvimento ao gerenciamento adequado de segredos.

• External Secrets Operator (6.500 estrelas): o padrão de fato do Kubernetes para sincronizar segredos de mais de 30 fontes externas.

Como criar uma defesa em camadas: um guia prático

Nenhuma ferramenta ou prática isolada impede todos os vazamentos de credenciais. O consenso do setor, refletido no Reddit, no Hacker News, na OWASP e em pesquisas acadêmicas, é adotar uma defesa em camadas:

Camada 1: hooks de pré-commit (detecção antes do commit)

Instale uma ferramenta de varredura de segredos (como Gitleaks, ggshield ou TruffleHog) como hook de pré-commit. Isso oferece o ciclo de feedback mais rápido e detecta a maioria dos commits acidentais.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Importante: é possível ignorar hooks de pré-commit no lado do cliente (--no-verify). Para uma aplicação mais rigorosa, implemente hooks de pré-recebimento no servidor para bloquear, no nível do repositório, envios que contenham segredos.

Ao implementar a varredura pela primeira vez, use o modo de linha de base: analise todo o histórico do repositório, reconheça os resultados existentes e, a partir daí, alerte apenas sobre novos segredos. Isso evita que o cansaço causado por falsos positivos prejudique a adoção.

Camada 2: varredura de CI/CD (detecção do que passou pelo pré-commit)

Adicione uma etapa de varredura ao pipeline de CI. Ferramentas compatíveis com a verificação de credenciais (como a flag --only-verified do TruffleHog) podem reduzir o ruído ao confirmar se as credenciais detectadas ainda estão ativas:

# Example using TruffleHog
trufflehog git file://. --only-verified --fail

Essa camada detecta segredos que passaram pelos hooks de pré-commit (hooks desativados, commits combinados, pushes forçados ou contribuições de forks).

Camada 3: cofre centralizado de segredos (elimine a origem dos vazamentos)

Remova completamente os segredos de arquivos .env, variáveis de ambiente e arquivos de configuração. Use um gerenciador de segredos dedicado para injetá-los em tempo de execução:

• Ambientes AWS: AWS Secrets Manager ou SSM Parameter Store com funções do IAM

• Multicloud: Vault, Infisical ou Doppler

• Kubernetes: External Secrets Operator para sincronizar segredos do cofre que você escolher

• Equipes pequenas: SOPS + age para configurações criptografadas ou dotenvx para arquivos .env criptografados

O gerenciador de segredos deve ser a única fonte da verdade, não uma cópia adicional ao lado de segredos que continuam em arquivos .env, variáveis de CI e wikis da equipe.

Camada 4: OIDC para CI/CD (elimine totalmente as credenciais estáticas)

Uma mudança de arquitetura que vale a pena avaliar: substituir credenciais estáticas de CI/CD por identidade federada baseada em OIDC.

# GitHub Actions example - no stored AWS credentials
permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-arn: arn:aws:iam::123456789:role/deploy
      aws-region: us-east-1

Esse padrão usa o provedor OIDC do GitHub para solicitar credenciais AWS de curta duração por meio de AssumeRoleWithWebIdentity. Não é preciso armazenar chaves de acesso do IAM. O consenso da comunidade no Hacker News e no r/devops é claro: credenciais estáticas nos GitHub Secrets são uma prática obsoleta.

Play Video: YouTube Video: 5xngh29yx9A

Camada 5: varreduras periódicas de todo o histórico (detecção de vazamentos antigos)

Programe varreduras regulares de todo o histórico dos repositórios da sua organização. Isso ajuda a encontrar:

• Segredos enviados antes da implementação da varredura

• Segredos em commits excluídos e objetos Git sem referência

• Repositórios antigos que passaram de privados a públicos

Várias ferramentas oferecem varredura em toda a organização. Por exemplo, o TruffleHog pode analisar uma organização inteira do GitHub:

trufflehog github --org=your-org --only-verified

Camada 6: design do formato dos tokens (torne os segredos identificáveis)

Se você desenvolve APIs, projete tokens que possam ser identificados. A reformulação do formato de token do GitHub em 2021, com prefixos conhecidos como ghp_ e somas de verificação incorporadas, melhorou significativamente a precisão da varredura. O prefixo sk_live_ da Stripe é um exemplo clássico.

Tokens identificáveis potencializam todas as ferramentas de varredura do ecossistema. Um gerente de produto do GitHub incentivou explicitamente todos os provedores de serviços a adotar esse padrão.

Quando segredos vazam: resposta a incidentes

Mesmo com todas as camadas implementadas, vazamentos acontecem. Siga este protocolo de resposta:

1. Revogue imediatamente. Não perca tempo discutindo nem investigue antes. Revogue a credencial e gere outra. Bots automatizados de detecção analisam a API do GitHub poucos minutos após um push público.

2. Verifique os logs de auditoria. Consulte o CloudTrail, o GCP Audit Logs ou ferramentas equivalentes para identificar qualquer uso não autorizado da credencial exposta.

3. Avalie o raio de impacto. Que acesso a credencial permitia? Que dados poderiam ter sido acessados?

4. Limpar o histórico é uma medida secundária. Use git filter-repo ou BFG Repo-Cleaner para remover o segredo do histórico do Git, se houver exigência de conformidade. A rotação elimina o risco de segurança, enquanto a limpeza do histórico atende a requisitos de conformidade e higiene. Se um segredo ficou público por qualquer período, considere-o comprometido, mesmo que o histórico seja limpo.

O consenso entre profissionais no r/devsecops é: revogue o segredo (tornando o histórico inofensivo) e só limpe o histórico se houver exigência de conformidade. Algumas organizações chegam a manter no histórico as credenciais revogadas como indicadores de honeypot.

A realidade jurídica: vazamentos de credenciais têm consequências

O panorama jurídico da segurança de credenciais mudou bastante. Estes casos mostram por que o gerenciamento de credenciais é uma questão crítica para os negócios:

United States v. Sullivan (9th Cir. 2025). O diretor de segurança da Uber foi condenado criminalmente por obstrução da justiça e omissão de crime, por ocultar uma violação causada por credenciais AWS gravadas diretamente em repositórios do GitHub. Os invasores encontraram as credenciais e acessaram um armazenamento S3 com dados de 57 milhões de usuários. A equipe de Sullivan pagou US$ 100 mil aos invasores pelo programa de recompensas por bugs sem revelar a violação. O 9º Circuito manteve a condenação, estabelecendo que executivos podem responder criminalmente por ocultar violações envolvendo credenciais.

Capital One (2022). Um ex-engenheiro da AWS explorou uma vulnerabilidade SSRF para roubar credenciais de metadados do IAM na nuvem, o que permitiu acessar dados de aproximadamente 100 milhões de clientes. A ação coletiva cível resultou em um acordo de US$ 190 milhões.

Ações de fiscalização da FTC. Após FTC v. Wyndham (3d Cir. 2015) (73 citações), os acordos firmados com a FTC passaram a exigir rotineiramente programas obrigatórios de rotação de credenciais, verificação de segredos em repositórios de código e a proibição de incluir credenciais diretamente no código-fonte. A FTC firmou acordos em ações de fiscalização contra Uber, Meta e outras empresas por falhas na segurança de credenciais.

SEC v. SolarWinds (S.D.N.Y., 2023). A SEC apresentou acusações alegando que a SolarWinds informou incorretamente os investidores sobre suas práticas reais de gerenciamento de segredos. As principais alegações sobreviveram à decisão de rejeição parcial, ampliando a responsabilidade por violações para o âmbito do direito mobiliário.

A violação de dados da Equifax, causada por falhas em credenciais e controles de acesso, resultou em um acordo de US$ 700 milhões com a FTC, o maior acordo sobre segurança de dados da história da FTC.

6 princípios fundamentais

Estas observações vêm da OWASP, de pesquisas acadêmicas e de discussões entre profissionais:

1. Repositórios privados contêm mais segredos do que os públicos. A GitGuardian descobriu que repositórios privados têm 6 vezes mais chances de conter segredos incluídos diretamente no código do que os públicos. Repositórios privados são clonados, bifurcados, acessados por prestadores de serviços e, às vezes, tornados públicos.

2. Segredos commitados permanecem no histórico do Git. Mesmo que sejam excluídos no commit seguinte ou que o repositório seja privado. Como o modelo de dados do Git é apenas de acréscimo, qualquer credencial commitada deve ser considerada exposta.

3. A cobertura das ferramentas varia. Testes acadêmicos de referência mostram uma sobreposição de apenas 18% a 76% entre os verdadeiros positivos identificados pelas ferramentas. Usar várias ferramentas em diferentes camadas amplia a cobertura.

4. A rotação de credenciais reduz o risco; a limpeza do histórico atende aos requisitos de conformidade. Revogar a credencial torna inofensivo o histórico do Git. Limpar o histórico sem fazer a rotação não resolve o problema.

5. A detecção, por si só, tem valor limitado sem ações posteriores. 64% dos segredos vazados em 2022 ainda estavam ativos em 2026. Organizações que detectam vazamentos, mas não os corrigem, continuam expostas ao mesmo risco.

6. As estações de trabalho de desenvolvedores são uma superfície de ataque cada vez maior. Ataques à cadeia de suprimentos, ferramentas de programação com IA que acessam arquivos e injeções de prompt direcionadas a servidores MCP criam caminhos para o roubo de credenciais em máquinas locais. A pesquisa da Snyk sobre agentes de programação com IA usados em ataques aborda essa nova superfície de ataque.

Por onde começar

A defesa em camadas descrita acima pode parecer muita coisa para implementar de uma só vez. A boa notícia é que cada camada oferece benefícios por conta própria, e você pode adotá-las gradualmente.

• Comece pela visibilidade — Antes de corrigir vazamentos de credenciais, você precisa saber onde eles estão. Adicione um gancho de verificação antes do commit (ferramentas como Gitleaks, ggshield e TruffleHog oferecem esse recurso) para detectar novos vazamentos. Em seguida, faça uma verificação em toda a organização, com validação de credenciais, para entender sua exposição atual. Se você já usa Snyk Code para SAST, combine-o com uma ferramenta dedicada à detecção de segredos para cobrir tanto as vulnerabilidades no código quanto a exposição de credenciais.

• Audite seus .env arquivos e segredos de CI/CD — Verifique se há credenciais reais no controle de versão, mesmo em repositórios privados. Troque todas as credenciais que tenham sido commitadas. Revise os pipelines de CI/CD em busca de credenciais estáticas que possam ser substituídas por uma identidade federada baseada em OIDC.

• Avalie sua estratégia de gerenciamento de segredos — Se sua equipe ainda compartilha credenciais por meio de arquivos .env ou define variáveis de ambiente manualmente, considere opções centralizadas como Infisical, Vault ou Doppler, que injetam segredos durante a execução.

• Proteja seus fluxos de trabalho de desenvolvimento com IA — Se sua equipe usa assistentes de programação com IA ou servidores MCP, revise essas configurações para encontrar credenciais incluídas diretamente no código. A integração do servidor MCP da Snyk pode verificar código gerado por IA em tempo real, e Snyk Open Source ajuda a detectar dependências comprometidas antes que elas cheguem à sua base de código (o mesmo vetor da cadeia de suprimentos usado para distribuir malware que rouba credenciais).

• Promova a conscientização em toda a organização — Tanto as ferramentas quanto as práticas da equipe contribuem para um gerenciamento eficaz de credenciais. A plataforma de segurança para desenvolvedores da Snyk integra SAST, SCA, segurança de contêineres e verificação de IaC aos fluxos de trabalho de desenvolvimento, oferecendo às equipes uma visão unificada da postura de segurança. Quando os desenvolvedores conseguem ver os problemas de segurança nos ambientes em que já trabalham, a adoção acontece naturalmente.

A resposta mais votada no HN foi sincera. Muitas organizações realmente gerenciam mal suas credenciais. Mas nunca foi tão fácil acessar ferramentas, práticas e conhecimentos da comunidade para fazer melhor.

Seus aplicativos Python estão preparados para o aumento de vazamentos de segredos e dos riscos de exposição de credenciais impulsionados pela IA, destacados acima? Baixe o whitepaper A crise de segurança da IA no seu ambiente Python e descubra como as equipes de ponta estão protegendo os fluxos de trabalho de desenvolvimento com IA.