Skip to main content
Back to Blog
automationgitguardianaws-govcloudsecrets-scanninggithub-push-protectiondevsecopscisa-data-breachcontractor-security-risk

CISA's GitHub Leak Is the Cautionary Tale Every Engineering Team Should Pin to the Wall

A CISA contractor exposed AWS GovCloud credentials in a public GitHub repo for 6 months. Here's what every engineering team must learn from this secrets leak.

Zyfolks Team ·

The agency tasked with telling American companies how to defend themselves just left the keys to its AWS GovCloud accounts sitting in a public GitHub repo for six months. If you’ve ever argued with a teammate about whether secrets scanning is worth the friction, this is the receipt you’ve been waiting for.

According to KrebsOnSecurity, a contractor working for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository named “Private-CISA” that exposed administrative credentials to three AWS GovCloud accounts, plaintext passwords for dozens of internal CISA systems, and detailed documentation of how CISA builds, tests, and deploys software. The repo was created on November 13, 2025, and only taken down after researchers at GitGuardian and the security consultancy Seralys escalated the issue in May. The contractor was identified as an employee of Nightwing, a government contractor based in Dulles, Va.

How a “Scratchpad” Repo Turned Into a Nation-State Buffet

Guillaume Valadon of GitGuardian — whose company scans public repositories for exposed secrets — told KrebsOnSecurity this was the worst leak he had witnessed in his career. The repo contained a file literally named “importantAWStokens” with administrative credentials to three AWS GovCloud servers, plus an “AWS-Workspace-Firefox-Passwords.csv” listing plaintext usernames and passwords for internal systems including “LZ-DSO,” which Seralys founder Philippe Caturegli identified as the agency’s Landing Zone DevSecOps environment. Even more damning: commit logs show the contractor explicitly disabled GitHub’s default push protection that blocks secrets from being committed in the first place.

This matters because it collapses the comforting fiction that data breaches require sophisticated adversaries. The attack surface here wasn’t a zero-day in a CI/CD pipeline or a clever supply-chain pivot — it was one administrator who toggled off a guardrail and treated GitHub as a Dropbox replacement. If you’re running a team that touches sensitive production infrastructure, this is the failure mode you actually need to plan for: not a hostile insider, but a tired engineer syncing files between a work laptop and a home machine.

Imagine you’re a startup CTO who just onboarded three contractors and gave them GitHub access scoped to your org. If even one of them creates a personal public repo and pastes a .env file into it to “deal with later,” you have a Private-CISA on your hands — and your secret scanner won’t see it because the repo isn’t in your org. The take: organizations that don’t monitor contractor personal accounts via external scanning services are running on the same trust model that just failed CISA.

Why Plaintext Credentials in CSV Files Are Still a 2026 Problem

Caturegli verified that the exposed AWS keys authenticated to three GovCloud accounts at high privilege, and noted the archive included plaintext credentials to CISA’s internal “artifactory” — the repository of code packages used to build agency software. He called it a prime target for lateral movement: “Backdoor in some software packages, and every time they build something new they deploy your backdoor left and right.” Worse, many of the exposed credentials followed a guessable pattern — the platform’s name followed by the current year.

The artifactory exposure is the part that should keep security teams awake. AWS keys can be rotated in minutes. A poisoned build artifact that gets deployed across an agency for months is the kind of supply-chain compromise that takes years to fully unwind — ask anyone who lived through SolarWinds. Modern build pipelines need provenance attestation and signed artifacts, not just access controls on the registry. For teams shipping software that downstream customers depend on, your artifact store is a higher-value target than your production database, and it deserves stricter controls. Engineering organizations building multi-tenant SaaS platforms should treat their internal package registries with mandatory MFA, short-lived tokens, and signed releases — not as a convenience layer.

The take: within 18 months, expect at least one major regulator to require signed software bills of materials for critical infrastructure vendors, because incidents like this make the voluntary approach indefensible.

