CISA Built Its Incident Response Playbook During the Actual Incident

There is a particular kind of horror that comes with discovering your organisation has no plan for the exact crisis you are currently living through. That is apparently what happened at the Cybersecurity and Infrastructure Security Agency — the US government body whose entire job is to help other organisations respond to cyber incidents — when a contractor exposed a trove of sensitive passwords on a public GitHub repository.

The story broke in May 2026, when independent cybersecurity journalist Brian Krebs reported that a security researcher at GitGuardian had spotted reams of exposed credentials sitting in a publicly accessible GitHub repo. The passwords had been uploaded by an employee of a CISA contractor. Embarrassing enough on its own. But the detail that has since emerged is arguably more alarming: CISA had to construct its own incident response playbook on the fly, while the incident was actively unfolding.

The Cobbler's Children Problem, But for Cybersecurity

This is a well-documented phenomenon in the security world. The organisations that spend their days advising others on resilience and preparedness sometimes neglect to apply the same rigour internally. CISA is not a small, under-resourced charity — it is a federal agency with a specific mandate to protect US critical infrastructure and to coordinate national cyber defence. The idea that it lacked a documented, rehearsed process for responding to a data exposure incident is not just ironic. It is a genuine institutional failure.

To be fair to CISA, the agency has acknowledged the gap, and the fact that it is publicly disclosing what went wrong is more transparency than most government bodies manage. Accountability matters. But the broader picture here is uncomfortable. If CISA does not have its house in order, it raises legitimate questions about how well-prepared other federal agencies are for similar incidents.

The GitHub exposure itself is the kind of mistake that security teams warn about constantly. Developers and contractors often use GitHub to store code, and it is surprisingly easy to accidentally commit credential files, API keys, or configuration data that should never be public. GitGuardian specifically exists to scan for these kinds of leaks — the company monitors public repositories in real time and alerts organisations when their secrets appear online. The fact that it was a third-party researcher who caught this, rather than CISA's own monitoring, is another thread worth pulling.

Third-Party Contractors Remain a Weak Link

This incident fits a pattern that has become almost tedious in its repetition. A major breach or exposure happens not through the core organisation but through a contractor or supplier with privileged access and, apparently, weaker security hygiene. We saw it with the SolarWinds attack in 2020. We have seen it repeatedly across financial services, healthcare, and government. The supply chain is the soft underbelly, and it keeps getting targeted because it keeps being vulnerable.

CISA has been vocal about third-party risk for years. It publishes guidance on it. It runs awareness campaigns about it. The contractor whose employee uploaded those passwords presumably had some kind of security agreement with CISA. And yet here we are.

The missing playbook detail is what makes this story stick. Incident response planning is not exotic or technically demanding. It is documentation work. It is tabletop exercises. It is knowing, before the alarm goes off, who calls whom, what gets isolated, what gets disclosed and when. The fact that CISA had to write the playbook while fighting the fire suggests that the planning work simply had not been done — or had not been done for this class of incident.

There will be an after-action review. There will be updated documentation. Whether the cultural change required to prevent the next gap actually takes hold is a different question. For an agency that exists to model best practice in cybersecurity, this one stings.