Secret scanning

O que é a varredura de segredos?

O secret scanning, ou varredura de segredos, é a prática automatizada de examinar código, configurações, infraestrutura, pipelines e outros lugares onde as equipes armazenam e compartilham informações sobre software, a fim de encontrar credenciais expostas. Um programa confiável vai além de executar um regex em um repositório: ele informa o que foi encontrado, se o valor ainda está ativo, onde ele aparece, quem precisa agir sobre ele e com que rapidez.

Segredos não são o mesmo que dados sensíveis

Vale a pena acertar essa distinção desde o início, porque ela molda a forma como as equipes pensam tanto a detecção quanto a resposta. Dados sensíveis (p. ex., o número do cartão de crédito de um cliente, um identificador nacional, um histórico médico) descrevem informações sobre pessoas que precisam ser protegidas. Segredos, por outro lado, são credenciais ou chaves que concedem acesso a diferentes sistemas. Uma chave de API de um provedor de pagamentos é um segredo; o número do cartão que essa chave ajuda a processar é um dado sensível. Ambos merecem proteção, mas têm modelos de ameaça e abordagens de gestão de segurança distintos.

Os valores que a varredura de segredos procura tendem a se enquadrar em um conjunto familiar: senhas, chaves de API, chaves de acesso à nuvem, chaves privadas SSH, tokens OAuth, strings de conexão com banco de dados, chaves de criptografia, certificados de segurança e URLs de webhook, que muitas vezes concedem acesso suficiente para merecer o mesmo tratamento. Muitos têm formatos reconhecíveis; por exemplo, uma chave da Stripe começa com um prefixo conhecido, uma chave de acesso da AWS segue um formato fixo, e uma chave privada fica entre linhas previsíveis de cabeçalho e rodapé.

Por exemplo, uma chave privada SSH poderia ter esta aparência:

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

Esses padrões ajudam, mas não são suficientes por si só; a detecção moderna precisa lidar com uma variedade muito maior.

Por que ocorrem exposições de segredos?

A história típica é mundana: um desenvolvedor codificou um token diretamente para testar uma integração localmente e pretendia removê-lo antes de fazer push. Uma equipe com pouco tempo decidiu: "Vamos mover isso para o vault (cofre) no próximo sprint." Um novo engenheiro não sabia que o cofre existia. Um assistente de codificação de IA produziu um exemplo funcional de integração de API com uma credencial de placeholder; o desenvolvedor inseriu uma chave real para fazê-lo funcionar, e o arquivo foi "commitado".

Então o valor se propaga. Uma vez que uma credencial cai no histórico de um repositório, removê-la da versão mais recente de um arquivo não desfaz a exposição. A string continua viva em commits anteriores, em branches que ainda não foram mescladas, em clones nos laptops de outras pessoas, em forks espelhados. Se o repositório for público, rastreadores automatizados provavelmente o encontrarão em minutos — plataformas de busca, agentes maliciosos e pesquisadores de segurança executam seus próprios scanners em hosts Git públicos, procurando exatamente isso. Se o repositório for privado, qualquer pessoa com acesso de leitura, inclusive colaboradores antigos, ainda pode recuperá-la.

O código está longe de ser a única fonte. Arquivos de configuração, pipelines de CI/CD, imagens de contêiner, manifests do Kubernetes, estado do Terraform, charts do Helm, scripts de implantação, logs de execução, plataformas de observabilidade como Datadog, canais do Slack, tickets do Jira, páginas do Confluence e documentação de onboarding podem todos conter credenciais que nunca deveriam ter ficado ali.

Aqui está um exemplo pequeno e bem comum — um job de backup escrito como um script shell rápido:

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

Nada neste script parece incomum à primeira vista — ele faz o trabalho. Mas qualquer pessoa com acesso ao arquivo (ou ao artefato de build em que ele termina, ou ao log da execução) obtém duas credenciais da AWS e uma via de acesso ao bucket de backups de produção. Um scanner que examina o arquivo sinaliza ambas as chaves: a chave de acesso pelo prefixo AKIA e a chave secreta de acesso pelo valor de alta entropia após uma atribuição AWS_SECRET_ACCESS_KEY.

Por que isso importa no nível do negócio?

Os atacantes procuram credenciais expostas porque elas funcionam. Uma chave de nuvem vazada pode criar recursos, exfiltrar dados ou executar mineradores de criptomoeda às custas de outra pessoa. Uma senha de banco de dados vazada pode levar à divulgação de uma violação. Um token de acesso de uma plataforma Git vazado pode permitir que um atacante injete código em um repositório ou adultere um pipeline de CI (um incidente de cadeia de suprimentos em gestação). Uma URL de webhook vazada pode ser suficiente para disparar fluxos de trabalho internos ou para ler mensagens que não deveriam ser vistas por olhos externos.

