A contractor’s personal repository put a security agency’s cloud keys in public view. CISA says a contractor copied a build and deployment repository to a personal GitHub account and added admin and build credentials, and a researcher who scans public code found it. CISA’s own lessons: control uploads, rotate everything the admin could reach, and write the GitHub and cloud playbook before you need it.
What happened at CISA in May 2026?
On Friday 15 May, CISA began an internal incident response. An investigative reporter had asked about internal CISA AWS GovCloud keys and other information in a public repository. The reporter got the material from a security researcher whose company continuously scans public code repositories.
The repository was not part of CISA’s official GitHub. It was a personal repository owned by a contractor. CISA says the leaked credentials were not used outside its own environments and that no customer or mission data was exposed. There is no public attribution, and CISA published its account on 9 July 2026. Our incident page holds the full record.
How does a personal repository become a path to cloud keys?
CISA says the individual uploaded copies of a CISA build and deployment repository to a personal GitHub account, for the purpose of creating cloud infrastructure autonomously. The repository included Infrastructure as Code and build code, and the individual also copied admin and build credentials into the public repository.
Two conditions made this possible, by CISA’s own account. CISA users had been able to upload to public repositories, and secrets had made it into CISA private repositories. The work happened outside the official GitHub, so the useful question for a buyer is which contractors hold cloud and code access, and whether they work in managed environments.
What did CISA’s response look like?
CISA limited the exposure first and tightened its controls after. The first actions were fast, and the longer work followed. The steps below follow CISA’s account.
- 15 May 2026Incident response beginsAn investigative reporter asked about AWS GovCloud keys in a public repository.
- First responseExposure limitedThe repository went offline with a copy saved. The development environment went offline and credentials were reset.
- First responseAccess revokedThe individual who exposed the keys lost system access.
- During the responseScope analyzedCISA studied the repository copy and security telemetry. Leaked credentials were not used outside its environments.
- During the responseControls tightenedAllow and deny lists for code repositories were tuned and uploads to public repositories were limited.
- After these actionsDevelopment environment back online
- 9 July 2026Lessons publishedCISA’s Acting CIO and Acting CISO shared what the response taught them.
Why rotate everything the admin could reach?
CISA rotated credentials in all environments where the individual was an administrator, not just the exposed ones. An exposed key shows what the person could do, and the same access may sit behind other keys.
Rotation was also slow. CISA says it took longer than anticipated because of system complexity and links with partners, and it urges mature, well-tested key-management capabilities. A fair check is how long it would take you to rotate every key in an environment, including those shared with partners, and whether you have ever tested it. Teams that want a second case of secrets in developer pipelines can read about the tj-actions supply chain incident.
Do you have a playbook for GitHub and cloud incidents?
CISA says it had missed creating a GitHub/Cloud playbook and had to spend time building one during the early stages of the incident. That is the plainest lesson in its post, and it applies to any organization that keeps code on GitHub and runs in the cloud.
Reporting was the other gap. CISA says its channels were not well defined, so the researcher emailed the contractor, submitted through CISA’s vulnerability disclosure platform, and then involved a reporter. That platform is intended for vulnerabilities affecting the broader community, not for an incident at CISA itself. CISA is refining its channels and advises publishing reporting instructions in several places, not only security.txt.
How could threat intelligence monitoring give early warning?
In this case, an outside party scanning public code found the material before CISA knew about it. Threat intelligence monitoring of exposed credentials works in a similar way: it watches for your keys or code appearing in public repositories and sends the finding to you directly, so you do not depend on a researcher’s email or a reporter’s call. This is not a promise of detection, and it does not replace controls on uploads.
CISA itself made an action plan to better monitor for exposed secrets going forward, and it uses its EDR tool to monitor and manage uploads. A buyer can ask which of these signals would reach your own team, and how fast.
What should a buyer check now?
A buyer should check five things now: uploads, secrets, rotation, playbooks and reporting.
- Uploads to public repositoriesCISA users could upload to them, and CISA now limits it.
- Secrets in repositoriesSecrets reached CISA private repositories, so scan private ones too.
- RotationCISA’s rotation took longer than expected. Test yours, including partner links.
- PlaybookCISA had none for GitHub and the cloud and wrote one mid-incident.
- ReportingGive researchers a clear way to report an incident that affects you.
CISA also credits granular Zero Trust principles in development environments, plus visibility and alerting across environments, and says its SOC had the logs needed to investigate. Treat development as seriously as production.
Related reading: Nx Console and GitHub: dev tools as an entry path.
Last checked against sources on 9 October 2026.