He pressed the publish button and walked away. For months, a repository called Private-CISA sat public on GitHub with admin tokens and plain-text passwords inside. I found out, as you just did, that the keys to a government cloud were visible to anyone with a link.
I’m going to walk you through what happened, what was exposed, who found it, and why this matters to you. Read fast — the danger of this kind of mistake is not abstract.
A developer copied work files to a home device: What leaked and how it happened
The repository was created in November, and sometime after a contractor tried moving files from a work machine to a home one, those files landed on GitHub. According to Krebs on Security, an employee for a contractor named Nightwing used a public GitHub repo as a transfer point — effectively treating a public code host like an email draft folder.
Inside: an AWS file labeled importantAWStokens holding administrative credentials for three Amazon AWS GovCloud servers, and a .CSV called AWS-Workspace-Firefox-Passwords.csv with plaintext usernames and passwords for dozens of internal systems, including a landing zone DevSecOps environment. In short, secrets that belong behind layered defenses were stored as readable text.
How did CISA leak its AWS keys on GitHub?
GitHub was used as a hand-off. The contractor pushed files to a public repository named Private-CISA, and those files contained tokens, keys, and passwords. Guillaume Valadon of GitGuardian — a firm that scans GitHub for exposed secrets — called it “the worst leak that I’ve witnessed in my career.” Krebs on Security first reported the exposure and CISA said it’s investigating.
An obvious repository name sat exposed: Why this is worse than a misclick
A plainly named repo — Private-CISA — is not subtle. That label turned an error into an open invitation.
Errors happen. What makes this alarming is scale and content. These weren’t ephemeral notes; they were administrative credentials to AWS GovCloud, the part of Amazon’s cloud used for sensitive government workloads. With those credentials anyone could probe systems, extract data, or pivot to other environments. The danger here is not only what sat there, but how easy it would be for a malicious actor to misuse it.
Were CISA systems compromised by the GitHub exposure?
CISA says there’s “no indication that any sensitive data was compromised” so far. That’s a clean statement, but it’s passive: detection gaps are common, and damage can show up later. The public disclosure window — the repo existed since November — means the exposure window might have been months long, even if the sensitive files were added later.
A security firm flagged the leak: Who found it and what they said
A security company that scans public code hosts noticed the guilty file tree and sounded the alarm. That’s how these things usually end up in the light.
GitGuardian’s Valadon raised the alarm to Krebs, and the story spread. This is the ecosystem: scanners, researchers, journalists. Krebs quoted both the file names and the contents, and cited internal system names such as “LZ-DSO” (Landing Zone DevSecOps). When a vendor calls it “the worst leak” they’ve seen, take that as a serious red flag, not a punchy headline.
Metaphor 1: The repository was a glass house with the blinds wide open.
A turbulent leadership backdrop: How politics and management amplify risk
Leadership at CISA has been unstable, and agency morale has followed. That’s the climate this mistake occurred in.
CISA is a relatively young arm of DHS. It was created by law in 2018 and later became a political football: the director Christopher Krebs was fired after trying to correct election misinformation, and since then acting directors appointed during the current administration haven’t been Senate-confirmed. The story Krebs reported threaded technical negligence into a larger picture of an agency under pressure from budget fights and political friction. When people are stretched and oversight is fragmented, operational hygiene slips.
Avoiding repeat mistakes: What defenders and vendors must do differently
A team found credentials in plain text. That simple fact tells you where to start fixing things.
First, stop treating GitHub like temporary storage for secrets. Use secret management tools tied to identity providers and rotate keys often. Platforms like Amazon Web Services offer IAM practices and GovCloud-specific controls; combine those with scanning services — GitGuardian wasn’t lucky, it exists for this exact reason. Second, enforce automated pre-commit checks, git-secrets hooks, and CI pipelines that block pushes containing credentials. Third, mandate least-privilege permissions and treat every token as if it will one day be public.
Metaphor 2: The exposed keys were a loaded gun left on a mantel in a crowded house.
An agency response and the unanswered questions: What CISA said and what we still need to know
CISA issued a short statement claiming no indication of compromise and promising additional safeguards.
The statement reads well on paper but raises operational questions: when were the specific secrets added, who had access, were any of the exposed keys actively used, and what monitoring detected the leak? Public assurance is one thing; a detailed after-action that names corrective steps, timelines, and accountability is another. You should expect transparency because this affects national resilience.
A wider lesson: Why this matters to businesses and citizens
If a federal cybersecurity agency can leak administrative credentials, every private company and local government should pay attention.
This incident is a plain reminder that human workflows fail. If your team emails secrets to themselves, stores tokens in spreadsheets, or uses public repos for transfer, you’re one mistake away from exposure. Tools exist to reduce risk: hashed secrets, short-lived tokens, SSO-backed access, and proactive scanning. Use them, and pressure vendors and partners to do the same.
We’ve seen the detection chain that caught this one start with a scanning company and end with a journalist’s byline. The question now is whether the people in charge will fix the operational holes or simply close the door and hope no one notices again?