CISA has published a candid after-action account revealing that a contractor accidentally exposed the agency’s own AWS GovCloud credentials and Infrastructure-as-Code repositories in a personal, public GitHub account, triggering an internal incident response and a rare public “lessons learned” disclosure from the federal cybersecurity agency itself.
On Friday, May 15, CISA’s incident response began after an investigative reporter contacted the agency about internal AWS GovCloud keys visible in a public code repository.
The reporter had been tipped off by a security researcher whose firm continuously scans public repositories for exposed secrets, and that researcher continued sharing findings with CISA throughout the response.
CISA’s Office of the Chief Information Officer moved within moments to contain the exposure, following a “stop the bleeding” approach. The team took the public repository offline while preserving a forensic copy, shut down the affected development environment, reset associated credentials, and revoked the individual’s system access.
Investigators determined the exposed material was not part of CISA’s official GitHub presence but rather a personal repository belonging to a contractor who had copied the agency’s build and deployment code, along with admin and build credentials, to automate cloud infrastructure creation.
Forensic log analysis confirmed that the leaked credentials were never used outside CISA’s own environments and that no customer or mission data was exposed.
As a precaution, CISA rotated every credential across all environments where the individual held administrative access not just the specific keys that leaked and tightened allow/deny lists for code repositories while restricting users’ ability to upload to public repos.
CISA’s after-action review, identified both strengths and gaps. The agency credited external reporting and Zero Trust visibility for enabling a fast response, but flagged several areas needing improvement:
| Area | Key Finding | Corrective Action |
|---|---|---|
| Public repo controls | Developers could upload directly to public repositories | Shifted monitoring to EDR-based controls to allow pulling code while blocking sensitive uploads. |
| Secrets management | Secrets existed in private repos despite policy | Rotated all secrets; built an action plan for ongoing secret detection. |
| Playbooks | No dedicated GitHub/cloud incident playbook existed | Built one mid-incident; now refining playbooks based on the response. |
| Reporting channels | Researcher tried multiple unclear channels (contractor email, vulnerability disclosure platform, a reporter) | Consolidating and publicizing clearer reporting paths, including security.txt. |
| Dev environment sprawl | Consolidation of developer environments was still in progress | Accelerated consolidation efforts for consistent controls. |
| Key rotation speed | Complex system interconnections slowed credential rotation | Recommends organizations build mature, well-tested key-management/rotation capabilities. |
Security analysts note the case underscores a human-risk dimension as much as a technical one: contractors and third parties handling infrastructure code need the same credential-hygiene training and offboarding rigor as full-time staff, since honest mistakes under normal working conditions not sophisticated attacks caused the exposure.
CISA framed the disclosure around a “when, not if” philosophy, arguing that transparency about its own incident builds trust and gives other organizations concrete, actionable takeaways for strengthening credential management, repository governance, and incident-reporting clarity in their own environments.
Stop Accepting SLAs Written for 2019 SOCs – Here’s the 2026 AI SLA Vendor Checklist – Download Free AI SOC SLA Guide
