Note
O administrador do site deverá habilitar a secret scanning para a instância antes que você possa usar esse recurso. Para obter mais informações, confira "Configurar a varredura de segredo para o seu dispositivo".
Talvez você não consiga habilitar ou desabilitar a secret scanning se um proprietário da empresa tiver definido uma política no nível da empresa. Para obter mais informações, confira "Como impor políticas para segurança e análise de código na empresa".
Detecção de pares de padrões
O Secret scanning detectará apenas pares de padrões, como Chaves de Acesso e Segredos da AWS, se a ID e o segredo estiverem no mesmo arquivo e ambos forem enviados por push para o repositório. A correspondência de pares ajuda a reduzir falsos positivos, pois ambos os elementos de um par (a ID e o segredo) devem ser usados juntos para acessar o recurso do provedor.
Pares enviados por push para arquivos diferentes ou não enviados por push para o mesmo repositório não resultarão em alertas. Para saber mais sobre os pares de padrões com suporte, confira a tabela em Padrões de varredura de segredos com suporte.
Sobre tokens herdados do GitHub
Para tokens do GitHub, verificamos a validade do segredo para determinar se o segredo está ativo ou inativo. Isso significa que, no caso de tokens herdados, o secret scanning não detectará um personal access token do GitHub Enterprise Server no GitHub Enterprise Cloud. Da mesma forma, um personal access token do GitHub Enterprise Cloud não será encontrado no GitHub Enterprise Server.
Limitações de proteção de push
Se a proteção de push não detectar um segredo que você acha que deveria ter sido detectado, primeiro você deve verificar se a proteção de push dá suporte ao tipo de segredo na lista de segredos com suporte. Para mais informações, confira Padrões de varredura de segredos com suporte.
Se o segredo estiver na lista com suporte, há vários motivos pelos quais a proteção de push pode não detectá-lo.
- A proteção de push bloqueia apenas segredos vazados em um subconjunto dos padrões mais identificáveis alertados pelo usuário. Os colaboradores podem confiar em defesas de segurança quando esses segredos são bloqueados, pois esses são os padrões que têm o menor número de falsos positivos.
- A versão do segredo pode ser antiga. 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.
- O push pode ser muito grande, por exemplo, se você estiver tentando enviar por push milhares de arquivos grandes. Uma verificação da proteção de push pode atingir o tempo limite e não bloquear um usuário se o push for muito grande. O GitHub ainda examinará e criará alertas, se necessário, após o push.
- Se o push resultar na detecção de mais de cinco novos segredos, mostraremos apenas os cinco primeiros (sempre mostraremos um máximo de cinco segredos ao mesmo tempo).
- Se um push contiver mais de 1.000 segredos existentes (ou seja, segredos para os quais os alertas já foram criados), a proteção de push não bloqueará o push.