Security1 publisher2 min readPublished
An outside researcher's scan found CISA's GovCloud admin keys in a contractor's personal repo
CISA has published the after-action report for an incident its own tooling missed. A researcher who continuously scans public code repositories spotted admin and build credentials and told a reporter.
The Watch · Security desk
What happened
- CISA opened an internal incident response on Friday, May 15, after an investigative reporter asked about internal AWS GovCloud keys and other information available in a public code repository.
- CISA took the repository offline and kept a copy for analysis, took its development environment offline and reset its credentials, and revoked the individual's system access.
- Log analysis found the leaked credentials were not used outside CISA's environments and that no customer or mission data was exposed.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Where developers can push to personal accounts, the sensitive copy lands outside the account boundary the security team administers, and an outside scanner sees it before the owner does.
- cost Cleanup scaled with the individual's privileges: CISA rotated all credentials in every environment where they held admin, well past the two credential types in the repository.
- constraint Putting the upload control in EDR ties coverage to the endpoint fleet, so every machine that can push code has to be running the agent, contractors' machines included.
- precedent Defenders arguing for secret scanning across developer-controlled repositories now have a federal after-action report to cite, written by the agency that issues the guidance.
Two people handled the find before the agency did. A security researcher whose company continuously scans public code repositories passed it to an investigative reporter, and the reporter put the question to CISA [2]. The case opened on that inquiry [1][17].
The repository sat outside CISA's official GitHub [4]. A contractor had copied a CISA build and deployment repository, Infrastructure as Code and build code included, into a personal account [5]. Admin and build credentials went into the same public repository [7]. The copy sat in an account outside the agency's administration [4].
The upload had a purpose. CISA said the contractor copied the repository in order to create cloud infrastructure autonomously [6].
CISA's after-action report credits three things that worked: taking the external tip seriously, Zero Trust principles applied to the development environment and not only to production, and logs complete enough for its SOC to run the investigation [11][12][13]. CISA identified further logging opportunities during the response and has since implemented them [13]. The report does not say when the copy was pushed or how long the credentials were reachable.
CISA tuned the allow and deny lists on its code repositories, limited user ability to upload to public repositories, and brought the development environment back online [10]. Users had been able to upload to public repositories [19]. After reviewing its Zero Trust tooling, the agency settled on its EDR product to monitor and manage uploads. The choice keeps the pull path open for developers while reducing the risk of pushing intellectual property or sensitive content out [14]. The rule blocks the push. The reason the contractor made the copy is still there [6][14].
On the second gap, CISA wrote: "No repository should contain secrets, yet secrets made it into CISA private repositories" [15]. The agency said it has since rotated all secrets and created an action plan for managing them [16].
What to watch
- Whether CISA's secrets-management action plan turns into published guidance or a directive that binds other federal agencies.
- Whether the EDR-based upload control extends to contractor-owned devices, or only to CISA-managed endpoints.
- Whether the researcher's company or the reporter publishes a discovery timeline. That would fix how long the keys were exposed.