The CISA GitHub Leak Is a Mess. But It’s Also Very Familiar
What do you get if you cross a US cybersecurity agency with exposed and unprotected passwords, left sitting in a public GitHub repository? Well, you get headline news, of course.
Now, this made people pay attention for a few reasons, partly because it’s embarrassing, and also partly because if an organisation like CISA can make that kind of mistake, it raises uncomfortable questions for everyone else too.
Recent reporting across the last week or so revealed that a contractor linked to the Cybersecurity and Infrastructure Security Agency exposed cloud credentials, access tokens, plaintext passwords, and internal deployment details in a public GitHub repository, with some researchers describing it as “one of the worst credential leaks they’d seen from a government environment”.
The story itself is dramatic enough, and yet, arguably, the bigger issue at play is just how ordinary this kind of thing has become. Now, we’re not going to sit and put one agency on blast for making one mistake - as eyebrow-raising as it may be, but there are lessons to be learned from this. But what is it?
We’ll start with a dive into how it highlights just how modern IT environments quietly accumulate risk over time.
So what actually happened?
According to reporting from KrebsOnSecurity, the exposed repository allegedly contained AWS GovCloud credentials, usernames, passwords, authentication tokens, infrastructure documentation, and deployment-related information. Researchers also claimed that GitHub’s secret-scanning protections had been disabled for the repository.
CISA have said there was no evidence of malicious activity tied to the exposure, and the repository was later removed, but the situation highlights something security teams already know deep down…
Credentials end up in places they shouldn’t be more often than most organisations would like to admit.
This happens more than people think
As we mentioned in a recent blog post, there’s a tendency to imagine cybersecurity incidents as highly targeted, well-planned, and carefully executed, before deploying incredibly technical attacks involving sophisticated malware and elite threat actors.
Sometimes, they absolutely are.
A lot of the time, though, someone leaves something exposed by accident, and that could be anything, such as:
An API key gets committed during testing.
A developer hardcodes credentials temporarily and forgets about them.
An old automation token never gets rotated.
A repository starts private, then becomes public later.
A supplier account keeps broad access long after a project finishes.
Almost none of these things actually happen because people are reckless or malicious. They tend to happen because environments grow quickly, teams move fast, and governance usually struggles to keep pace with reality. It’s the same principles we’ve seen time and time again - and are now seeing it in the form of AI and Shadow AI too.
That same governance issue is especially true in cloud-first businesses where integrations, scripts, automations - alongside a whole host of third-party tooling - all quietly pile up over time.
Does this matter to SMEs?
A lot of UK SMEs regularly hear stories like this and either disengage because it’s viewed as even more negativity, or they might just assume that they’re too small to be hit - I mean, if it’s only government agencies or huge enterprise environments making headlines, you’re safe, right?
Wrong.
So many modern businesses now rely on dozens of cloud platforms, integrations, outsourced services, and automation tools to keep day-to-day operations moving. If you took the time to pause and list out all of the tools, software and platforms you use, how long would that list be? The most up-to-date stat I can find at the time of writing suggests that the average business has 106 SaaS applications in place… Which makes for an awful lot of routes into your business, with credentials everywhere behind the scenes.
That also encompasses everything like:
Microsoft 365.
Cloud backups.
Remote monitoring platforms.
Finance systems.
CRM integrations.
PowerShell scripts someone wrote three years ago and forgot about.
The issue isn’t whether those credentials exist. Of course, they do, and we’re never about to advocate for trimming back on anything that boosts your productivity. But you need to ensure you have that complete visibility over these credentials, and that everything is safely stored (and not left in plain text, CSV files for anyone to read).
Attackers don’t need to “hack” everything
One thing businesses may not yet realise is just how automated credential harvesting has become. Yet, public repositories are constantly scanned for exposed:
AWS keys
Azure credentials
GitHub tokens
API secrets
database connection strings
authentication cookies
Researchers have repeatedly shown that leaked credentials can be discovered within minutes of exposure, and attackers don’t necessarily care who the victim is, either.
If credentials work and provide access, they have value.
It’s really that simple.
The real risk? Operational drift
Now, I don’t believe there’s a single organisation out there that suddenly wakes up one morning and all of a sudden has terrible security practices.
Instead, what usually happens - from our experience and conversations with people who need help - is something much slower, and things that snowball over time.
It could just be that there’s a bunch of permissions that get added but never removed, or suppliers (or even your payroll provider) keep access longer than they need it.
The same goes for old integrations stay connected because nobody wants to break anything, admin accounts that quietly multiply for ease of access, or documentation that you forget to keep on top of until it ultimately falls out of date.
Eventually, you end up with an environment where nobody’s completely sure:
which credentials are active
who owns them
what systems depend on them
whether they’re still being monitored properly
And that twilight zone is exactly how - and where - exposure risk starts to creep in. It doesn’t come through as one catastrophic decision, but rather via years of small compromises and assumptions.
So what should businesses actually do?
You don’t need to treat every cybersecurity headline like a ‘Code Red: drop everything!’ type of emergency. In reality, breaches and hacks happen daily, and if you got worked up about every single one, you’d never sleep soundly ever.
Still, stories like this are useful reminders to check whether the basics are still being handled properly.
For most SMEs and mid-market organisations, a sensible starting point looks something like this.
Review privileged access properly:
Look at:
admin accounts
API keys
automation credentials
supplier access
cloud permissions
Then ask whether those permissions still make sense. A surprising amount of unnecessary risk comes from old accounts and forgotten integrations nobody’s reviewed in years.
Enforce MFA everywhere it matters:
Most businesses have MFA enabled somewhere, and if you’re Cyber Essentials certified, it’s now mandated.
If you’re one of those who don’t enforce it consistently across high-risk systems, now is the time to do so.
Developer tooling, cloud platforms, remote access, repositories, and admin accounts should all be covered properly.
Scan for exposed secrets:
Repository scanning and credential monitoring should really be standard practice now, especially for businesses using internal development, automation, or infrastructure-as-code tooling.
The earlier you spot exposed credentials, the smaller the problem usually stays.
Review supplier access:
The CISA incident reportedly involved contractor-managed infrastructure. That’s worth paying attention to because supplier access is often one of the least visible parts of an IT estate.
Third parties shouldn’t sit outside security governance.
If someone has access into your environment, they’re part of your security posture, whether you like it or not.
This is ultimately a visibility problem
Modern businesses run on interconnected systems and inherited trust, and that’s just reality now - especially since the pandemic and working from anywhere became a thing.
But still, we find a lot of organisations still don’t have clear answers to fairly basic questions:
Who has access to what?
Which credentials are still active?
Which integrations are business critical?
How quickly would suspicious behaviour actually get spotted?
If those answers take too long to find, there’s a good chance risk has built quietly in the background.
Final thought
There’s obvious irony in a cybersecurity agency suffering a public credential exposure incident. But honestly, the more useful takeaway is that these mistakes aren’t rare anymore.
They’re normal enough that most businesses should assume some level of credential exposure risk already exists somewhere in their environment.
The goal isn’t perfection. It just doesn’t exist.
It’s reducing blind spots before someone else does.