¿Cómo evitas que los secretos se filtren a través de tu pipeline CI/CD?
Respuesta breve
Usa defensa en profundidad: los hooks pre-commit (p. ej. gitleaks) atrapan secretos antes de que lleguen, el escaneo de CI en el servidor atrapa lo que se cuela, y escaneos periódicos de todo el historial encuentran filtraciones antiguas. Y lo crítico: un secreto que llegó a un repositorio remoto debe tratarse como comprometido y rotarse — borrar el commit no ayuda porque vive en el historial, los forks y los logs. Combina esto con un gestor de secretos real para que los secretos no estén en el código en absoluto.
Las credenciales codificadas a mano son uno de los errores más comunes y dañinos en el software, y el pipeline es donde las atrapas. Una buena respuesta es por capas.
Atrápalo antes de que llegue: pre-commit
Un hook pre-commit (usando un escáner como gitleaks o detect-secrets) se ejecuta en la máquina del desarrollador y bloquea el commit si detecta una clave de API, una clave privada o un token. Este es el lugar más barato para detener una filtración — el secreto ni siquiera llega al servidor. La debilidad: los hooks son locales y pueden eludirse u omitirse, así que no pueden ser tu única línea.
Atrapa lo que se cuela: CI en el servidor
Como los hooks no son imponibles, ejecuta el mismo escaneo en el servidor en CI en cada push y pull request, e idealmente como un escaneo a nivel de plataforma (escaneo de secretos nativo de GitHub/GitLab) que el desarrollador no pueda desactivar. Esta es la barrera imponible.
Encuentra filtraciones antiguas: escaneo del historial
Los secretos comiteados hace meses siguen en el historial de git. Escanea periódicamente todo el historial, y usa protección de push para que los secretos detectados por la plataforma se bloqueen en el momento del push.
Lo innegociable: rotar
Aquí está la parte que los junior pasan por alto. Una vez que un secreto ha llegado a un repositorio remoto, está comprometido — punto final. Persiste en el historial, en los clones, en los forks y en los logs de CI. Borrar el commit o reescribir el historial no lo hace seguro. La única respuesta correcta es rotar la credencial de inmediato.
Mejor: no tener secretos en el código
La corrección de raíz es un gestor de secretos (Vault, KMS/almacenes de secretos cloud) para que las aplicaciones obtengan los secretos en runtime y CI los inyecte como variables enmascaradas — no hay nada que filtrar.
Lo que buscan los entrevistadores
Quieren el modelo por capas, la insistencia en la rotación sobre el borrado, y el reconocimiento de que los gestores de secretos eliminan el problema en su origen.
Posibles preguntas de seguimiento
- ¿Por qué no basta con borrar el commit infractor?
- ¿Dónde deberían residir realmente los secretos en vez de en el código?
- ¿Por qué ejecutar el escaneo tanto en pre-commit como en el servidor en vez de solo uno?