A developer commits a DNA Center token in a .env file, then deletes the line in a later commit. Which secret-storage approach is the relevant fix going forward?
Select an answer to reveal the explanation.
Short Explanation
Git remembers like a library microfilm—deleting a line today does not erase yesterday’s reel. Put tokens in a secret store or a gitignored local file, not the repo.
Full Explanation
Secrets must stay out of git history—use a secret store or a gitignored, uncommitted local file instead of the repository. Clones and remotes replicate history; once a token is committed, treat it as compromised until rotated across every consumer of the civic integration. Believing that deleting the line in a later commit erases older blobs misunderstands git: history retains the object until a careful rewrite and force-push, and forks plus CI caches may still hold the old value. Storing tokens in tracked YAML under a secrets/ folder confuses directory naming with protection—the folder is still versioned plaintext visible to anyone with repo access. Encoding the token in Base64 inside the repo is encoding, not encryption, and is trivial to reverse with a one-liner. Exam caveat: pre-commit secret scanners help prevent new leaks but do not heal an already-published credential—rotate immediately and revoke the old value everywhere it was used. Operational check: search git history for the token pattern, confirm the working tree uses a vault or gitignored file only, and rotate any value that ever appeared in a commit. Record the outcome in the release or incident notes so the next operator inherits evidence, not tribal knowledge.