A contractor working for the Cybersecurity and Infrastructure Security Agency published dozens of internal CISA credentials, including AWS GovCloud keys, to a public GitHub repository. The repo sat exposed for almost six months. Nobody at CISA found it. A journalist did.

That journalist was Brian Krebs, and the fact that it took an outside reporter to flag a live credential leak inside the agency whose entire mission is helping the rest of the country do cybersecurity better is the kind of detail that writes its own headline. CISA has since published a postmortem on the incident, and to its credit, the agency didn’t try to spin it. The report lays out where its own detection and response process broke down. Those gaps are worth studying closely, because they’re not unique to CISA. They’re the same gaps sitting in your GitHub org right now.

The Leak Nobody Internally Caught

Here’s the part that should bother every security team reading this: GitHub has offered secret scanning, push protection, and partner notification programs for years. Amazon itself runs automated scanning that revokes or quarantines exposed AWS keys within minutes in many cases. None of that caught this. A GovCloud key set, the tier of AWS specifically built for federal workloads with elevated compliance requirements, sat live in a public repo for roughly half a year.

That’s not a failure of tooling. It’s a failure of ownership. Somewhere between the contractor’s account, CISA’s vendor oversight process, and whatever cloud security posture management the agency runs internally, there was no single team whose job it was to ask “does anything we don’t own have write access to anything we do?” Contractor-managed repos are a classic blind spot. They live outside the primary org’s audit scope, they don’t always inherit the parent organization’s branch protection or scanning rules, and unless someone explicitly maps them into the asset inventory, they’re invisible to threat detection until someone stumbles into them.

Contractor Access Is Still Your Attack Surface

The instinct after an incident like this is to blame the contractor and move on. Resist that. The contractor is a symptom. The real problem is that CISA, like most large organizations, treats third-party developer access as someone else’s security hardening problem right up until it isn’t. If a vendor’s engineer can generate a working AWS GovCloud key, that key needs to live under the same monitoring regime as a key generated by a full-time employee. There’s no defense in depth argument that excuses treating contractor infrastructure as out of scope.

This isn’t an abstract concern. The same week CISA’s postmortem landed, the EU and UK jointly sanctioned Russian operators, including the FSB’s Center 16, for cyber operations against European energy and water infrastructure. Nation-state actors are actively probing critical infrastructure operators for exactly this kind of soft entry point: a contractor account, a forgotten repo, a credential that never got rotated. An agency holding GovCloud access to federal systems is a high-value target by definition. Treating contractor credential hygiene as a paperwork exercise rather than an operational priority is how a six-month exposure window happens in the first place.

What The Postmortem Got Right

To CISA’s credit, the published lessons-learned document doesn’t dodge the timeline. It acknowledges that the internal response, once notified, moved slower than it should have, and that the initial triage undercounted how many credentials were actually exposed. That kind of candor is rare from a federal agency, and it’s worth naming as a good example of transparent incident response, even when the underlying story is embarrassing.

Where the postmortem is thinner is on root cause. It’s easy to document what happened after notification. It’s harder to explain why continuous scanning of public code repositories tied to agency personnel and contractors wasn’t already running before a reporter had to do it manually. Threat protection built around “we’ll respond fast once someone tells us” is not the same as threat protection built around “we’ll find it ourselves.” The former is incident response. The latter is actual security posture. CISA had the first. It didn’t have the second.

Building A Leak Response Plan That Doesn’t Depend On A Journalist

None of this requires exotic tooling. Most organizations already have the pieces; they just haven’t wired them together as policy. If your incident response plan currently has no defined owner for “credential exposed in a public code repository,” that’s the gap to close first, before the next audit, not after the next breach.

• Enable GitHub’s secret scanning and push protection org-wide, and extend it explicitly to any contractor-owned repos tied to your projects, not just repos inside your primary org
• Require short-lived, scoped credentials for contractor cloud access instead of long-lived static keys, so an exposed key expires before it becomes useful
• Run a quarterly external search sweep, GitHub, GitLab, pastebin-style sites, for your organization’s domain strings and key prefixes, the same search a journalist or attacker would run
• Put a named team on the hook for triaging leak reports within hours, not weeks, with a documented escalation path that doesn’t stall on “whose credential is this”
• Rotate contractor credentials on a fixed schedule regardless of whether a leak has been reported, treating rotation as routine security hardening rather than a breach response step

Firewall rules and brute-force protections matter, but they don’t help when the credential walked out the front door in a public commit. That’s a monitoring and ownership problem, and it’s fixable with process, not budget.

Sources

• Lessons Learned from CISA’s Recent GitHub Leak
• Russia’s FSB blamed for Poland grid attack as UK and EU impose first joint cyber sanctions
• EU and UK blacklist Russia’s cyber operators over efforts to destabilize Europe