As consequências a jusante são familiares a qualquer pessoa que já tenha passado por perto de um incidente: tomada de conta, uso não autorizado de recursos em nuvem, violações de dados, movimento lateral, comprometimento da cadeia de suprimentos, interrupção de serviço e os custos financeiros que vêm com tudo isso. Estruturas regulatórias adicionam outra camada: PCI DSS, GDPR, HIPAA, SOX, FISMA e CCPA impõem requisitos quanto a controles de acesso e ao tratamento de credenciais e dados de clientes. Um padrão recorrente de segredos expostos é difícil de defender durante uma auditoria e ainda mais difícil depois de uma violação.

Para executivos, o cálculo é simples. A varredura de segredos é relativamente barata de executar; o custo de um incidente impulsionado por credenciais (isto é, perícia forense, notificação, remediação, perda de confiança, possíveis multas) geralmente não o é.

Como funciona a varredura de segredos?

Frequentemente, várias técnicas são usadas em conjunto. Cada uma tem forças e modos de falha conhecidos, razão pela qual nenhuma ferramenta séria depende apenas de uma delas.

As expressões regulares (também conhecidas como regex) são a abordagem mais antiga. Uma regra descreve a forma de um tipo específico de credencial (p. ex., uma chave da Stripe, uma chave de acesso da AWS, um bloco de chave privada, um JWT) e o scanner procura por correspondências. Isso funciona bem quando os provedores publicam formatos estáveis e mal quando não o fazem, e produz falsos positivos sempre que uma string por acaso parece uma credencial sem ser uma.

A análise de entropia pergunta a questão oposta: não "isso corresponde a um formato conhecido?", mas "isso parece aleatório?". Segredos gerados por um CSPRNG têm entropia de Shannon mensuravelmente alta. O mesmo acontece com hashes, identificadores e blobs codificados em base64 — e aí está o problema.

Os dicionários e as bibliotecas de padrões reduzem parte dessa ambiguidade ao comparar valores e textos ao redor com catálogos de tipos de credenciais conhecidos e com convenções de nomenclatura. Uma string de alta entropia atribuída a uma variável chamada password em um arquivo de implantação de produção é tratada de maneira muito diferente da mesma string em uma fixture de testes.

A análise contextual vai ainda mais longe, examinando caminhos de arquivo, comentários, mensagens de commit e o código ao redor para determinar quanto peso atribuir a uma descoberta. O machine learning, treinado com exemplos rotulados, pode captar sinais mais sutis que regras fixas deixam passar (p. ex., formatos estranhos de tokens, colocações incomuns e padrões de como uma determinada equipe tende a vazar dados).

Considere o que uma varredura em camadas poderia revelar em um trecho de código Python:

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

Três credenciais em poucas linhas: uma chave de API da OpenAI com o prefixo sk-proj- (correspondência por regex), um SID da Twilio com seu formato conhecido (regex mais dicionário) e um token de autenticação (entropia mais um nome de variável no dicionário). O comentário TODO é o tipo de sinal contextual que aumenta ainda mais a confiança — os humanos deixam rastros quando planejam consertar algo depois e se esquecem.

Ferramentas robustas combinam esses métodos. A varredura híbrida executa regex, entropia, dicionários, contexto e ML em conjunto, aproveitando os pontos fortes de cada método para compensar as fraquezas dos demais. É também aí que um segredo ofuscado ou dividido (um token reconstituído a partir de duas variáveis, por exemplo, ou uma chave codificada em base64) tem mais chance de ser detectado.

Algumas ferramentas dão um passo além: validação em tempo real. Depois de sinalizar um candidato, o scanner realiza uma chamada segura ao provedor correspondente para verificar se a credencial ainda está ativa. O ponto não é confirmar todas as ocorrências; é fazer triagem. Uma chave AWS de produção ativa com permissões de administrador deve ficar no topo da fila; um token de teste expirado de dois anos atrás não deve.

Onde procurar por segredos?

Código-fonte é o ponto de partida óbvio, mas um programa que para aí vai perder a maior parte da superfície de exposição. A varredura deve abranger todas as branches, não apenas a padrão, e deve examinar o histórico de commits, porque um segredo removido do arquivo atual ainda pode existir em commits anteriores, clones e forks.

Recursos de configuração e implantação são a próxima prioridade. Arquivos .env, configurações YAML, manifests do Kubernetes, charts do Helm, Terraform, Dockerfiles e definições de pipeline de CI/CD acumulam credenciais com frequência. Imagens de contêiner as armazenam em camadas que sobrevivem muito depois que a fonte foi limpa. Um manifesto simples do Kubernetes é ilustrativo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

