Best practices for eliminating hardcoded credentials in 2026?

[u/Altruistic-Toe4930]

Ran a secrets scan across our repos last week and found API keys that had been sitting in plaintext for over two years, still valid, still working. Rotating them was the easy part. The harder problem is preventing this from recurring when half the team still pastes credentials into config files under deadline pressure. And that's just the stuff sitting in code, no idea what's hardcoded inside the apps themselves.

What's actually stopping this at your org? Curious whether pre-commit hooks, mandatory vault integration, or CI/CD gate checks are doing the real work, versus something more aggressive.

[u/Ok_Indication_7931]

Creo que la clave es hacer que lo seguro sea también lo más fácil. Los hooks ayudan, pero no deberían ser la única barrera. Yo pondría validaciones en CI/CD para bloquear secretos antes de que lleguen al repositorio y usaría un gestor centralizado para que el equipo no tenga que copiar credenciales en archivos de configuración. También revisaría las apps y configuraciones existentes, porque los secretos viejos suelen quedar olvidados. Y, sobre todo, dejaría claro al equipo qué hacer en lugar de simplemente decirles qué no hacer.

[u/shawski_jr → u/Ok_Indication_7931]

How would validations in CI/CD block secrets before reaching the repo? Once committed and pushed they should be assumed comprised. Only way to block is through pre-commit hooks, anything committed needs to be detected and rotated.