Challenge 2: Explain Why Deleting a Committed Secret Isn't Enough — Possible Solution ==================================================================== WHY THE KEY SHOULD STILL BE TREATED AS COMPROMISED -------------------------------------------------------- Deleting the API key from the file in a NEW commit only changes what the CURRENT, latest version of the file looks like — it does nothing to remove the key from the repository's HISTORY. Git is fundamentally designed to preserve every prior commit; the commit that originally introduced the key still exists, permanently, in the repository's history, and remains fully retrievable by anyone who can access that history (via git log, git show, browsing commit history on GitHub, or cloning the repo and checking out that specific earlier commit). This chapter states this directly: "a credential committed to git history is compromised forever, even if later deleted from the current file." The "delete it in the next commit" fix only hides the key from someone glancing at the CURRENT state of the file — it does nothing to prevent someone from viewing the file's history and finding the original commit that added it. WHY THIS MATTERS PRACTICALLY, EVEN FOR A PRIVATE REPO ----------------------------------------------------------- Even setting aside the chapter's specific point about public repos being scraped by automated bots within minutes, the exposure risk doesn't disappear just because a repo happens to be private — anyone with legitimate access to the repo (current team members, anyone who gains access later, a compromised account) can still browse its full history and find the key. Treating a briefly-exposed key as permanently compromised is the only safe assumption, regardless of how quickly it was noticed and "fixed" in the visible, current file. WHAT ACTUALLY NEEDS TO HAPPEN ---------------------------------- The correct remediation is to ROTATE the credential — generate a brand new key/secret from whatever service issued it, update GitHub Secrets (or wherever the credential is actually used) with the new value, and treat the OLD key as permanently invalid/revoked at the source, not just removed from the repo's current files. Simply deleting the committed value from the file, without also rotating the actual credential at its source, leaves the original, still-valid key sitting recoverable in git history indefinitely.