How a public repository ended up holding production-grade secrets
The failure started with a simple control being turned off. Commit history showed secret blocking had been disabled rather than defeated by some clever trick, which is worse because it leaves a clear record of the decision.
That matters because GitHub’s secret detection is meant to catch the obvious mistakes before they go public. If it is switched off, the repo stops acting like a guardrail and starts acting like storage. The rest of the mess followed from that choice.
Plaintext passwords sat in CSV files, and backup files were committed with the rest of the material. There was no neat separation between sensitive values and ordinary project files. The result was a repository that mixed internal deployment data, operational logs and working credentials in one place.
The exposure path from GitHub to AWS GovCloud and internal systems
The exposed AWS access keys still authenticated after disclosure, and they were valid at a high privilege level against three AWS GovCloud accounts. That is the part that turns a leak into an incident. A public GitHub repository is bad enough on its own. Working keys for a cloud control plane are the bit that can turn one mistake into remote access.
The same repository also held credentials for internal systems, including artifactory and Landing Zone DevSecOps. That widens the blast radius fast. Once those files are public, access is no longer limited to the cloud account itself. Build artefacts, package stores and deployment paths all become reachable if the exposed passwords are still live.
CI/CD files make the situation messier because they often encode how code moves from a repo into production. If those files sit next to valid secrets, an attacker does not need to guess the shape of the pipeline. The repo shows the shape for free. Internal deployment files also reveal naming, environment structure and the bits of the stack that are usually hidden behind a ticketing system and a few too many permissions.
What stands out here is how little friction there was after publication. The keys remained valid for 48 hours after notification, which is a generous window for anyone trying to use them and a poor look for any secret rotation process. Old credentials do not stop being dangerous because somebody has been told about them.
What this says about repo hygiene and secret scanning
Public repositories often get treated as code-only spaces, then someone drops in a password file because it is convenient or temporary or meant for a single machine. That is how internal deployment files and credentials end up living together in a place that was never supposed to hold them.
Secret scanning helps only if it is left on and treated as a hard boundary. If a repository owner can disable it casually, the protection is already too soft. The pattern here is not subtle: secret detection off, plaintext credentials present, backups in git, and a public repo carrying enough detail to map internal systems.
There is also a more boring failure hiding in the details. Some passwords used the platform name plus the current year, which is exactly the sort of thing that survives in the wild because people expect it to be good enough for one more week. It rarely is.
Closing the hole before the next repo turns into an incident
Remove the valid credentials, rotate the affected accounts, and look for copies in other repositories, local clones and backup sets. If the same secret appears in CI/CD files, package managers or deployment scripts, treat each copy as live until it is replaced.
For AWS GovCloud credentials, rotation needs to be immediate and complete. That means the access keys, the associated account credentials and any downstream tokens that depend on them. If artifactory credentials or internal deployment files were exposed at the same time, those need the same treatment. Leaving one path open just hands the problem to the next person who checks the repo.
The cleaner habit is dull but effective: keep secrets out of public GitHub repositories, leave secret blocking switched on, and stop committing backup files with operational data in them. Anything else is just hoping nobody notices the next time a repository gets used as shared storage.