The Detection Gap Between Disclosure and Revocation

Here’s the detail that quietly undermines CISA’s response statement. The contractor’s GitHub account was taken offline shortly after KrebsOnSecurity and Seralys notified CISA — but Caturegli told Krebs the exposed AWS keys remained valid for another 48 hours. CISA’s public response: “Currently, there is no indication that any sensitive data was compromised as a result of this incident.”

A 48-hour window between disclosure and key revocation is a lifetime when the credentials in question grant administrative access to GovCloud. Any adversary with a half-decent monitoring pipeline on GitGuardian-style scanning services — and several nation-state actors operate exactly such pipelines — would have grabbed those keys long before the public takedown and had time to establish persistence. “No indication of compromise” in this context means “we haven’t finished looking,” not “nothing happened.”

If you’re a platform engineer, the practical question is: how fast can your organization revoke a leaked AWS key today? If the answer involves a Jira ticket, a Slack thread with the cloud team, and an approval from a manager who’s in another timezone, you have the same problem CISA has. The take: automated credential revocation triggered by external scanner webhooks will be table-stakes by 2026, the same way automated certificate renewal became table-stakes after Let’s Encrypt.

What the Workforce Crisis Has to Do With This

Krebs notes CISA is operating with only a fraction of its normal budget and has lost nearly a third of its workforce since the start of the second Trump administration. That context isn’t incidental — it’s the soil this leak grew in. When agencies hemorrhage senior staff through buyouts and early retirements, the people left behind take on more responsibility with less oversight, and security hygiene becomes the first casualty. A contractor using a personal GitHub to sync files between machines is the behavior of someone who has either never been trained out of it or no longer has a senior colleague reviewing their workflow.

The same dynamic plays out across the private sector. Any engineering organization going through layoffs, restructuring, or rapid contractor expansion is carrying the same risk. The take: expect a wave of similar disclosures from companies that thinned their security teams during the 2024–2025 efficiency push.

FAQ

Q: What is AWS GovCloud and why does this leak matter more than a regular AWS exposure? A: AWS GovCloud is a set of isolated AWS regions designed for U.S. government workloads with stricter compliance controls, including FedRAMP High and DoD Impact Level requirements. Administrative credentials there typically grant access to systems handling sensitive but unclassified federal data, which means a leak can have national security implications, not just business ones.

Q: How does GitHub’s push protection actually work, and can it be bypassed? A: GitHub’s push protection scans commits for known secret patterns (AWS keys, API tokens, etc.) and blocks the push before the secret hits the remote. It’s on by default for public repositories on personal accounts, but as the CISA case shows, an individual user can explicitly disable it. Organization owners can enforce it at the org level to prevent that bypass.

Q: What should a security team do if they discover their own credentials in a public repo? A: Treat the credentials as compromised, not just exposed. Rotate them immediately, audit all activity associated with those keys for the entire period they were public, and assume an adversary may have established persistence using the access. Only then do you remove the public repo — deleting first without rotating is the worst possible order of operations.

Key Takeaways

  • Enforce GitHub push protection at the organization level and require it for contractor accounts — individual opt-outs are the failure mode this incident illustrates.
  • Treat your internal artifact registry as higher-value than your production database, because a poisoned build propagates compromise across every downstream deployment. The same logic applies to supply chain and logistics systems where a single tampered artifact can cascade through traceability data for months.
  • Automate credential revocation in response to external secret-scanner alerts; a 48-hour manual rotation window is indefensible for high-privilege cloud keys.
  • Audit contractor and personal GitHub accounts that touch your codebase using third-party scanning, because attackers already do. Regulated industries like healthcare software should make this a compliance-grade control, not a best-effort one.
  • Plan for the human failure mode: an exhausted engineer syncing files between machines, not a sophisticated adversary. Your controls should make the lazy path the secure path.

Have a project in mind?

Tell us what you're building — we reply within 24 hours.