The 844 MB Wake-Up Call
On May 15, 2026, security firm GitGuardian spotted something alarming: a public GitHub repository named “Private CISA” containing 844 MB of sensitive data from the Cybersecurity and Infrastructure Security Agency (CISA). Inside sat files like “importantAWStokens” — administrative credentials to three AWS GovCloud servers — and a CSV listing plaintext usernames and passwords for dozens of internal CISA systems.
The repository had been public for nearly six months before KrebsOnSecurity alerted the agency. CISA’s own postmortem, published by acting CIO Preston Werntz and acting CISO Brad Libbey, doesn’t sugarcoat what went wrong. It’s a rare, transparent look at how a national cybersecurity agency fumbled its own security — and what every organization can learn from the mess.
Key Rotation Took Too Long
CISA acknowledged the alert quickly, but invalidating the exposed AWS keys and other secrets took more than 48 hours. The agency blamed the delay on “complexities of the agency’s systems and interconnections with federal and industry partners.”
The lesson is blunt: key rotation must be fast and well-practiced. CISA now recommends that all organizations maintain “mature and well-tested key management capabilities.” If rotating a compromised credential takes two days, an attacker has a wide window to cause damage.
Why Speed Matters
Every hour a credential stays live increases risk. The postmortem doesn’t say whether the exposed keys were used maliciously, but it does confirm that detailed logs showed no unauthorized access. That’s lucky — not a strategy.
Nine Ignored Alerts, Six Months of Exposure
Guillaume Valadon, the GitGuardian researcher who first contacted KrebsOnSecurity, revealed a damning detail: CISA had received nine automated alerts about the exposed credentials before the May 15 notification. Each alert went unanswered.
“Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,” Valadon wrote in his own analysis. His point is sharp: automated scanning is useless if nobody reads the reports.
Organizations should configure alerts to escalate if ignored. A single unread email shouldn’t leave sensitive data exposed for half a year.
Reporting Channels Were a Maze
When Valadon tried to report the leak, he hit dead ends. CISA’s vulnerability disclosure platform was designed for product bugs, not reports about the agency’s own infrastructure. He ended up emailing the contractor who leaked the data, submitting through the wrong channel, and eventually going to a reporter.
The postmortem admits these channels “were not well defined.” CISA is now refining them to make reporting faster and easier. The agency also stresses that organizations should publish reporting instructions in multiple prominent locations — not just a security.txt file.
Valadon’s advice: “Make it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat.”
The Playbook Didn’t Cover GitHub
CISA had an incident response playbook, but it somehow didn’t include scenarios involving GitHub or other cloud services. That gap meant the team had to improvise when dealing with a public repository full of their own secrets.
The lesson is straightforward: incident response playbooks must cover modern attack surfaces. Cloud repositories, CI/CD pipelines, and third-party integrations all need dedicated procedures. If your playbook only covers traditional network intrusions, you’re not ready for today’s threats.
Continuous Scanning Is Non-Negotiable
The “Private CISA” repository sat exposed for six months. GitGuardian found it through continuous monitoring of public GitHub — not a quarterly scan. Valadon argues that comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.
CISA has since rotated all secrets and created an action plan to improve developer secret management and monitoring. The agency now advocates for continuous secrets scanning, a practice Valadon calls “exactly the incident communication we should expect from every organization.”
What Went Right: Logging and Zero Trust
CISA gave itself passing grades on several fronts. Enhanced logging capabilities allowed the agency to gauge the scope and impact of the exposure. Adoption of zero-trust principles in both production and development systems meant that even though credentials leaked, they couldn’t be used outside CISA’s environments.
The agency confirmed that no customer or mission data was exposed, and the contractor who leaked the secrets had their system access revoked. These controls prevented a bad situation from becoming catastrophic.
The Biggest Takeaway: Transparency
Valadon praised CISA for publishing the postmortem at all. “To my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers,” he wrote.
That’s the real lesson. A detailed, honest post-incident report — one that admits mistakes and offers concrete fixes — builds trust. It also helps the entire security community improve. Every organization should aim for that level of candor.
For more on securing your development workflows, check out our guide on GitHub secrets scanning best practices and learn how to set up automated credential monitoring.
