The software supply chain has had a brutal run.
In the past few months, we’ve seen attacks against Axios, Trivy, LiteLLM, SAP, Vercel, and a new Mini Shai-Hulud campaign that has impacted a long list of packages that includes TanStack, UiPath, and Mistral AI.
Then GitHub confirmed that attackers had accessed nearly 3,800 internal repositories after a poisoned VS Code extension landed on a single employee’s laptop.
The extension was Nx Console, a legitimate tool with 2.2 million installs and a verified publisher badge, compromised using a stolen token from a separate supply chain attack.
The malicious version was live on the marketplace for just eighteen minutes, but auto-update had already pushed it to running editors during that window.
Co-founder and CEO of Aikido Security.
These attacks came through different doors.
A browser extension, a worm in the package registry, a poisoned IDE plugin. But they all landed on the same thing: a developer’s machine. GitHub is not a careless company.
If this can happen to the platform that hosts most of the world’s source code, it can happen to anyone.
Developers Are Now the Primary Target
Developers have become one of the most valuable targets in the software supply chain because they hold cloud credentials, SSH keys, npm publish tokens, Kubernetes configs, and direct access to source code. A single compromised credential can be enough to publish malicious packages or trigger downstream compromises across thousands of organizations.
The rise of AI-driven development is also contributing to the challenge in two ways. First, coding agents working on developers’ laptops are pulling packages and adding skills with little to no human oversight over what gets installed, which, of course, further increases the attack surface on the developer device.
Second, it has dramatically lowered the barrier to entry to carry out supply chain attacks because what used to require real skill and deep technical knowledge now only requires an LLM subscription. More skilled attackers are also using AI to conduct increasingly sophisticated attacks that scale faster than security teams can respond.
For years, supply chain security meant securing the infrastructure that code passes through, like registries and build pipelines and CI/CD systems. Those layers still matter, but the vulnerability now starts earlier, on the developer’s device, before code ever enters shared infrastructure.
Traditional Endpoint Protection Is Inadequate
Despite the sensitive content on developer machines and the growing risks they face, most enterprises still secure them the same way they secure any standard corporate employee laptop: including traditional endpoint protection (EDR) for detecting threats on the operating system and mobile device management (MDM) for managing what gets installed.
The problem is that most of what developers do day-to-day happens above the OS, through package managers, IDE marketplaces, browser extensions, and AI tools. These are mostly invisible to EDR and MDM. A malicious npm package running a post-install script doesn’t register.
A compromised VS Code extension quietly exfiltrating credentials doesn’t register. An AI browser plugin with over-permissioned OAuth access doesn’t register. These tools weren’t designed for how software development works today.
Companies Are Stuck Choosing Between Bad Options
As a result, most companies find themselves trying to defend the developer endpoint with approaches they’d prefer not to have to use.
Some block everything, drawing a hard line between developers and the open internet. This can work in highly regulated environments like financial services, but it kills development speed everywhere else. This approach is so restrictive that developers in these environments often find workarounds like second laptops and disabled VPNs, which makes the security posture worse than if you’d done nothing.
Many companies go the other direction and allow developers to install everything they need and hope nothing goes wrong. Given the issues I just listed, this approach is extremely risky (and pretty much indefensible).
Others try a third path, manually approving install requests on a case-by-case basis. While this precision is effective from a safety and developer needs standpoint, it’s impossible to scale.
The Industry Is Solving the Wrong Problem
Most of the supply chain security conversation right now is about detection. How fast can you identify a malicious package? How quickly can you flag a compromised extension? These are reasonable questions, but they miss something important.
Look at the GitHub breach. The malicious Nx Console extension was identified and pulled within eighteen minutes. That’s genuinely fast. But it didn’t matter, because auto-update had already distributed the compromised version to running editors during that window. Detection told you something bad existed. It didn’t stop it from landing on developer machines.
The more useful question is: how do you stop something from reaching the device in the first place? A cooldown period, a delay between when a new version is published and when it’s allowed to install, would have prevented the GitHub breach entirely.
If your policy says “don’t auto-install anything published less than 48 hours ago,” the malicious Nx Console version never reaches a single device. That’s a basic timing rule that buys the ecosystem the window it needs to catch problems before they land.
The same thinking applies more broadly. Know what’s installed across every developer machine. Set policies around which packages, extensions, and plugins are allowed. When a developer needs something outside the policy, give them a way to request it that’s fast enough they don’t route around it.
None of this means making developer environments sterile. Modern software development depends on open source, third-party tools, and increasingly on AI agents. Developers need freedom to work. But that freedom should be visible and governed, not invisible.
The First Domino
The developer device is the first domino in the software supply chain. Every major breach I’ve described in this piece started there. Not in a pipeline or in production.
The fixes aren’t complicated. The cost of ignoring them is. The industry has spent years shifting security left into the pipeline. It’s time to shift it all the way to the device.
We’ve reviewed and ranked the best business monitors.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit
https://cdn.mos.cms.futurecdn.net/7DtE9RCVmUtmH2FAfvxsvM-2560-80.jpg
Source link
