Una credencial que llega a un commit enviado ya está filtrada, incluso si un commit posterior la elimina. Seguridad detecta credenciales en sus cambios e historial, no las guarda y las trata como abiertas hasta que alguien confirme que se han rotado o revocado.
¿Qué se analiza?
- Cada cambio: los cambios de cada pull request, como parte del
Coroid Securitychequeo, y los cambios de los agentes propios de Coroid antes de ser commiteados. - La rama predeterminada: cada envío y una vez a través de todo su historial. El análisis del historial comienza cuando se conecta un repositorio o se activa Secretos filtrados.
- Ramas de pull request: una credencial enviada a una rama de pull request también genera un hallazgo, ya que ya está en el repositorio.
Una rama enviada sin pull request no se analiza.
El análisis del historial lee cada commit accesible, empezando por el más reciente, y cada versión de archivo una sola vez. Funciona en segmentos y reanuda donde se detuvo. Cada repositorio tiene límites sobre cuánto historial se puede leer (commits, bytes, tiempo y tamaño de archivo); si un repositorio supera esos límites, la cobertura será parcial.
¿Qué se detecta?
Credenciales de proveedores en sus formatos conocidos (claves de acceso de AWS, tokens de GitHub y GitLab, claves de OpenAI y otros), tokens de autorización, credenciales asignadas a nombres como password o api_key, claves privadas, credenciales
dentro de URLs y cadenas largas de alta entropía. Las credenciales asignadas en el código solo se coinciden cuando el valor es un literal, no una variable o llamada a función.
Coroid nunca guarda el valor
Un valor detectado pasa directamente del detector al broker de credenciales de Coroid, que devuelve una huella digital con clave y descarta el valor. Solo se almacena la huella digital. Está vinculada a la organización, por lo que no se puede comparar entre organizaciones ni adivinar fuera de línea.
En cualquier lugar donde aparecería un secreto (hallazgos, chequeos, comentarios de revisión,
registros), Coroid muestra solo la regla, la longitud y la ubicación, por ejemplo
[redacted secret: named_credential, 40 characters]. Ninguna parte del valor se
muestra, ni siquiera sus primeros caracteres.
Coroid nunca prueba una credencial que encuentra para ver si funciona.
Una credencial, un hallazgo
Una credencial vista en muchos commits es un único hallazgo con varias ocurrencias. La misma credencial en dos repositorios son dos hallazgos, uno por repositorio. Cuando confirma una, Seguridad lista las demás con la misma credencial para que pueda confirmarlas juntas. Nunca lo hace por sí sola.
Un secreto solo se cierra mediante confirmación
Eliminar una credencial del código hace que sus ocurrencias desaparezcan, pero el hallazgo permanece abierto: cualquiera que haya leído el repositorio antes podría tenerla. Solo se cierra cuando un propietario o administrador confirma lo que se hizo:
- Rotada o revocada;
- la fecha en que se realizó;
- una nota opcional.
Seguridad registra quién confirmó y cuándo, y lo muestra en el hallazgo: "Rotada el 28 de octubre, confirmada por Alex el 29 de octubre". El hallazgo pasa a Rotación confirmada.
Solucionar un secreto filtrado
Crear la tarea de lista de verificación crea una tarea en el proyecto con estos pasos:
- Rotar o revocar la credencial en su proveedor.
- Moverla al lugar donde el proyecto guarda sus secretos.
- Eliminarla del código.
- Confirmar la rotación en Seguridad.
La tarea nunca se repite ni prueba la credencial. No reescribe el historial de Git: eliminar una credencial del historial es una decisión de su equipo y no hace que un secreto filtrado vuelva a ser seguro.
¿Credencial real o no es un problema?
En un hallazgo de secreto, los propietarios y administradores responden ¿Era esta una credencial real?
- Credencial real mantiene el hallazgo abierto hasta que se confirme.
- No es un problema registra una excepción de falso positivo que oculta el hallazgo, por ejemplo para un fixture de prueba. Credencial real elimina esa excepción de nuevo.
Estas respuestas también ayudan a calibrar los detectores.
Bloqueo
Secretos filtrados opera de forma predeterminada en modo observación. Solo bloquea una vez que sus detectores hayan pasado la calibración y el cumplimiento esté activado. Consulte Protecciones y cumplimiento.
Las organizaciones que tenían activada la función de escaneo de secretos anterior en su política de organización seguirán siendo bloqueadas por esta, junto con la versión del detector correspondiente, hasta que los nuevos detectores pasen la calibración. Dicho escaneo anterior no genera Hallazgos, por lo que una excepción o certificación no puede ocultar lo que bloquea.
En la configuración predeterminada de la organización, Bloquear nuevos secretos y los cambios más importantes escaneados se muestran en la sección Secretos filtrados.
Notificaciones
Los Hallazgos de secretos aún no envían notificaciones. Aparecen en Seguridad → Hallazgos y en el Resumen.
GitHub escaneo de secretos
Si el escaneo de secretos propio de GitHub está activado para un repositorio, Seguridad puede importar sus alertas. Una alerta de escaneo de secretos de GitHub permanece abierta hasta que alguien la resuelva en GitHub, por lo que fusionar una corrección no la cierra allí. Consulte Alertas de seguridad de GitHub.