Una guía publicada el 28/10/2026 por la consultora Veduis propone a los equipos de desarrollo un camino por fases para gestionar secretos, desde ordenar los archivos .env hasta usar HashiCorp Vault o los gestores de AWS y Google Cloud, con una advertencia clara: si una clave llega a un repositorio remoto, hay que darla por comprometida. El texto, firmado por Steven Richards, especialista en seguridad y cumplimiento, incluye configuraciones y comandos que un administrador de sistemas puede aplicar directamente.
Las claves de la gestión de secretos en equipos de desarrollo en 20 segundos
- Los archivos .env reales nunca deben llegar a Git; se versiona un .env.example sin valores.
- Gitleaks y detect-secrets detectan claves antes o después del commit.
- Ante una fuga, lo primero es revocar la clave y después limpiar el historial.
- Vault encaja cuando hacen falta auditoría y control de acceso por roles.
El punto de partida es conocido por cualquiera que haya revisado un repositorio ajeno: archivos .env.production subidos por error, contraseñas compartidas por chat o correo, el mismo secreto en desarrollo y en producción, claves que no se rotan nunca y ningún registro de quién ha accedido a qué. La guía resume el objetivo en tres reglas: los secretos no van en el control de versiones, no viajan en texto plano y su acceso se gobierna por roles con un registro de auditoría.
Primero, ordenar los .env y detectar fugas
Para el desarrollo local, Richards recomienda añadir a .gitignore todos los archivos con secretos reales y versionar solo un .env.example con los nombres de las variables y los valores vacíos. Propone además validar las variables al arrancar la aplicación con un esquema (en su ejemplo, con la librería Zod): comprobar que la URL de la base de datos tiene el prefijo correcto o que el secreto de los JWT tiene al menos 32 caracteres, y detener el proceso si algo falla.
La detección se monta en dos capas. Antes del commit, detect-secrets crea una línea base con detect-secrets scan > .secrets.baseline y se registra como gancho de pre-commit. En la integración continua, Gitleaks revisa todo el historial de Git en cada push y pull request; en GitHub Actions eso exige clonar con fetch-depth: 0. GitHub también ofrece su propio escaneo de secretos, automático en los repositorios públicos y disponible en los privados con Advanced Security.
Si una clave ya se ha subido, el orden importa. La guía insiste en revocarla primero, revisar los registros del proveedor para ver si se usó durante el tiempo que estuvo expuesta y solo después reescribir el historial con git filter-repo --replace-text y un git push --force-with-lease coordinado con el equipo. La razón es sencilla: cualquiera que haya clonado el repositorio conserva la copia antigua.
CI/CD, Vault y gestores en la nube
En los pipelines, los secretos deben vivir en el almacén de la plataforma y no en los archivos de configuración. En GitHub Actions, el texto recomienda pasarlos en el bloque env de cada paso con la sintaxis ${{ secrets.NOMBRE }} y usar entornos protegidos, con aprobación obligatoria de un revisor, antes de desplegar en producción.
Cuando el equipo necesita control de acceso por roles y auditoría, entra HashiCorp Vault. La guía distingue entre secretos estáticos, que se guardan como pares clave-valor, y dinámicos, credenciales de corta vida que Vault genera bajo demanda. Su ejemplo configura credenciales de PostgreSQL con una vida por defecto de una hora y un máximo de 24, y una aplicación que renueva el pool de conexiones cuando faltan cinco minutos para que caduquen. Recuerda que vault server -dev solo sirve para aprender y que en producción la autenticación debe hacerse con AppRole o con la integración de Kubernetes. Para quien prefiera una alternativa abierta y autoalojada, administraciondesistemas ya analizó OpenBao, la bifurcación comunitaria de Vault.
En la nube, el texto muestra cómo leer secretos de AWS Secrets Manager con el SDK de JavaScript, guardándolos en caché unos cinco minutos, y cómo programar la rotación automática cada 30 días con una función Lambda. En Google Cloud, Secret Manager controla el acceso a cada secreto mediante permisos de IAM. También describe la inyección con 1Password: un archivo de plantilla con referencias del tipo op:// que puede versionarse porque no contiene valores, y el comando op run, que entrega las variables al proceso sin escribirlas en disco.
Rotar sin cortes y no empezar la casa por el tejado
Para rotar secretos sin interrumpir el servicio, la guía propone una ventana en la que conviven dos valores: la aplicación firma con el secreto nuevo, pero acepta todavía el anterior. El proceso consiste en generar el nuevo, mover el viejo a una variable de secreto previo, recargar todas las instancias, esperar a que caduquen los tokens antiguos y borrar el secreto previo.
La parte más práctica es la que el autor dedica a los errores habituales. Montar Vault en un equipo de cinco personas suele ser prematuro: antes necesitan un .env.example, un gancho de pre-commit y secretos acotados en la integración continua. Confiar solo en el escaneo posterior al push tampoco basta, porque para entonces la clave ya debe considerarse expuesta. Y la revocación hay que ensayarla antes de un incidente, no durante. El texto no aporta estadísticas propias ni cita informes externos sobre fugas de credenciales.
Preguntas frecuentes
¿Se pueden subir los archivos .env a Git?
No los que contienen valores reales. Se recomienda ignorarlos y versionar solo un .env.example con las variables vacías.
¿Qué hacer si se sube una clave a un repositorio?
Revocarla de inmediato, revisar si se usó y después limpiar el historial con git filter-repo y un push forzado coordinado.
¿Qué herramientas detectan secretos en el código?
La guía cita detect-secrets como gancho de pre-commit, Gitleaks en la integración continua y el escaneo de secretos de GitHub.
¿Cuándo compensa usar Vault?
Cuando el equipo necesita control de acceso por roles, auditoría o credenciales dinámicas; antes conviene cubrir lo básico.
Fuentes:
