Tu equipo guarda las contraseñas de BD como variables de entorno en texto plano en una config de despliegue versionada en el repositorio. ¿Mejor enfoque?

Un secreto versionado es uno de los incidentes más comunes del mundo real, y esta pregunta comprueba si conoces la diferencia entre ocultar un secreto y protegerlo. La única respuesta correcta elimina el secreto del control de código por completo y lo gestiona adecuadamente.

Por qué un gestor de secretos es la respuesta

Un gestor de secretos (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) te da las tres cosas que el control de código no puede: control de acceso (solo el rol de la carga de trabajo puede leer el secreto), auditoría (cada recuperación queda registrada) y rotación (la contraseña se puede cambiar de forma automática y bajo demanda). La aplicación obtiene el secreto en runtime, mediante su rol IAM o un sidecar, de modo que nunca se versiona nada sensible. Es clave: como la contraseña ya estaba en el repositorio, debes tratarla como comprometida: elimínala del historial y rótala.

Por qué fallan los distractores

• Codificarla en base64. El base64 es codificación, no cifrado. Cualquiera lo revierte en un comando. El secreto queda igual de expuesto, ahora con una falsa sensación de seguridad.
• Moverla a un repositorio privado. Un repo privado sigue entregando el secreto a cada desarrollador con acceso de clonación, cada runner de CI/CD, cada fork y clon local, y a quien después obtenga acceso de lectura. «Privado» no es «secreto», y la credencial sigue para siempre en el historial de git.
• Codificarla de forma fija en el binario. Las cadenas de un binario compilado se extraen trivialmente con strings o un desensamblador. Has añadido fricción de compilación sin añadir protección, y sigues sin poder rotar sin un redespliegue.

El problema del historial

Borrar el archivo de HEAD no basta: el secreto permanece en el historial de git y en cada clon. Por eso la rotación es obligatoria: asume que se ha filtrado e invalídalo.

Qué buscan los entrevistadores

Nombrar un almacén de secretos gestionado con inyección en runtime, insistir en la rotación porque el secreto ya está comprometido, y señalar que base64 y los repos privados no son protección. Los buenos candidatos añaden una salvaguarda de pre-commit / escaneo de secretos para que no vuelva a ocurrir.