What Actually Happened: The Basics of a Baffling Own-Goal
Sometime in November 2025, a public GitHub repository named “Private-CISA” began quietly broadcasting plaintext passwords, SSH private keys, authentication tokens, and other sensitive assets belonging to the Cybersecurity and Infrastructure Security Agency — the federal body responsible for defending American civilian infrastructure from exactly this kind of exposure. The repository was public, fully indexed, and discoverable by anyone with a search bar.
CISA did not catch it.
Guillaume Valadon, a researcher at GitGuardian, caught it — through automated public code scanning, the same category of tool that any competent security team should be running on their own infrastructure. Valadon attempted to contact the repository’s owner directly. He received no response. He then brought the findings to journalist Brian Krebs, who published the story and forced the issue into the open. The repository was taken offline after Krebs made contact with CISA.
The name “Private-CISA” deserves a moment of attention. It signals intent — someone knew this material was sensitive and labeled it accordingly. That makes the outcome worse, not better. This was not an accidental misconfiguration where a developer forgot to flip a visibility toggle on some throwaway test file. Credentials were committed deliberately into a repository that someone believed was private, and nobody verified that it actually was.
According to Valadon, the repository’s commit logs show that GitHub’s built-in secret-detection protections — default safeguards designed to catch exactly these kinds of mistakes before they go live — were bypassed. That detail matters. It means the exposure survived multiple layers of protection that exist specifically to stop this from happening, and CISA’s internal processes added nothing on top of them.
The agency that publishes guidance on secure software development, credential management, and responsible disclosure spent months with its own credentials sitting in plain sight, waiting for an outside researcher to notice.
The Missing Context Most Coverage Is Glossing Over: This Is a Process Failure, Not Just a Mistake
Accidentally pushing secrets to a public repository is not an exotic failure mode. It is one of the most documented, most warned-about mistakes in software development, and CISA knows this better than almost any organisation on earth. The agency publishes guidance, advisories, and best-practice frameworks specifically designed to help organisations avoid this class of error. That CISA committed it anyway is embarrassing. That nobody caught it for months is the more serious problem.
GitGuardian’s Guillaume Valadon discovered the exposure through GitGuardian’s automated public code scanning — the same category of tooling CISA recommends organisations deploy internally to catch exactly this kind of leak before it becomes a public incident. The repository, publicly visible on GitHub under the name “Private-CISA,” contained plaintext passwords, SSH private keys, and authentication tokens sitting in commit history since at least November 2025. Valadon attempted to contact the repository’s owner directly and received no response, which is why he brought the findings to Brian Krebs.
According to Valadon, the commit logs show that GitHub’s own default secret-scanning protections — the baseline safeguards GitHub activates automatically to catch credentials before they go public — were bypassed or ignored during the commit process. These are not optional enterprise features. They are standard, free, and on by default.
What this means is that CISA did not just make a human error. The agency failed at multiple layers simultaneously: a developer committed secrets, the commit bypassed default platform protections, no internal monitoring flagged the public exposure, and no one responded when an external researcher raised the alarm. Each of those layers represents a control that CISA’s own published guidance tells other organisations to have in place.
This is not a sophisticated intrusion. No attacker exploited a zero-day. No nation-state found a novel attack surface. A public repository sat open for months, containing credentials that should never have left an internal environment, and the agency responsible for raising America’s baseline security hygiene detected none of it on its own. CISA’s advisories classify this type of failure as entirely preventable. By CISA’s own standards, this was preventable.
Why the ‘Private-CISA’ Name Matters More Than a Punchline
The repository was named “Private-CISA.” It was public. That gap between intention and reality is not a punchline — it is the whole story compressed into two words.
The name signals one of two failures, and neither reflects well on the agency. Either the person who created the repository did not understand that GitHub’s default visibility setting is public and that naming a repo “private” does not make it private, or they understood perfectly well and assumed someone else had verified the configuration. The first failure is a skills problem. The second is an accountability problem. Both are exactly the kind of gap CISA spends its institutional energy warning critical infrastructure operators to close.
GitGuardian’s Guillaume Valadon flagged the repository through routine automated scanning of public GitHub code — the same category of tooling CISA recommends organisations deploy. The irony is structural: a third-party researcher using standard commercial tools found what CISA’s own internal processes missed, then received no response from the repository’s owner after attempting responsible disclosure. Krebs’ reporting only moved after Valadon escalated to him directly.
The accountability questions the name raises are specific. Who owned this repository? What GitHub organisation or personal account hosted it? Who held write access, and was that access list ever reviewed? CISA’s own guidance on supply chain security stresses the importance of repository access controls and periodic audits. The commit logs, according to Valadon, show that GitHub’s native secret-scanning protections were bypassed — meaning the exposure was not simply a matter of misconfigured visibility settings but an active circumvention of safeguards that exist precisely because developers make mistakes.
A one-off developer error is recoverable. A process that produces a public repository named “Private-CISA” containing plaintext passwords and SSH private keys, sits undiscovered for months, and surfaces only because an external scanner caught it — that is a cultural failure. The name did not cause the breach. The name just made the gap between what CISA preaches and what CISA practised impossible to ignore.
How It Was Found — and What That Says About the Detection Gap
GitGuardian’s automated public code scanning caught the exposure. CISA’s own internal monitoring did not. That single fact carries more weight than any policy failure memo could.
Guillaume Valadon, a researcher at GitGuardian, was alerted to the repository through the company’s routine scans of public code. The repo — named “Private-CISA,” a label that aged poorly — contained plaintext passwords, SSH private keys, tokens, and other sensitive CISA assets sitting openly on GitHub since at least November 2025. Valadon contacted the repo’s owner directly. He received no response. He then brought the findings to journalist Brian Krebs, who published the story and forced the issue into the open. The repo has since been taken offline.
The disclosure chain here is damning in its specificity: a private commercial tool detected the leak, a researcher tried and failed to get a response through direct contact, and a journalist became the mechanism of public accountability. CISA — the agency whose stated mission includes improving cybersecurity across critical infrastructure — was not part of that chain at any point until the story ran.
GitHub’s default secret-protection features exist precisely to catch this kind of mistake before it becomes a public record. According to Valadon, the commit logs show those protections were bypassed. That means someone actively overrode a guardrail designed to catch unskilled or inattentive developers — a category that should not include anyone working on systems tied to national infrastructure security.
GitGuardian’s scanning of public repositories functions as a genuine public good in cases like this. The company routinely surfaces credentials, API keys, and private tokens that developers accidentally expose. But that service also documents a systemic reality: sensitive material bleeds into public code repositories constantly, across organizations of every size and security posture. The fact that CISA appears in that population is not just embarrassing — it confirms that the detection gap between what gets exposed and what gets caught is being bridged by commercial vendors, not by the institutions responsible for closing it.
The Broader Stakes: Why This Damages More Than Just CISA’s Reputation
CISA’s entire authority rests on a simple premise: it knows how to secure systems better than the organizations it regulates. That premise is now cracked. When CISA issues a Binding Operational Directive to federal agencies — legally enforceable mandates that carry real compliance costs and deadlines — those agencies comply partly because they assume CISA operates at a higher standard. A public GitHub repository named “Private-CISA,” sitting exposed since at least November 2025 and packed with plaintext passwords, SSH private keys, and authentication tokens, destroys that assumption. CISA cannot credibly demand that federal contractors rotate credentials and audit their repositories when its own personnel committed secrets to a public repo and apparently defeated GitHub’s built-in protections to do so.
The national security dimension extends well beyond embarrassment. SSH private keys and authentication tokens are not just passwords — they grant persistent, often privileged access to systems without requiring repeated authentication. Depending on what infrastructure those credentials authenticated, the exposure window stretches across months. The full blast radius remains unknown publicly, which is itself a problem. Adversaries who discovered the repository before GitGuardian’s Guillaume Valadon flagged it to Brian Krebs had ample time to move laterally through any accessible systems, harvest data, and cover their tracks.
The political timing makes this worse. CISA is already absorbing budget cuts and operating under heightened scrutiny from lawmakers skeptical of its mission scope. Critics who want to curtail the agency’s authority or slash its funding now have something concrete: not an abstract argument about regulatory overreach, but a documented operational failure at the agency’s own hands. CISA’s ability to argue for expanded resources, stronger legal authority, or a broader mandate depends on maintaining credibility as a competent operator. This incident hands opponents a permanent reference point in every future budget negotiation and oversight hearing.
The damage compounds because the failure was entirely self-inflicted and entirely preventable. GitHub’s default secret-scanning protections exist precisely to catch this class of mistake. Someone actively bypassed them.
What Needs to Happen Next — and What Probably Won’t
Credential rotation across every exposed key, token, and password is the minimum acceptable first step — not the response itself. CISA must treat anything that touched that repository as fully compromised until proven otherwise. That means SSH private keys, API tokens, plaintext passwords, and any downstream systems they authenticate into. Rotation is the floor.
Above that floor, CISA owes the public a detailed post-mortem. The repository named “Private-CISA” sat publicly accessible on GitHub from at least November 2025 until a security researcher surfaced it. GitGuardian’s Guillaume Valadon discovered it through automated public code scanning and spent weeks attempting to reach the repository’s owner before escalating to Brian Krebs. CISA never responded. That timeline — months of exposure, zero internal detection, silence when contacted — demands an explanation. The post-mortem must answer four questions: how the repository became public in the first place, how long it was actually exposed, whether any credentials were accessed and by whom, and why no internal process caught it during that entire window.
The longer-term case this incident makes is almost too obvious to state. CISA has directly recommended that organizations implement mandatory secret-scanning in CI/CD pipelines and pre-commit hooks to catch credentials before they ever reach a repository. The agency publishes guidance on this. It runs awareness campaigns around it. The “Private-CISA” repository’s commit logs show that GitHub’s own default protections against committing secrets were bypassed — meaning the developer actively worked around safeguards that exist precisely to prevent this. Mandatory secret-scanning in federal development environments, enforced at the pipeline level rather than left to individual developers, would have stopped this before it started.
What probably won’t happen: a full public accounting. Federal agencies have a reliable habit of confirming incidents in the narrowest possible terms, declaring the matter resolved once credentials are rotated, and declining to discuss process failures in any detail. CISA may follow that pattern here. That would be the wrong call for an agency whose entire mandate rests on its credibility as a standards-setter — and whose credibility just took a direct hit from the exact category of mistake it tells everyone else not to make.
