The Leak That Wasn’t on CISA’s Radar
In May, security researchers from GitGuardian spotted something alarming — a public GitHub repository containing credentials to multiple highly privileged AWS GovCloud accounts. The repo also exposed keys to a large number of internal CISA systems.
Here’s the twist: the repository didn’t belong to CISA’s official GitHub organization. It was a personal repo owned by a contractor. And it was wide open.
KrebsOnSecurity broke the story in May. CISA’s formal response landed on June 9, offering a rare, unvarnished look at how a federal agency handles a cloud credential spill.
Timeline: From Alert to Action
CISA’s internal incident response kicked off on May 15 — the same day the agency learned of the exposure. The Office of the Chief Information Officer (OCIO) moved fast.
“Within moments of receiving this information, CISA’s OCIO took swift and comprehensive action to mitigate any exposure to CISA’s cloud resources and code repositories,” the agency wrote in its June 9 update.
Incident responders focused on five priorities:
- Eliminating public exposure of the credentials
- Preventing further harm to CISA systems
- Understanding the full scope of what was shared
- Assessing the operational impact
- Implementing corrective actions
Critically, CISA confirmed that no customer or mission data was accessed. The leaked credentials were never used outside CISA’s own environments.
How the Keys Ended Up on GitHub
The contractor uploaded copies of a CISA build and deployment repository to their personal GitHub account. Their stated goal: to automate cloud infrastructure creation.
That repository contained CISA’s Infrastructure as Code (IaC) and build code — sensitive material that should never have left the agency’s controlled environment.
It’s a classic insider risk scenario, but with a twist: the contractor wasn’t malicious. They simply ignored basic security hygiene. And because CISA lacked tight controls over public code repository access, the mistake went unnoticed until an external researcher flagged it.
What CISA Got Right — And Where It Fell Short
CISA’s response was far from a PR whitewash. The agency openly acknowledged gaps in its defenses.
Areas flagged for improvement include:
- Tighter controls over public code repository access
- Stronger monitoring for exposed secrets
- Comprehensive GitHub and cloud incident-response playbooks (which apparently didn’t exist before)
- Simpler security researcher reporting channels
- Better cryptographic key management for faster credential rotation
On the reporting side, CISA admitted its vulnerability disclosure platform wasn’t designed for this kind of incident. The researcher ended up emailing the contractor directly, filing through CISA’s public disclosure portal (meant for broader community vulnerabilities), and finally looping in a reporter before the agency took action.
“These channels were not well defined,” CISA wrote.
The Zero Trust Lesson and Logging Wins
CISA used the incident to reinforce the importance of zero trust principles — not just for protecting systems, but for securing development environments where code is built and deployed.
Strong logging also proved its worth. CISA’s Security Operations Center (SOC) had the logs needed to investigate the breach thoroughly. The agency called continuous improvement of logging capabilities “a key element of a strong security program.”
That’s worth noting: good logs don’t prevent leaks, but they make incident response vastly more effective.
Transparency as a Security Tool
Perhaps the most striking part of CISA’s update is its closing reflection: “It is not a matter of ‘if’, but ‘when’ a cybersecurity incident will happen to your organization. It is important to the broader cybersecurity community that we address these matters openly to strengthen trust and foster transparency. Such transparency unlocks opportunities for learning that will enhance not only CISA’s security posture but that of other organizations as well.”
That’s a refreshingly honest take from a federal agency. CISA published the update on its LinkedIn channel, where one commenter praised the agency for documenting both its strengths and its gaps.
The lesson for other organizations? Build the playbooks before the breach. Tighten access controls on code repositories. And when a researcher tries to report a leak, make sure they know exactly where to go.
Because the next exposed key might not belong to a federal agency — it could be yours.