Duas exposições em oito linhas (uma string de conexão com banco de dados e uma chave ativa da Stripe), ambas comprometidas em um manifesto que provavelmente acaba no controle de versão e em um registro de contêiner. Um scanner captura a chave da Stripe pelo prefixo sk_live_ e a URL do banco de dados pela sua estrutura.

Além da infraestrutura, segredos aparecem em ferramentas de colaboração (p. ex., mensagens no Slack e no Teams, tickets do Jira, páginas do Confluence, plataformas de suporte) e em sistemas de observabilidade, onde rastreamentos de pilha e logs de depuração às vezes incluem cabeçalhos de autorização ou despejos de ambiente. Repositórios de artefatos, backups e armazenamentos de dados podem conter builds e snapshots antigos com credenciais que ninguém se lembrou de rotacionar.

Dois modos de varredura cobrem esse terreno. Varreduras em repouso focam o risco acumulado em locais estáticos e históricos; varreduras em tempo real examinam novos commits, pull requests, execuções de CI, tickets e mensagens de chat à medida que ocorrem. Ambos importam: a linha de base histórica mostra onde você está, e os controles em tempo real impedem que as coisas piorem.

Colocando a varredura no fluxo de desenvolvimento

A varredura de segredos funciona melhor como um controle contínuo, não como uma auditoria trimestral; quanto mais cedo uma credencial é detectada, menor o custo de remediação.

Hooks de pre-commit são executados na máquina do desenvolvedor e avisam antes que um segredo saia do ambiente de trabalho. A proteção de push fica do lado da plataforma e bloqueia pushes que contêm achados de alta confiança. Verificações de pull request sinalizam (ou bloqueiam) credenciais antes que sejam mescladas, muitas vezes com comentários inline. A integração com CI/CD varre builds, scripts de implantação e artefatos como parte do pipeline. Plugins de IDE podem fornecer feedback enquanto o código é escrito.

Descobertas que passam por esses controles ou que surgem de varreduras em repouso de material histórico precisam de um processo de triagem. Classificar por tipo de credencial, validade, local, idade, permissões, ambiente e impacto no negócio permite que as equipes de segurança distribuam o trabalho com eficiência. A automação cuida do encaminhamento; as pessoas lidam com casos ambíguos e padrões recorrentes que sugerem algo mais profundo do que um erro pontual.

Respondendo quando um segredo é encontrado

A primeira pergunta é o que a credencial realmente permite. Um token de análise somente leitura, uma senha de serviço interno, uma chave administrativa de nuvem e um valor de teste expirado há muito tempo ocupam pontos muito diferentes na curva de risco. Identifique o serviço, o ambiente, as permissões e o tempo de exposição, assim como se o valor estava visível publicamente ou restrito a sistemas específicos.

Depois, revogue ou rotacione. Na maioria dos casos, a rotação é o caminho mais limpo: invalide o valor antigo, gere um novo e atualize os consumidores para usá-lo. Se o segredo já foi público em algum momento, assuma que ele foi copiado. Remover o texto de um arquivo não é suficiente; a exposição já aconteceu.

A investigação ocorre em paralelo. Logs, trilhas de auditoria e registros de atividade do lado do provedor podem indicar se a credencial foi usada de maneiras inesperadas, a partir de locais incomuns ou contra recursos incomuns. Se as permissões eram amplas, a revisão precisa se estender aos sistemas downstream. O privilégio mínimo limita o raio de impacto, mas apenas quando a credencial exposta já tinha privilégios limitados desde o início.

A limpeza vem depois. Remova o valor do código, da configuração, da documentação, dos logs e de qualquer outro lugar em que ele apareça. Se ele foi parar no histórico do Git, pode ser necessário reescrever o histórico, além de invalidar caches e comunicar a qualquer pessoa que possa ter clonado o repositório. Depois, documente o incidente (o que aconteceu, quando foi detectado, o que foi feito, o que deve mudar) para fins de auditoria e para o aprendizado da própria equipe.

A varredura é uma camada; a gestão de segredos é a base

Vale repetir porque isso muitas vezes se confunde: a varredura de segredos é uma camada de detecção, não uma substituta da gestão de segredos. Credenciais devem ser armazenadas em gerenciadores de segredos dedicados (p. ex., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) e recuperadas em tempo de execução por meio de APIs, em vez de serem "commitadas" junto com o código que as utiliza.

