The agency whose entire job is telling you how to secure your infrastructure had its own contractor disable GitHub secret scanning and push AWS GovCloud keys, plaintext passwords, and an RSA private key to a public repository. The repo sat open for six months. Nobody at CISA noticed. A third-party scanner noticed. That is like leaving your front door wide open for half a year and only finding out because a passing mailman mentioned it.
The contractor created a GitHub profile called "Private-CISA" - the word "Private" doing absolutely no work here - in November 2025 and filled it with files named AWS-Workspace-Firefox-Passwords.csv, Important AWS Tokens.txt, and kube-config.txt (KrebsOnSecurity). Not encoded. Not encrypted. Plaintext CSV exports from Firefox's password manager, sitting in a public repo anyone could clone. You could not design a more careless credential dump if you tried.
But the part that should make every DevOps engineer wince: the contractor deliberately disabled GitHub's built-in secret scanning before pushing credentials. Commit logs confirm it (KrebsOnSecurity). The one automated safeguard that would have flagged this was turned off by the person whose job was to administer CISA's code platform. Turning it off was a choice, the equivalent of disabling the smoke detector before you start cooking.
The most damaging exposure was an RSA private key tied to a GitHub App with full access to the CISA-IT organization. That single key could read every private repository, register rogue CI/CD runners to hijack build pipelines, and modify branch protection rules and deploy keys. A skeleton key to the entire building, left under the doormat. TruffleHog's Dylan Ayrey found this key still live two days after KrebsOnSecurity's initial May 18 report (TruffleHog). The repo was already public knowledge by then. Anyone monitoring GitHub's public event feed - and both researchers and botnets do, continuously - could have been sitting on it for weeks.
CISA's official response: "There is no indication that any sensitive data was compromised as a result of the incident" (KrebsOnSecurity). A repo with dozens of plaintext credentials was public for six months, but CISA assures us nothing happened. "No indication" is doing a lot of heavy lifting in that sentence. It translates to: we cannot prove anyone grabbed the keys, so we will assume nobody did. The Hacker News community was unconvinced: the thread hit 476 points and 183 comments, with multiple people pointing out that GitHub's public event firehose is monitored by both researchers and threat actors around the clock.
More than a week after notification, CISA was still rotating credentials (KrebsOnSecurity). The gap between "repo taken down" and "secrets actually invalidated" turned out to be far wider than the agency's statement suggests. Deleting the repo does not revoke the keys. Any attacker who cloned it in those six months still had valid credentials for days after the breach became public.
Three developer lessons worth extracting from this:
Secret scanning is not optional. If your org allows disabling it, you have a policy problem, not just a tooling problem. Enforce it at the organization level and block overrides.
Credential rotation timelines matter more than detection timelines. Finding a leak in hours means nothing if revoking access takes days. Map your rotation procedures and test them before you need them.
Shared credentials in CSV files are a systemic failure. AWS Organizations lets each admin authenticate individually with short-lived tokens and full audit trails. The "we need shared passwords" argument does not survive contact with modern IAM.
CISA is hardly alone here: the same CSV-in-a-repo pattern shows up in breach reports from startups, banks, and cloud providers. The difference is that CISA is supposed to be the agency that teaches everyone else how to do this right.