Las contraseñas, claves de API y tokens no deberían almacenarse junto al resto de la configuración de una aplicación. La configuración describe comportamiento y debe vivir en git, en la revisión de código y en las máquinas de los desarrolladores; los secretos conceden autoridad y exigen acceso restringido y rotación independiente. Mezclar ambos en un mismo archivo acopla ciclos de vida y audiencias distintos: rotar una contraseña termina obligando a regenerar configuración de la aplicación.
Una auditoría de los 445 módulos de NixOS que gestionan un secreto real, realizada sobre el commit 141f212 de nixpkgs, ilustra el alcance del problema. De esos módulos, 110 (el 25 %) recuperan el secreto de forma segura pero lo copian en un archivo de configuración en tiempo de ejecución porque esa es la única interfaz que acepta la aplicación. Otros 42 módulos pueden insertar secretos en /nix/store, que es legible por todos. El resto utiliza canales más limpios: variables de entorno (36 %), archivos dedicados (13 %), credenciales de systemd (12 %) o argumentos de línea de comandos (4 %). El patrón se reproduce fuera de NixOS como script de entrada, plantilla de Helm o paso de interpolación en CI.
Para corregirlo, las aplicaciones deberían aceptar secretos mediante canales específicos —archivos dedicados, credenciales de systemd, variables de entorno acotadas o un proveedor externo— en lugar de embeberlos en la configuración. SecretSpec, una herramienta surgida tras detectar este mismo fallo en Cachix, formaliza esa separación: un archivo secretspec.toml declara qué necesita la aplicación y cada entorno (llavero del sistema, CI, 1Password, Vault, OpenBao) elige dónde residen los valores, sin obligar a construir una plataforma de secretos propia.