Developer workstations have become the highest-ROI target in software supply chain attacks, and the problem is accelerating.
“There’s one key metric that concerns me: over the past three months we had seven times more vulnerabilities in our supply chain versus the prior three months,” says Gavin Williams, Engineering Manager at AI procurement platform provider Omnea.
“We’re just seeing more problems and issues across registries as time goes on, with more supply chain attacks but also more issues being caught by AI tooling. It’s so easy for developers to install a vulnerable package or something that’s been compromised”.
The industry has spent years shifting security left into the pipeline. But the attack surface itself has shifted even further left than the pipeline and onto the machines themselves.
In the past year alone, attackers have all come through different doors: the recent GitHub breach via a malicious VS Code extension, Trivy via a security tool, TanStack (mini Shai-Hulud) through a package manager, TeamPCP attacks through malicious packages, but they all share one key factor. They’re targeting the developer device. And it's working.
But why?
I like to think of it in this way: most commercial buildings have got their front-door bolted down with locks, cameras, and the likes. But there’s also a staff entrance round the back which has a propped-open fire door because people are coming and going all day with deliveries. That staff entrance leads straight to the office with the keys to every room, which is effectively the developer workstation.
Organizations and their security teams have, up until now, not thought of this as a security risk because “it’s just for them”. It’s a kind of blind belief that no one will bother because it’s not for them.
But if you're an attacker, it literally doesn’t matter who the door (or in this case, device) is for, it makes sense to go where the friction is the lowest.
The gap between what EDR sees and what developers actually install
One of the key reasons for supply chain attacks, according to James Berthoty, founder and analyst at Latio, is that developer endpoints go largely unmonitored, as traditional detection and management tools don't work well for their use cases.
“EDR tools are not granular, they’re primarily focused on the apps or programs that are installed rather than the inner packages of that allowed application,” says Walid Mahmoud, DevSecOps lead in the UK public sector.
EDR monitors at the application level for malicious activity. But organizations aren’t able to see what’s happening inside the tools developers use every day, like the npm packages, the IDE extensions, the Chrome plugins, the Cursor skills.
This is important, because the problem starts before a single line of code is even written.
“It’s not a case of people deploying insecure code to production. It’s a case of even at the install they’re getting GitHub credentials exposed,” says Omnea’s Gavin.
For instance, a malicious package can run a post-install script and exfiltrate credentials the moment a developer installs it.
And of course, it would be amiss to not mention how trivially easy it’s getting to make malware thanks to LLMs. Steeven George, head of product security at Raisin says that this was an area that was creating a “blind spot” for his organization, and he’s not the only one.
Walid, from the UK public sector, explains what the introduction of AI is doing, “A lot of people are living in the terminal now, and they’re installing lots of markdown files and other things. However, naturally without any verified processes, there’s nothing stopping them from downloading things that they’ve seen on Reddit or X. These could be part of a malware campaign to get people to download it. And then - the rest is history.”
Part of the problem is that no single team owns the intersection where developer machines sit, where AppSec, endpoint security, identity, and supply chain risk all come together. And so it’s been easier to use tools like EDR and MDM to fill the void without really protecting organizations from these growing threats. But it’s becoming clear that it’s no longer viable. The downside is being at the receiving end of a significant supply chain attack (That’s quite some downside).
How teams are securing developer machines against supply chain attacks
Chris Holman, DevSecOps engineer team lead at cybersecurity firm Glasswall, has rolled out Aikido Safe Chain across the company’s entire estate.
“Any production pipeline that touches packages which are supported are now scanned with Safe Chain to make sure that we’re not installing anything poisoned."
Walid has done the same across the UK public sector department.
“It’s added a stage gate that we normally have in our software development lifecycle, but that stage gate is local now. So we have a bit more confidence that devs have some sort of guardrail on their local machine that will question them before they install something.”
But packages are only one entry point; Gavin’s team was already using Safe Chain when he said they realized they needed broader visibility across the whole developer device.
“We've been using Safe Chain up until now, but having a more comprehensive way of managing across everyone’s devices and really checking that things are not being installed insecurely is going to be a real game changer,” Gavin said.
That’s what led several of these teams towards Aikido’s Device Protection, which extends the same principle beyond package registries to IDE extensions, browser plugins, and AI tools.
Walid describes it as a “beefed up version of Safe Chain”. He says, “It gives us the telemetry to know what devs are using or what they’ve attempted to install - giving us more context of who is susceptible to an attack”.
Kristina's team at Cognism is planning to deploy it for similar reasons. "No other tools currently have that kind of coverage. EDR tools do not present installed packages on developer machines, and vulnerabilities in Chrome extensions are not covered by other vendors. We will definitely close the gap there."
Steeven has already tested it. "I'm really happy to see the complete overview of browser extensions, Cursor extensions, and all the package registries. It gives us an overall threat model for all of our developer machines.”
Every team we spoke to found the same gap
The pattern across these conversations was consistent, across security and engineering leaders at different companies, in different industries, all independently identifying the same gap. Developer machines sit between the cracks of existing tooling, and attackers have figured that out.
The teams already addressing it started with package-level controls and are now expanding to full device visibility. The ones that haven't started yet are likely running the same EDR and MDM setup that missed every attack mentioned in this piece.
Find out how Device Protection works here or try it out here.
