Skip to main content

Solución de problemas de examen de secretos

Si tiene problemas con secret scanning, puede usar estas sugerencias para ayudar a resolver problemas.

¿Quién puede utilizar esta característica?

Secret scanning alerts for partners runs automatically on public repositories and public npm packages to notify service providers about leaked secrets on GitHub.com.

Secret scanning alerts for users are available for free on all public repositories. Organizations using GitHub Enterprise Cloud with a license for GitHub Advanced Security can also enable secret scanning alerts for users on their private and internal repositories. Additionally, secret scanning alerts for users are available and in beta on user-owned repositories for GitHub Enterprise Cloud with Enterprise Managed Users. For more information, see "About secret scanning" and "About GitHub Advanced Security."

For information about how you can try GitHub Advanced Security for free, see "Setting up a trial of GitHub Advanced Security."

Detección de pares de patrones

Secret scanning solo detectará pares de patrones, como claves de acceso y secretos de AWS, si el identificador y el secreto se encuentran en el mismo archivo y ambos se insertan en el repositorio. La coincidencia de pares ayuda a reducir los falsos positivos, ya que ambos elementos de un par (el identificador y el secreto) deben usarse juntos para acceder al recurso del proveedor.

Los pares insertados en archivos diferentes, o no insertados en el mismo repositorio, no generarán alertas. Para más información sobre los pares de patrones admitidos, consulta la tabla en "Patrones de análisis de secretos".

Acerca de los tokens de GitHub heredados

Para GitHub, comprobamos la validez del secreto para determinar si el secreto está activo o inactivo. Esto significa que, para los tokens heredados, secret scanning no detectará un GitHub Enterprise Server personal access token en GitHub Enterprise Cloud. Del mismo modo, no se encontrará GitHub Enterprise Cloud personal access token en GitHub Enterprise Server.

Limitaciones de protección de inserción

Si la protección de inserción no detectó un secreto que cree que se debe haber detectado, primero debe comprobar que la protección de inserción admite el tipo de secreto en la lista de secretos admitidos. Para más información, consulta "Patrones de análisis de secretos".

Si el secreto está en la lista admitida, hay varias razones por las que es posible que la protección de inserción no la detecte.

  • La protección de inserción solo bloquea los secretos filtrados en un subconjunto de los patrones con alertas de usuario más identificables. Los colaboradores pueden confiar en defensas de seguridad cuando estos secretos se bloquean, ya que son los patrones que tienen el número más bajo de falsos positivos.
  • Es posible que la versión del secreto sea antigua. Es posible que las versiones anteriores de ciertos tokens no sean compatibles con la protección de inserción, ya que estos tokens pueden generar un número mayor de falsos positivos que su versión más reciente. Es posible que la protección de inserción tampoco se aplique a los tokens heredados. En el caso de tokens como claves de Azure Storage, GitHub solo admite tokens creados recientemente, no tokens que coincidan con los patrones heredados.
  • La inserción puede ser demasiado grande, por ejemplo, si intenta insertar miles de archivos grandes. Un examen de protección de inserción puede agotar el tiempo de espera y no bloquear a un usuario si la inserción es demasiado grande. GitHub seguirá examinando y creando alertas, si es necesario, después de la inserción.
  • Si la inserción da como resultado la detección de más de cinco secretos nuevos, solo le mostraremos los cinco primeros (siempre le mostraremos un máximo de cinco secretos a la vez).
  • Si una inserción contiene más de 1 000 secretos existentes (es decir, secretos para los que ya se han creado alertas), la protección de inserción no bloqueará la inserción.