Un secreto en un commit está quemado: rotación inmediata, nunca la fecha
Un secreto seguido por un repositorio se trata como comprometido en el instante en que se escribe, no cuando alguien demuestra que ha sido leído, y el remedio que alcanza cada copia es hacer rotar el identificador, la reescritura del historial llega en segundo lugar y no siempre es necesaria.
Un secreto seguido por un repositorio se trata como comprometido en el instante en que se escribe, no en el momento en que alguien demuestra que ha sido leído: esta es la regla que retiene este curso, construida sobre el orden de prioridad que plantea la documentación oficial de GitHub, consultada el 2 de septiembre de 2026, entre rotación y reescritura de historial.
La reescritura de historial no sustituye a la rotación
Limpiar el historial de un repositorio, retirando el archivo culpable de un commit pasado, da la impresión tranquilizadora de haber borrado el problema. La misma fuente es explícita en este punto: revocar y hacer rotar un secreto expuesto es la prioridad, la limpieza del historial llega en segundo lugar, precisamente porque la clave ya está comprometida en el momento en que se descubre. Una copia del repositorio puede existir en otro lugar, un espejo, un clon en otro puesto, una copia de seguridad: la reescritura solo alcanza la copia sobre la que se trabaja, nunca las demás copias posibles. Solo una rotación del propio identificador protege contra cada una de estas copias, conocida o no.
La antigüedad del commit no dice nada sobre el estado del token
Un token encontrado en un commit de hace un mes no está necesariamente todavía activo: ha podido cambiarse entre tanto por una razón sin relación con este descubrimiento. La antigüedad del archivo no zanja entonces nada, ni en un sentido ni en otro. La fecha que lleva un archivo de configuración es solo un dato de contexto, no una prueba. El siguiente ejemplo ilustra la diferencia entre mirar una fecha y probar realmente un token, sobre un fixture creado para la ocasión:
echo "jeton_de_prod_gamma" > jetons_valides.txt
jeton_a_tester="jeton_de_prod_gamma"
grep -qx "$jeton_a_tester" jetons_valides.txt && echo "encore actif" || echo "revoque"El archivo jetons_valides.txt hace aquí las veces del servicio que emitió el token. En el proveedor real, este papel lo desempeña una petición autenticada, enviada por ti, contra el servicio en cuestión, nunca por la comparación de dos cadenas de caracteres locales ni por la fecha de un commit.
La rotación primero, la prueba de lectura nunca
Esperar una prueba de que el secreto ha sido efectivamente leído por otra persona antes de hacerlo rotar equivale a apostar por una ausencia de prueba en vez de por la seguridad. Esta prueba casi nunca llega a tiempo, y a veces no llega nunca. Haz rotar el identificador nada más descubrirlo, sin esperar confirmación, y luego limpia el historial si el tiempo lo permite después. La lección anterior trata lo que hay que hacer incluso antes de que un secreto termine en un repositorio.
La antigüedad del commit contra la prueba real
Un commit de hace un mes representa un riesgo bajo, el tiempo transcurrido tranquiliza sobre el estado del secreto.
Solo una petición autenticada en directo contra el servicio que emitió el token dice si sigue activo.
Un desarrollador encuentra, en un commit de hace seis semanas, una clave secreta olvidada en un archivo de configuración. Hace rotar esta clave ante el proveedor que la emitió el mismo día de su descubrimiento, y luego retira el archivo de los commits siguientes.
Escribe en una frase lo que esta situación establece, y en una frase lo que no establece.
Lo que esto establece: Establece que la clave comprometida fue neutralizada en origen, mediante una rotación solicitada el mismo día de su descubrimiento.
Lo que esto no establece: No establece que esta clave no haya sido usada por nadie más durante las seis semanas en que permaneció expuesta en el historial.
Los tres calibrados falsos más frecuentes
- Demasiado amplio La rotación de esta clave garantiza que ninguna copia del repositorio, presente o futura, vuelve a contener jamás este secreto.
- Demasiado estrecho Esta situación no muestra nada más que un desarrollador que corrigió un archivo de configuración.
- Fuera de lugar Muestra que el proveedor de la clave tardó seis semanas en detectar un uso anómalo.
- Un secreto commiteado en un repositorio seguido se considera comprometido desde el instante de su escritura, no cuando se demuestra que un tercero lo ha leído.
- Limpiar el historial de un repositorio solo alcanza la copia sobre la que se trabaja, nunca las demás copias posibles del mismo secreto.
- La antigüedad de un commit no dice nada sobre el estado real de un token, solo una petición autenticada ante el servicio en cuestión zanja la cuestión.
- La rotación de un identificador expuesto se hace desde su descubrimiento, sin esperar una prueba de que alguien más lo ha leído efectivamente.
Busca, hoy, un identificador que quizá hayas dejado en un archivo de configuración ya compartido o commiteado, aunque sea una sola vez. Hazlo rotar ante el servicio que lo emitió antes de que termine el día, sin esperar una prueba de que otra persona lo ha leído.
Estos puntos dependen de una interfaz o de una regla que puede haber cambiado desde la redacción. Verifícalos en tu propia pantalla antes de fiarte de ellos.
- El modo exacto de revocación y el registro de uso disponible dependen del proveedor que emitió el token: verifícalo en el panel de ese proveedor concreto antes de considerar terminada la rotación.
Cada afirmación datable de esta lección remite aquí al texto público que la respalda. Una fuente que no se abre no prueba nada.