Skip to main content

Esta versão do GitHub Enterprise Server será descontinuada em 2026-03-17. 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.

Secret scanning detection scope

Secret scanning uses pattern matching and validation to detect secrets. Detection varies based on pattern pairs, token types, and push protection settings.

Quem pode usar esse recurso?

O Secret scanning está disponível para os seguintes tipos de repositório:

Observação

O administrador do site deverá habilitar a secret scanning para a instância antes que você possa usar esse recurso. Para saber mais, 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 saber mais, confira Como impor políticas para segurança e análise de código na empresa.

Detection of pattern pairs

Secret scanning will only detect pattern pairs, such as AWS Access Keys and Secrets, if the ID and the secret are found in the same file, and both are pushed to the repository. Pair matching helps reduce false positives since both elements of a pair (the ID and the secret) must be used together to access the provider's resource.

Pairs pushed to different files, or not pushed to the same repository, will not result in alerts. For more information about the supported pattern pairs, see the table in Padrões de varredura de segredos com suporte.

About legacy GitHub tokens

For GitHub tokens, we check the validity of the secret to determine whether the secret is active or inactive. This means that for legacy tokens, secret scanning won't detect a GitHub Enterprise Server personal access token on GitHub Enterprise Cloud. Similarly, a GitHub Enterprise Cloud personal access token won't be found on GitHub Enterprise Server.

Push protection limitations

If push protection did not detect a secret that you think should have been detected, then you should first check that push protection supports the secret type in the list of supported secrets. For further information, see Padrões de varredura de segredos com suporte.

If your secret is in the supported list, there are various reasons why push protection may not detect it.

  • Push protection only blocks leaked secrets on a subset of the most identifiable user-alerted patterns. Contributors can trust security defenses when such secrets are blocked as these are the patterns that have the lowest number of false positives.
  • The version of your secret may be old. 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.
  • The push may be too large, for example, if you're trying to push thousands of large files. A push protection scan may time out and not block a user if the push is too large. GitHub will still scan and create alerts, if needed, after the push.
  • If the push results in the detection of over five new secrets, we will only show you the first five (we will always show you a maximum of five secrets at one time).
  • If a push contains over 1,000 existing secrets (that is, secrets for which alerts have already been created), push protection will not block the push.
  • If you see a bypass request without commit or file path details, it means that push protection ran out of time. The push was too large or the history too complex to locate the commit that introduced the secret.