The Agency Protecting America's Infrastructure Just Leaked the Keys to It on GitHub

You know that feeling when you're trying to hide something, so you label the folder "Definitely Not Secrets" — and then accidentally leave it on the kitchen counter?

That's what just happened with the Cybersecurity and Infrastructure Security Agency. CISA. The federal agency literally responsible for protecting America's critical infrastructure from cyberattacks.

A contractor working for CISA maintained a public GitHub repository — visible to anyone with an internet connection — that contained live credentials for AWS GovCloud. That's the Amazon cloud environment reserved for U.S. government workloads. Sensitive stuff. Law enforcement data. Federal operations.

The repository was named "Private-CISA."

It was public. It had been public since November 2025. And it sat there, exposed, until someone outside the agency noticed it last weekend and reported it.

Here's the part that should make your blood pressure spike: this wasn't a hack. Nobody broke in. There was no zero-day exploit or ransomware gang. The people in charge of securing the country's infrastructure just... left the door open.

When developers write code, they often need to connect their application to other systems — databases, cloud storage, APIs. To do that, they use credentials. Passwords. API keys. Tokens. Digital keys that unlock access.

The proper way to handle this: store those credentials in a secure vault that only the application can access at runtime. Never put them directly in your code.

What keeps happening instead: developers hardcode the credentials right into the source code, commit it to a repository like GitHub, and forget it's there. Or they assume the repository is private. Or they think nobody will notice.

GitHub has more than 100 million developers. Automated bots scan public repositories 24/7 looking for exactly this: exposed credentials they can use or sell. The moment you publish a repository with a live password in it, that password is compromised. Not in a week. Not tomorrow. Now.

CISA's leak included AWS access keys and secret keys. With those, an attacker could spin up servers, access stored data, pivot into connected systems, or run up a six-figure cloud bill just for fun.

This is the same agency that publishes alerts telling everyone else to secure their credentials.

This isn't isolated. It's epidemic.

In the same week, GitHub itself confirmed a breach of its own internal repositories — caused by a malicious VS Code extension installed on an employee's device. The extension, a developer tool called Nx Console, was compromised. It stole GitHub session tokens and used them to clone private repos.

Also in the same week: researchers found that popular GitHub Actions — the automated workflows developers use to build and deploy software — had been hijacked. Attackers modified widely used workflow tags to redirect to malicious code. Those workflows ran with full access to CI/CD pipelines, which means they had credentials for production systems.

You're seeing the same failure three times in seven days:

- CISA leaked credentials by publishing them in a public repo

- GitHub lost credentials because an employee installed a compromised tool

- Thousands of developers leaked credentials because they trusted a workflow tag that got silently redirected

The tools built to make development faster are also making credential leaks faster. And the people responsible for stopping this — government agencies, security companies, the platforms themselves — are failing at the same rate as everyone else.

You can't fix CISA's GitHub hygiene. But you can fix your own exposure to this same pattern.

1. Search for yourself on Have I Been Pwned (haveibeenpwned.com). Enter your email. If your credentials were exposed in a breach, you'll know. Change those passwords today.

2. Revoke app and extension permissions you don't recognize. Go to your Google account settings (myaccount.google.com/permissions) and your Microsoft account (account.microsoft.com/privacy). Look at every app and extension that has access. If you don't remember authorizing it or don't use it anymore, revoke it.

3. Enable MFA everywhere that offers it — but understand it's not magic. Multi-factor authentication helps. But as we've seen with OAuth consent phishing, attackers are now bypassing MFA by tricking you into granting app permissions directly. MFA stops password theft. It doesn't stop you from clicking "Allow" on a malicious app.

4. If you're a developer or work with developers: stop committing secrets to repos. Use environment variables. Use a secrets manager. Use GitHub's secret scanning and push protection features (they're free). If you've already committed a secret, rotating the password isn't enough — it's in your Git history forever. You need to purge it or assume it's compromised.

5. If your company uses GitHub Actions or any CI/CD automation: pin workflow versions to specific commit hashes, not tags. Tags can be redirected. Commit hashes can't. This is technical, but if you work somewhere with a DevOps team, forward this and ask if they're doing it. Most aren't.

The CISA leak isn't surprising. The pattern is almost universal.

In every environment I've assessed, I've found credentials committed to repos that were never rotated — not because the team didn't know better, but because nobody could answer the question "what breaks if we rotate it?" The safe choice was always to leave it alone and note it in the audit finding.

That's the real failure. Not developer hygiene. It's that exposed credentials become load-bearing over time. Systems depend on them. Nobody documented it. The rotation cost compounds into a risk nobody wants to own.

CISA published an alert about this exact pattern four months before their own repo went public. The alert was correct. The process to act on it internally didn't exist.

The tools that prevent this — secret scanning, push protection, vault-based injection at runtime — are free. The missing ingredient is usually accountability: someone whose job it is to close the loop between the finding and the fix.

If that person doesn't exist on your team, the credential stays in the repo.

Have you ever worked somewhere — or do you work somewhere now — where you knew credentials were being stored in ways that would horrify a security professional? What was it, and why do you think it still happens?

Identity Decoded publishes every week at identity-decoded.com