Six Months. 844 Megabytes. Three GovCloud Accounts. The CISA Leak Is The Class We Just Closed In Our Own Stack This Week.

The disclosure landed this week. A contractor working for CISA — the agency responsible for cybersecurity guidance across the federal civilian network — kept a public GitHub repository named "Private-CISA" with 844 megabytes of credentials, internal blueprints, and signed certificates from November 13, 2025 through May 15, 2026. Six months in the open. GitGuardian's automated scanner caught it on May 14, 2026. Krebs and Seralys notified CISA the next day. The repository came offline approximately twenty-six hours after notification. The exposed AWS access keys remained valid for an additional forty-eight hours after takedown.

This post does two things. It catalogs what was actually in the repository, because the public coverage so far has under-stated the depth of the exposure. And it lays the leak side-by-side with the exact infrastructure class DugganUSA closed in its own production stack twenty-four hours before the disclosure dropped. The contrast is the point.

What was actually in the repository

The reported contents, sourced from the Krebs writeup and the GitGuardian disclosure:

A file named "importantAWStokens" containing high-privilege AWS access keys for three separate AWS GovCloud accounts. GovCloud is the federally-cleared isolated region of AWS used by federal agencies for workloads that touch federal data. The keys carried administrative privilege levels on all three accounts.

A file named "AWS-Workspace-Firefox-Passwords.csv" — plaintext passwords exported from the contractor's Firefox profile, for dozens of internal CISA-adjacent systems. Plaintext. CSV. Public repository for six months.

Entra ID SAML certificates. The certificates that prove identity for federated single-sign-on into Microsoft tenant services. The exposed certificates would allow an attacker to forge SAML assertions and impersonate the identity provider to any service trusting that federation.

Artifactory credentials connected to CISA's internal software package repository. This is the most operationally dangerous artifact in the dump. Artifactory is the build-system package store. An attacker with Artifactory access has the ability to substitute malicious package versions that downstream CISA systems will pull and install. The supply chain risk is direct and is what every external security expert quoted in the coverage flagged first.

Landing Zone DevSecOps environment credentials. The LZ-DSO is CISA's secure-development environment for cloud workloads — the place where code gets reviewed and signed before deployment.

CI/CD build logs and deployment workflow documentation. Terraform configuration bundles. Kubernetes manifests and ArgoCD application files. GitHub Actions workflows. Service account credentials. Personal and professional GitHub tokens.

Internal documentation backups, including OneNote and .docx exports describing how the agency builds and deploys software. The architecture diagram a defender would normally only obtain through a months-long penetration test was sitting in a public repository labeled "Private-CISA."

How it happened

The contractor was an employee of Nightwing, a government services firm headquartered in Dulles, Virginia. The employee's GitHub account had existed since September 2018. The "Private-CISA" repository was created on November 13, 2025. Quoting from the Krebs reporting on what the contractor did:

The contractor disabled GitHub's default secret detection feature on the repository. GitHub publishes a free secret-scanning feature that catches AWS keys, GitHub tokens, and many other secret formats at commit time. It is on by default. It was turned off on this repository.

The contractor used passwords reported as easily-guessed — described in the coverage as platform-name-plus-current-year shapes.

The contractor used the repository as a synchronization mechanism between a work computer and a home computer. The repository was, functionally, the contractor's dotfile-sync. The contractor stored everything in it because the contractor wanted it on both machines.

That is the entire mechanism. There is no exotic supply-chain attack, no zero-day, no nation-state intrusion. The mechanism is a tired developer using a public git repository as a sync drive because dotfile-sync is convenient and the EDR does not flag it.

Why the forty-eight hour post-takedown window matters

After GitGuardian notified CISA on May 15 and the repository came offline, the AWS access keys in the exposed file remained valid for forty-eight additional hours. Anyone who had scraped the repository during its six-month public window had two more days to use the keys against the three GovCloud accounts after the leak was identified. CISA's spokesperson stated "there is no indication that any sensitive data was compromised." The honest reading of that statement is "we have no evidence yet." Six months of unmonitored exposure plus forty-eight hours of post-takedown validity does not yield positive proof of non-use. It yields the absence of a forensic trail capable of proving use either way.

The same forty-eight hour window is the symptom of a specific configuration class: credentials stored in a system that does not rotate automatically on revocation. Someone in CISA's incident response had to manually go to each AWS GovCloud console, find the keys, and disable them. Manual rotation in an incident is slow. Manual rotation in three accounts is slower. Manual rotation across three accounts plus Artifactory plus LZ-DSO plus SAML cert revocation across an Entra ID tenant is a multi-team multi-day operation. That is what the forty-eight hour gap actually measures.

