Nota: El administrador del sitio debe habilitar secret scanning para tu instancia de GitHub Enterprise Server para que puedas utilizar esta característica. Para obtener más información, vea «Configurar el escaneo de secretos para tu aplicativo».
Es posible que no puedas habilitar o deshabilitar secret scanning si un propietario de empresa ha establecido una directiva en el nivel empresarial. Para obtener más información, vea «Aplicación de directivas de seguridad y análisis de código de la empresa».
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.