A six-month exposure of AWS GovCloud credentials and plaintext passwords in a public repository has prompted a rare and unusually frank government postmortem.
Summary
- A contractor published 844 MB of sensitive CISA data — including AWS GovCloud admin keys and plaintext passwords — to a public GitHub repository, where it sat for roughly six months.
- CISA ignored nine automated alerts from secrets-scanning firm GitGuardian before a reporter’s notification finally prompted action; revocation of the AWS keys then took more than 48 hours.
- CISA’s incident response playbook had no provisions covering GitHub or cloud services, and internal reporting channels were not clearly distinguished from external vulnerability disclosure processes.
- Detailed logging and zero-trust controls allowed CISA to confirm no customer or mission data was accessed via the exposed credentials.
- CISA has published a postmortem advocating continuous secrets scanning, mature key management, and clear researcher-facing reporting channels — practices it acknowledges it did not fully have in place.
How the exposure unfolded
On 15 May 2026, security firm GitGuardian contacted KrebsOnSecurity for assistance in notifying CISA about a public GitHub repository named “Private CISA” containing 844 MB of sensitive agency data. Among the files were administrative credentials to three Amazon AWS GovCloud servers and a CSV file listing plaintext usernames and passwords for dozens of internal CISA systems. The repository had been publicly accessible for close to six months before that notification.
Nine ignored alerts
The more pointed detail sits upstream of that notification. GitGuardian’s automated scanning had already sent nine alert emails directly to the responsible accounts before the matter was escalated through a journalist. Guillaume Valadon, the GitGuardian researcher who pursued the disclosure, characterised the outcome succinctly: “Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure.” Once CISA was engaged, the agency acknowledged the alert promptly but still required more than 48 hours to invalidate the AWS keys and other exposed secrets.
Playbook gaps and routing failures
CISA’s postmortem, authored by acting CIO Preston Werntz and acting CISO Brad Libbey, is candid about the structural problems that compounded the delay. The agency’s incident response playbook had no guidance covering GitHub or cloud services. Internally, the channels for reporting an incident affecting CISA’s own infrastructure were not clearly separated from those intended for external vulnerability disclosures. As a result, the researcher ended up trying multiple avenues — emailing the contractor, submitting through CISA’s vulnerability disclosure platform, and eventually involving a reporter — before the right people were reached. The report notes that CISA is now refining those reporting channels to be faster and less ambiguous.
Where existing controls held
The picture is not entirely one-sided. CISA credited its enhanced logging capabilities and the adoption of zero-trust principles across both production and development environments with allowing investigators to establish that the leaked credentials were not used outside CISA’s own systems and that no customer or mission data was compromised. The contractor responsible had their system access revoked. These are meaningful controls, and the postmortem gives them appropriate credit without overstating their role in preventing the initial exposure.
On continuous scanning
The agency’s report endorses continuous scanning of public code repositories — a position Valadon described as historically significant. He noted that, to his knowledge, this is the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers. CISA’s own assessment found that had comprehensive internal scanning been in place, the plaintext passwords and committed backups could have been identified before they ever reached a public repository.
A model for incident communication
Whatever its operational shortcomings, the postmortem itself has attracted quiet praise from the security research community. Valadon wrote that it represents “exactly the incident communication we should expect from every organisation” — a public, factual account of what worked and what did not, without deflection. That standard is rarely met in the private sector, let alone in government.
Why it matters
The CISA incident illustrates a failure mode that is commonplace across enterprises: a contractor commits credentials to a public repository, automated alerts are routed to an inbox nobody is watching, and the exposure compounds for months before an external party forces the issue. For CISOs, the systemic risks here are not exotic. Secrets committed to public repositories, playbooks that have not been updated to reflect cloud and SaaS environments, and ambiguous disclosure channels are pervasive. What is unusual is the quality of the postmortem — CISA has produced a detailed, attributable account of its own failures that security teams can use as a benchmark to audit their own posture.
What to do now
- Implement continuous — not periodic — automated scanning of public code repositories for exposed credentials and secrets belonging to your organisation.
- Establish and test internal scanning pipelines capable of detecting plaintext secrets and sensitive files before they leave controlled environments.
- Ensure your incident response playbook explicitly covers cloud services and public code repositories, including defined procedures for credential revocation and rotation with tested timescales.
- Create clearly separated reporting channels: one for external vulnerability disclosures affecting your products, and a distinct, well-publicised channel for reports affecting your own infrastructure.
- Publish researcher reporting instructions in multiple prominent locations beyond security.txt, and assign ownership to ensure inbound notifications are triaged promptly.
- Build and regularly exercise key rotation capabilities so that revocation of cloud credentials can be completed within hours, not days.