Variáveis de ambiente geralmente são mais seguras do que valores codificados, mas não são a linha de chegada. Elas ainda podem vazar por logs, mensagens de erro, endpoints de depuração, despejos de artefatos e arquivos .env que acabam em commits. Arquivos de segredos locais devem estar em .gitignore, e os desenvolvedores se beneficiam de orientações escritas claras sobre configuração local segura.

O privilégio mínimo é a outra metade do quadro. Uma credencial deve conceder apenas o que precisa, expirar quando possível, ser rotacionada segundo um cronograma e ser registrada sempre que usada. Uma política que codifica essas expectativas (o que conta como segredo, onde a varredura é executada, como as descobertas são triadas, quem é o responsável pela remediação e quais prazos se aplicam por severidade) transforma uma prática ad hoc em algo que uma organização pode auditar e melhorar.

A educação fecha o ciclo. Desenvolvedores e engenheiros de plataforma se beneficiam de entender por que hardcoding é arriscado, como o histórico do Git realmente funciona e o que fazer quando cometem um erro. Auditorias manuais e testes de invasão preenchem lacunas que as ferramentas automatizadas deixam passar.

Limitações que vale a pena admitir com honestidade

A varredura de segredos produz falsos positivos. Identificadores que parecem aleatórios, hashes, dados de exemplo e valores de placeholder são sinalizados. Alarmes demais levam à fadiga de alertas, o que, por sua vez, leva a alertas ignorados. Ela também produz falsos negativos: um scanner pode deixar passar uma credencial dividida entre arquivos, codificada, em um formato desconhecido ou enterrada em uma estrutura de dados que o parser não entende bem.

A exposição histórica é ainda mais difícil. Um segredo commitado uma vez e "removido" depois ainda vive no histórico de commits, em clones, forks, backups e artefatos de build. É por isso que bloquear um vazamento no momento do commit vale mais do que detectá-lo depois.

A precisão é um equilíbrio entre "precision" (a maioria dos valores sinalizados é de segredos reais) e "recall" (poucos segredos reais são perdidos). A maioria das organizações prefere investigar alguns falsos positivos a perder uma credencial que confere acesso à produção. Ajustar as regras ao stack da organização (seus provedores de nuvem reais, formatos internos de tokens, convenções de dados de teste) é o que eleva ambos os números ao mesmo tempo.

Escolhendo uma ferramenta e onde ela se encaixa em AppSec

Quatro dimensões importam ao escolher um scanner: cobertura, integração, qualidade de detecção e relatórios.

Cobertura significa varrer os lugares onde os segredos realmente aparecem: repositórios, IaC, CI/CD, contêineres, artefatos, ferramentas de colaboração e logs. Integração significa funcionar com as plataformas de origem, sistemas de build, IDEs e ferramentas de segurança já em uso, junto com caminhos de feedback amigáveis ao desenvolvedor (avisos no IDE, varreduras via CLI, comentários em PR, hooks de pre-commit) e fluxos de trabalho da equipe de segurança (dashboards, atribuição, status, evidências, trilhas de auditoria).

A qualidade de detecção vem de métodos em camadas, personalização para padrões internos e, quando apropriado, ML e validação em tempo real. Os relatórios devem produzir os artefatos que uma auditoria de conformidade solicitará e as métricas que um líder de segurança precisa acompanhar para medir a saúde do programa.

A varredura de segredos fica ao lado de outras práticas de AppSec, em vez de substituí-las. SAST procura padrões de codificação inseguros; SCA encontra vulnerabilidades conhecidas e problemas de licença em dependências; DAST e teste de penetração avaliam sistemas em execução. A varredura de segredos aborda uma classe distinta de risco — as credenciais que conectam o software a tudo ao seu redor — e as categorias se complementam. Por exemplo, uma ferramenta de SAST pode sinalizar um código de autenticação inseguro em um serviço, enquanto a varredura de segredos encontra o token ativo codificado no mesmo arquivo.

Conclusão

O software moderno depende de credenciais, e estas podem acabar em lugares onde não deveriam estar. A varredura de segredos as encontra — cedo, quando possível, e historicamente, quando necessário — e alimenta as descobertas em um processo que revoga, rotaciona, investiga e limpa. Ela funciona melhor com cobertura ampla, controles em tempo real que bloqueiam vazamentos antes que se espalhem, detecção precisa por múltiplos métodos, validação segura para priorizar credenciais ativas e uma base sólida de gestão de segredos subjacente. Para um líder de segurança ou de desenvolvimento, a pergunta é se a configuração atual detecta credenciais antes que elas se propaguem, se cobre os pontos onde os vazamentos realmente ocorrem e se a organização tem um local mais seguro para que essas credenciais sejam mantidas.