A scan of a source code repository finds application configuration files containing database connection strings with plaintext passwords, committed over several months. What is the best remediation?
Select an answer to reveal the explanation.
Short Explanation
Once a password lands in version control, assume it's out of the bag; the history remembers it even after you delete the file. So you rotate the passwords, move secrets into a vault the app reads at runtime, and add scanning to catch the next slip. Base64 is the trap; it's encoding, not encryption, and anyone can reverse it.
Full Explanation
Credentials committed to a repository are exposed to everyone who has ever had access to it, and they persist in the commit history, forks and clones even after the file is removed. Remediation therefore has two parts. First, treat the passwords as compromised and rotate them, so the leaked values no longer work. Second, remove secrets from code entirely by storing them in a secrets vault or managed secret store that the application retrieves at runtime with its own identity, ideally with short-lived or automatically rotated credentials. Adding secret scanning to commits and pipelines catches future mistakes before they are pushed. Deleting the files in a new commit leaves every prior version, including the passwords, in the history, and keeping the passwords unchanged leaves the database open to anyone who copied them. Base64 encoding is a reversible representation, not encryption, so the passwords remain trivially readable. Making the repository private reduces future exposure but does nothing about everyone who already accessed it or about copies elsewhere. Exam caveat: rewriting history to purge the secret can be done as an extra step, but it never replaces rotation. Operational check: confirm the old passwords fail authentication and that the application starts using only vault-retrieved credentials.