CISA’s GitHub Leak Wasn’t the Real Failure. Nine Ignored Alerts Were

1

The leak was bad. The ignored security alerts were worse

Most coverage of CISA’s GitHub exposure leads with the headline facts. A public repository sat online for six months. It held AWS GovCloud keys and plaintext passwords, left there by a contractor. Still, those facts matter. But the detail that should actually change how security teams operate is smaller and far less dramatic: nine ignored security alerts from GitGuardian, sent straight to CISA’s account, that nobody acted on.

A contractor disabling a safety setting is a mistake anyone can make under deadline pressure. Nine ignored security alerts are different. They came from a working tool that did exactly what it was built to do. That is a policy failure, not an accident. Yet CISA had the warning. It just was not set up to hear it.

Tools do not fail quietly. People let them

It is tempting to call this a story about one careless contractor. He worked for government services firm Nightwing and copied files somewhere they should not have gone. That framing is comfortable. It puts the failure on one person, who can be blamed and removed. CISA duly did both.

But a single contractor’s mistake should never have had six months to matter. GitGuardian’s scanning worked. The alerting worked. What broke was everything after that. Yet nobody read the alerts. There was no defined channel for reporting the exposure. And the rotation process was so tangled that, even after discovery, the exposed keys stayed live for another two days.

This pattern is not unique to CISA, and that is exactly the point. Ask most security teams who reads their scanning tool’s alerts. You will get a name, a shrug, or silence. Alert fatigue is a well-worn phrase for a reason. Teams buy detection tools and wire them up. Then, once the volume becomes routine, they quietly stop looking at what those tools produce. A tool nobody watches is not a control. It is a compliance checkbox that happens to also do some scanning.

CISA’s own postmortem makes the same point

To its credit, CISA’s postmortem does not dodge this. It flags “clear and distinct reporting channels” as a missing piece. Incidents affecting the agency itself, it says, need a different path than reports about its products or customers. That is a polite way of putting it. Researchers trying to warn CISA about CISA did not know where to send the message. So nine automated pings sat unread, ignored security alerts stacking up in a queue nobody watched, until a journalist made the phone call that finally got a response.

Why this isn’t a government-only problem

It is easy for a business owner reading this to file it under “government IT, not my problem” and move on. That would be a mistake. GitHub, automated secret scanning, cloud key management: these are the same tools running under most mid-sized businesses’ code and infrastructure. Often, fewer people are watching them than at a federal agency.

Scale offers no protection here. If anything, a five-person development team is more likely than CISA to have nobody formally assigned to read scanner output. Nobody has had the conversation about whose job it is.

The uncomfortable question worth asking after a story like this is not “could this happen to us.” Every step here was ordinary: a contractor cutting a corner, a tool firing correctly, an alert landing in an inbox nobody checks. Given that, the more honest question is “how would we know if it already had.”

What this should change, practically

If your business runs any form of automated security monitoring, secret scanning, vulnerability alerts, anomaly detection, this incident is worth an honest internal audit, not just a nodding read. Three questions are worth asking this week:

• Who is named, by role, as the owner of each alerting tool’s output, and what happens if they are on leave?
• Is there a visible, monitored channel for external researchers to report an issue affecting you directly, separate from customer-facing support?
• When was the last time anyone tested whether an alert actually reaches a human within hours, rather than assuming it does?

None of these questions require new tooling. They require someone senior enough to admit the honest answer might be “nobody” or “we’re not sure.”

A lucky outcome, not proof it worked

CISA’s own logs show the leaked credentials were never used outside its systems. So no customer or mission data was exposed. That is genuinely good news. CISA’s clean-up was thorough once it started too: the repository and its build systems came offline, credentials were reset agency-wide, and a proper incident playbook finally got built.

But six months of exposure ending without exploitation is luck, not proof the process worked. The next business in this spot, government or private, may not get the same outcome from the same gap. The fix is not more tools. It is making sure the ones already installed have someone listening, so the next set of ignored security alerts does not sit unread for six months before a journalist has to make the call.