Documentação

Segredos vazados

Como o módulo Segurança identifica credenciais em alterações e no histórico sem armazená-las, por que um segredo vazado só é fechado quando alguém confirma sua rotação e como corrigir esse problema.

Uma credencial que chegou a um commit enviado já está vazada, mesmo que um commit posterior a remova. O módulo Segurança identifica credenciais nas suas alterações e no histórico, não armazena nenhuma delas e trata cada uma como aberta até que alguém confirme que foi rotacionada ou revogada.

O que é escaneado

  • Toda alteração: as alterações de cada pull request, como parte do Coroid Security check, e as alterações dos próprios agentes do Coroid antes de serem commitadas.
  • O branch padrão: cada envio e uma vez ao longo de todo o seu histórico. O escaneamento do histórico começa quando um repositório é conectado ou quando o recurso Segredos vazados é ativado.
  • Branches de pull request: uma credencial enviada para um branch do pull request também gera uma ocorrência, pois já está no repositório.

Um branch enviado sem um pull request não é escaneado.

O escaneamento do histórico lê todos os commits acessíveis, do mais recente para o mais antigo, e lê cada versão de arquivo uma única vez. Ele funciona em fatias e retoma de onde parou. Cada repositório tem limites para a quantidade de histórico lido (commits, bytes, tempo e tamanho de arquivo); repositórios que ultrapassam esses limites apresentam cobertura parcial.

O que é detectado

Credenciais de provedores em seus formatos conhecidos (chaves de acesso da AWS, tokens do GitHub e GitLab, chaves da OpenAI e outras), tokens de autorização, credenciais atribuídas a nomes como password ou api_key, chaves privadas, credenciais dentro de URLs e strings longas de alta entropia. Credenciais atribuídas no código são identificadas apenas quando o valor é um literal, e não uma variável ou chamada de função.

Coroid nunca armazena o valor

Um valor detectado vai diretamente do detector para o corretor de credenciais do Coroid, que retorna uma impressão digital criptografada e descarta o valor. Apenas a impressão digital é armazenada. Ela é vinculada por organização, portanto não pode ser comparada entre organizações ou adivinhada offline.

Em todos os lugares onde um segredo apareceria normalmente (ocorrências, verificações, comentários de revisão, logs), o Coroid mostra apenas a regra, o comprimento e o local, por exemplo [redacted secret: named_credential, 40 characters]. Nenhuma parte do valor é exibida, nem mesmo seus primeiros caracteres.

Coroid nunca tenta usar uma credencial encontrada para verificar se ela funciona.

Uma credencial, uma ocorrência

Uma credencial vista em muitos commits corresponde a uma ocorrência com várias instâncias. A mesma credencial em dois repositórios gera duas ocorrências, uma por repositório. Quando você confirma uma delas, o módulo Segurança lista as demais com a mesma credencial para que você possa confirmá-las juntas. Ele nunca faz isso por conta própria.

Um segredo só é fechado por meio de confirmação

Remover uma credencial do código torna suas ocorrências inexistentes, mas a ocorrência permanece aberta: quem leu o repositório anteriormente pode ainda tê-la. Ela só é fechada quando um proprietário ou administrador confirma as medidas tomadas:

  • Rotacionada ou revogada;
  • a data em que isso foi feito;
  • uma observação opcional.

O módulo Segurança registra quem confirmou e quando, e exibe essa informação na ocorrência: "Rotacionada em 28 de outubro, confirmada por Alex em 29 de outubro". A ocorrência passa para Rotação confirmada.

Corrigindo um segredo vazado

Criar a tarefa da lista de verificação arquiva uma tarefa no projeto com estas etapas:

  1. Rotacione ou revogue a credencial no provedor.
  2. Mova-a para onde o projeto armazena seus segredos.
  3. Remova-a do código.
  4. Confirme a rotação no módulo Segurança.

A tarefa nunca se repete nem tenta usar a credencial. Ela não reescreve o histórico do Git: remover uma credencial do histórico é uma decisão da sua equipe e não torna um segredo vazado novamente seguro.

Credencial real ou não é um problema

Em uma ocorrência de segredo, proprietários e administradores respondem Essa era uma credencial real?

  • Credencial real mantém a ocorrência aberta até que seja confirmada.
  • Não é um problema registra uma exceção de falso positivo que oculta a ocorrência, por exemplo para um fixture de teste. Credencial real remove essa exceção novamente.

Essas respostas também ajudam a calibrar os detectores.

Bloqueio

O recurso Segredos vazados opera em modo de observação por padrão. Ele bloqueia apenas após os detectores passarem pela calibração e o reforço estar ativado. Consulte Proteções e reforço.

As organizações que tinham a varredura de segredos anterior ativada em sua política de organização continuarão sendo bloqueadas por ela, com a versão do seu detector, até que os novos detectores passem pela calibração. Essa varredura anterior não gera achados, portanto uma exceção ou atestado não pode ocultar o que ela bloqueia.

Na configuração padrão da organização, Bloquear novos segredos e as alterações maiores escaneadas são listadas em Segredos vazados.

Notificações

Os achados de segredos ainda não enviam notificações. Eles aparecem em Segurança → Achados e em Visão geral.

GitHub varredura de segredos

Se a varredura de segredos própria do GitHub estiver ativada para um repositório, a Segurança poderá importar seus alertas. Um alerta de varredura de segredos do GitHub permanece aberto até que alguém o resolva no GitHub, portanto a incorporação de uma correção não o fecha lá. Veja Alertas de segurança do GitHub.