CISA postmortem: nine alerts ignored, six months exposed

CISA published a postmortem on its own six-month GitHub credential leak — the one KrebsOnSecurity flagged to the agency in May, after GitGuardian’s automated scanner had already fired nine notification emails into the void. What the postmortem actually says, once the reassurances are stripped away, is that the outside monitoring worked exactly the way it was supposed to. It was the intake on CISA’s side that didn’t.

The exposure itself: 844 MB of internal CISA material sitting in a public repository titled “Private CISA,” including AWS GovCloud administrative keys to three servers, a file straightforwardly named importantAWStokens, and a CSV called AWS-Workspace-Firefox-Passwords.csv containing plaintext usernames and passwords for internal systems. The contractor who published the repository is not named in the writeup. Their access has been revoked. Krebs walks the disclosure timeline in detail and it’s worth reading in full — the agency’s own postmortem is embedded there.

Two things stand out. First, GitGuardian’s monitoring had already surfaced the leak and tried to tell CISA about it — nine times, over months. “Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,” Guillaume Valadon of GitGuardian says in the piece, and that’s the whole shape of the failure. The signal was there. The system was watching. The receiving end wasn’t.

Second, once CISA did acknowledge the notification on May 15, key invalidation still took more than 48 hours. Preston Werntz and Brad Libbey, writing for the agency, attribute the delay to the complex interconnections between GovCloud systems and the mature key rotation those interconnections require. Read that the other way and it says: rotating an administrative key without breaking production takes days, the agency knew it took days, and there was no playbook for the specific case of “our own credentials are on public GitHub.” The recommendation the postmortem buries near the end — “make it trivial to report a leak about you, not just about your products” — is the honest one. Every vulnerability program at every large organization is built around receiving reports about the software the organization ships. The special case of a report about the organization itself has historically routed to a general-purpose inbox nobody checks with urgency. That is not a CISA problem specifically. It is a category problem.

The parallel worth drawing here is not to a prior CISA incident. It is to Datadog Security Labs’ work last week on dormant GitHub accounts enumerating corporate orgs, and to Noma’s earlier writeup on agentic-workflow leakage from private repos: the public GitHub surface of every large organization is now large enough that continuous outside monitoring finds things faster than the organization itself does. That is the recurring pattern — the same mistake, different decade, with GitHub playing the role that FTP servers once played and pastebins after them. What is new is the asymmetry. External scanners see everything within seconds; the receiving inbox on the target side is still a person who may or may not be at their desk.

The postmortem is candid about the reporting-channel gap. It is less candid about the key-rotation timing, which is where the actual damage window sits. Both are fixable. Neither will be fixed by better tooling alone.