A code scan finds database passwords hard-coded in an application's source, which had been pushed to a public repository. After the exposed credentials are revoked and rotated, what is the best long-term fix?
Select an answer to reveal the explanation.
Short Explanation
Hard-coding passwords is like taping your house key to the front door. Put them in a secrets manager instead, where access is controlled, logged and rotated, and have the app fetch them when it runs. Base64 is the classic trap; it's an encoding, not encryption, and anyone can reverse it.
Full Explanation
Secrets such as database passwords, API keys and tokens should never live in source code, configuration committed to version control or machine images. Once a secret appears in a repository, it persists in history and clones even after being removed from the current version, which is why revocation and rotation come first. The durable fix is a secrets manager: a centralized service that stores secrets encrypted, controls which identities and workloads may read each secret, logs access and supports automated rotation. The application retrieves the secret at run time using its workload identity, so no human-readable credential sits in code. Making the repository private reduces exposure but leaves secrets in history, in every clone and on every developer machine, and does nothing for rotation or access logging. Base64 is a reversible encoding with no key, so it offers no confidentiality and secret scanners routinely detect encoded credentials anyway. Baking credentials into machine images spreads them to every instance and image copy, makes rotation require rebuilding images and exposes them to anyone who can access the image. Exam caveat: short-lived, dynamically issued credentials are even better where the platform supports them. Operational check: run secret scanning in the CI pipeline and fail builds that contain credentials.