Sobre os tipos de alertas
Há três tiposalertas de escaneamento de segredos:
- Alertas para os usuários: Relatados aos usuários na Security and quality guia do repositório, quando um segredo suportado é detectado no repositório.
- Alertas de proteção por push: Relatado aos usuários na Security and quality aba do repositório, quando um colaborador ignora a proteção por push.
- Alertas do parceiro: Relatados diretamente aos provedores confidenciais que fazem parte do programa de parceiros do secret scanning. Esses alertas não são relatados na Security and quality guia do repositório.
Sobre alertas do usuário
Quando você habilita a secret scanning para um repositório ou envia commits por push a um repositório com a secret scanning habilitada, o GitHub verifica o conteúdo em busca de segredos que correspondam aos padrões definidos pelos provedores de serviço.
Quando a secret scanning detectar um segredo, o GitHub gerará um alerta. GitHub exibe um alerta na Security and quality guia do repositório. Se o mesmo segredo for exibido várias vezes em um único arquivo, somente um alerta será criado.
Para ajudá-lo a fazer a triagem de alertas com mais eficiência, GitHub separa os alertas em duas listas:
- Alertas padrão
- Alertas genéricos
Lista de alertas padrão
A lista de alertas padrão exibe alertas relacionados a padrões compatíveis e padrões personalizados especificados. Esta é a exibição principal para alertas.
Lista de alertas genéricos
A lista de alertas genéricos exibe alertas relacionados a padrões não provedores (como chaves privadas) ou segredos genéricos detectados usando IA (como senhas). Esses tipos de alertas possuem uma taxa maior de falsos positivos ou segredos usados em testes. Você pode alternar da lista de alertas padrão para a lista de alertas genéricos.
GitHub continuará a adicionar novos padrões e tipos de segredos à lista de alertas genéricos e os promoverá para a lista padrão quando estiverem completos em termos de funcionalidade (ou seja, quando tiverem um volume adequadamente baixo e uma taxa de falsos positivos).
Além disso, os alertas que se enquadram nessa categoria:
- São limitados em quantidade a cinco mil alertas por repositório (isso inclui alertas abertos e fechados).
- Não são mostrados nas visões resumidas para a visão geral de segurança, somente na visão "Secret scanning".
- Apenas os cinco primeiros locais detectados são exibidos GitHub para padrões que não são de provedor, e apenas o primeiro local detectado é exibido para segredos genéricos detectados por IA.
Para GitHub verificar se há padrões que não são de provedor e segredos genéricos, primeiro você deve habilitar os recursos para seu repositório ou organização. Para obter mais informações, consulte Habilitar a verificação de segredos que não são de provedor e Como habilitar a detecção de segredo genérico da verificação de segredos do Copilot.
Se o acesso a um recurso exigir credenciais emparelhadas, a verificação secreta criará um alerta somente quando ambas as partes do par forem detectadas no mesmo arquivo. Isso garante que os vazamentos mais críticos não estejam ocultos por trás de informações sobre vazamentos parciais. A correspondência de pares também ajuda a reduzir falsos positivos, pois ambos os elementos de um par devem ser usados juntos para acessar o recurso do provedor.
Sobre os alertas de proteção por push
A proteção por push verifica os pushes em busca de segredos compatíveis. Se a proteção por push detectar um segredo compatível, ela bloqueará o push. Quando um colaborador ignora a Security and quality proteção por push para enviar por push um segredo para o repositório, um alerta de proteção por push é gerado e exibido na guia do repositório. Para ver todos os alertas de proteção por push de um repositório, você deve filtrar por bypassed: true na página de alertas. Para saber mais, confira Exibindo e filtrando alertas do escaneamento de segredos.
Se o acesso a um recurso exigir credenciais emparelhadas, a verificação secreta criará um alerta somente quando ambas as partes do par forem detectadas no mesmo arquivo. Isso garante que os vazamentos mais críticos não estejam ocultos por trás de informações sobre vazamentos parciais. A correspondência de pares também ajuda a reduzir falsos positivos, pois ambos os elementos de um par devem ser usados juntos para acessar o recurso do provedor.
Observação
Você também pode habilitar a proteção por push para sua conta pessoal, chamada "proteção por push para usuários", o que impede que você envie segredos com suporte acidentalmente para qualquer repositório público. Os alertas não serão criados se você optar por ignorar apenas a proteção por push baseada no usuário. Os alertas só serão criados se o próprio repositório tiver a proteção por push habilitada. Para obter mais informações, consulte Gerenciando a proteção por push para usuários.
Versões mais antigas de determinados tokens podem não ter suporte da proteção de push, pois esses tokens podem gerar um número maior de falsos positivos do que sua versão mais recente. A proteção de push também pode não se aplicar a tokens herdados. Para tokens como Chaves do Armazenamento do Azure, o GitHub só dá suporte a tokens criados recentemente, não a tokens que correspondem aos padrões herdados. Para obter mais informações sobre limitações de proteção por push, consulte Escopo de detecção de verificação secreta.
Sobre os alertas de parceiros
Quando GitHub detecta um segredo vazado em um repositório público ou pacote npm, um alerta é enviado diretamente ao provedor do segredo, se ele fizer parte do programa de parceiro de varredura de segredos de GitHub. Para obter mais informações sobre alertas de verificação de segredo para parceiros, consulte Programa de verificação de segredo de parceiros e Padrões de varredura de segredos com suporte.
Os alertas de parceiros não são enviados aos administradores do repositório, portanto, você não precisa executar nenhuma ação para esse tipo de alerta.