The class is the literal-secret-with-no-vault-rotation class

Every credential type in the leak shares one property: it was stored in a place where the act of changing the source-of-truth value did not propagate automatically to the systems that used it. AWS keys in a CSV in a repository do not rotate when AWS keys rotate. SAML certs in a file backup do not refresh when the IDP refreshes them. Passwords in a Firefox export do not invalidate when the actual passwords change. The leak is not about the contractor's bad habits. The leak is about an architecture that allows credential copies to drift away from a rotatable source-of-truth at all.

This class of failure is the single most common and most preventable shape of credential exposure in any large organization. The fix is structural, not procedural. The fix is to migrate every credential reference from a literal copy to a Key-Vault-ref or equivalent binding so that the credential value resolves at runtime against a single source-of-truth that the security team controls. Rotate the source. Every consumer picks up the new value within its cache TTL. There is no second copy. There is no plaintext CSV. There is no "Private-CISA" repository because there is no value to put in a repository.

What DugganUSA did about this in its own stack this week

We hit the same class of failure ourselves on Monday. A Meilisearch master key was rotated in our Azure Key Vault, but the analytics container's meili-key reference was a literal value — a snapshot taken at the time the secret was originally set, with no Key Vault reference. The rotation did not propagate. The analytics container kept booting with the stale key, every dependent endpoint failed with "invalid API key," and we spent thirty minutes diagnosing what should have been an automatic propagation. The structural fix was obvious in retrospect: migrate every container-app secret from literal value to keyvaultref binding so that future Key Vault rotations propagate without manual intervention.

We wrote up the lesson as an internal feedback memory. We audited our container apps. The DugganUSA production estate is two container apps in a single resource group — analytics (the BRAIN) and security (the DRONE). Both already have managed identity enabled. The Key Vault binding migration is two apps, not sixty. The remediation is a single afternoon's work, gated behind change-control and verified with a rotation drill afterward.

The CISA leak is the federal-scale version of the same failure, multiplied across hundreds of contractor accounts and an estate that nobody has ever fully audited. The exact same structural fix applies. The exact same migration pattern works. The fact that the agency tasked with telling everyone else how to manage credentials had a contractor running a literal-secret git-sync for six months tells you what the install base looks like at every federal contractor below the news cycle.

What defenders should do this week

The clear move is to audit every secret in every system you operate for the literal-versus-vault-reference distinction. Anywhere a credential value is pasted as a literal — into a container app, into a Kubernetes manifest, into a Terraform variable, into a CI/CD pipeline configuration — that credential is one rotation event away from a "Private-CISA" outcome. Replace the literal with a vault binding. The pattern is one CLI command per credential per consumer. Most cloud providers expose it natively. The platform engineering team will know what to do.

The secondary move is to verify that your secret store actually issues credential revocation events that downstream consumers can subscribe to. A vault that holds the source-of-truth is necessary but not sufficient. If a downstream consumer caches a credential for a week, the consumer is operating with a copy that has the same drift problem as a literal. The rotation drill — actually rotate a test secret and verify that all consumers pick up the new value within a documented TTL — is the receipt that the binding is doing what it claims.

The tertiary move, which the CISA leak makes visible: monitor your own repositories for credential exposure. GitHub publishes secret scanning. GitGuardian publishes secret scanning. Both work. The contractor in this incident actively disabled the GitHub feature. The default-on posture is the correct posture. If your developers can disable secret scanning on internal repositories, you have the same vulnerability surface CISA had on May 14, 2026.

What this is and is not

This is not a CISA-bashing post. CISA does necessary work. The agency that produced the Cybersecurity Performance Goals, that runs the Known Exploited Vulnerabilities catalog, that ships the StopRansomware guidance, that publishes joint advisories with allied agencies on Chinese and Russian state actors, that operates the SLTT outreach program — that agency just experienced a credential exposure that happened because a single contractor used the wrong sync tool. The institutional work continues. The exposure does not invalidate it. The exposure also does not get a pass because the institutional work is good.

This is a methodology post. The literal-secret-with-no-vault-binding class is the most common, most preventable, and most under-discussed credential exposure shape in the install base. The CISA leak is the public proof of how bad the class can get when nobody catches it for six months. The DugganUSA position is that we ran into the same class in our own stack four days ago, learned from it, and are migrating away from it this week. The audit pattern, the binding pattern, and the rotation drill pattern are all documented. The class is closable. The work is operational, not theoretical.

That is the receipt. That is the work. That is the week.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com