Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2023-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Solução de problemas com a varredura de segredos

Se você tiver problemas com secret scanning, poderá usar essas dicas para ajudar a resolver os problemas.

A Secret scanning está disponível para os repositórios pertencentes a uma organização no GitHub Enterprise Server se a sua empresa tem uma licença do GitHub Advanced Security. Para obter mais informações, confira "Sobre a verificação de segredo" e "Sobre a Segurança Avançada do GitHub".

Observação: o administrador do site precisa habilitar a secret scanning no sua instância do GitHub Enterprise Server para 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 o secret scanning se um proprietário da empresa tiver definido uma política GitHub Advanced Security (GHAS) 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 digitalização de segredo".

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 digitalização de segredo".

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.