Menos alertas falsos de segredos. A evidência continua essencial
O GitHub aprimorou detectores de segredos em 5 de novembro. Contexto e estado da credencial orientam a resposta.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestEm 5 de novembro, o GitHub anunciou mudanças nos detectores de segredos. Um novo padrão parceiro da SpaceX e filtros mais precisos ampliam a cobertura. Uma lista menor de alertas não prova que um repositório esteja livre de credenciais expostas.
O que mudou
Para alguns padrões Alibaba, AWS e Google, o GitHub suprime uma correspondência sem par quando o filtro de dicionário remove todos os segredos acompanhantes que atendem aos critérios. Outros detectores aplicam verificações distintas de contexto ou formato. O padrão parceiro starlink_public_api_v2_secret foi adicionado. O envio ao fornecedor em repositórios públicos é diferente de um alerta ao usuário e não garante a revogação de todo segredo exposto.
Examine as evidências
| Pergunta | Evidência | Por quê |
|---|---|---|
| O que foi encontrado? | Revisão, caminho, linha e contexto | Dado de teste, nome de variável e credencial utilizável são diferentes. |
| Ainda pode ser usado? | Estado suportado pelo fornecedor e confirmação do responsável | Estado desconhecido não comprova segurança. |
| Onde houve exposição? | Visibilidade, histórico e cópias | A exposição pode ir além do arquivo atual. |
| O que ocorreu depois? | Rotação, substituição e revisão de acesso | Apagar o texto não invalida a credencial. |
Se uma credencial puder estar ativa, inicie imediatamente seu processo de incidente. Contate o responsável e revogue ou rotacione a credencial no fornecedor quando adequado. Não copie seu valor em tickets ou conversas. Revise logs disponíveis e sistemas afetados. Um segredo hoje inativo pode ter sido usado anteriormente.
O GitHub explica as verificações de validade e seus limites: o suporte depende do tipo e da configuração; unknown exige investigação adicional. A imagem é um exemplo de documentação, não um resultado do Plexicus.
Mantenha a decisão verificável
Registre versão do scanner, revisão imutável, localização, conclusão limitada pela evidência e responsável. Declare quando faltarem dados. Excluir uma pasta inteira de testes pode ocultar segredos reais. Nossa análise de três alertas do n8n mostra a importância do contexto sem concluir sobre todos os alertas.
O Plexicus descreve testes de aplicações baseados em evidências e fluxos de remediação. Isso não afirma que o Plexicus executa a verificação específica do GitHub ou rotaciona credenciais automaticamente. Sua equipe ainda precisa de um responsável e um processo para uma exposição suspeita.
Imagem: GitHub Docs, Evaluating alerts from secret scanning, CC BY 4.0. Captura original preservada. Licença.
