Why Your Employee Workstation Is the New Target for Software Supply Chain Attacks

In the AI-era, software supply chain risk has shifted beyond your CI/CD and production environments and now squarely targets your employee workstations.

Developer laptops, analyst machines, and even AI-enabled endpoints are pulling code straight from the internet at breakneck speed — packages, IDE extensions, MCP tools — often initiated by AI agents you didn’t build.

This shift changes both the blast radius and the focal point for supply chain attacks. Compared to governed build and production systems, semi-trusted employee endpoints are now accumulating thousands of new dependencies and tools. Just one malicious package or IDE extension can steal credentials, take over accounts, and pivot across your environments.

AI-driven Development Has Dramatically Increased Software Supply Chain Exposure

AI-generated code quality from tools like Copilot, GPT, Claude, and Cursor has improved meaningfully over the past year. Anyone building software can feel it. But faster code doesn’t reduce supply chain risk — it increases it.

AI-driven development leans hard on open source dependencies and build tools. Even when the code is correct, the risk sits underneath: the packages the model pulled in, the IDE extensions it relied on, and the MCP servers that supplied context. Those decisions happen fast, locally, and often outside the guardrails you built around CI and production. With everyone using tools like Claude Code, Codex, and Copilot, why attack through well-protected production systems when all an attacker needs is one compromised employee workstation?

OWASP codified this shift by expanding “Vulnerable and Outdated Components” into the broader “Software Supply Chain Failures,” and noted it was the top-ranked concern in their community survey (OWASP Top 10 2025: Software Supply Chain Failures. Hat tip Tanya Janca for catalyzing this change!)

The Shai-Hulud npm package was a wake-up call for many. Safety’s research team was among the first to analyze the campaign and document what mattered: stolen GitHub and npm tokens, pivoting into AWS/GCP environments, malicious GitHub Actions, and worm-like behavior that republished compromised packages to spread further. That’s a workstation compromise leading to a repo compromise, and then to a cloud compromise — without touching production first.

Why EDR and EPP Were Built for the Pre-AI Era

Most organizations have limited visibility into what’s happening on workstations. Even answering basic questions — which packages are being installed, which IDE extensions are running, which AI tools are in use — is surprisingly difficult.

Risk and attacks have moved to these endpoints, but traditional EDR and EPP products still protect the workstation like we did 10 years ago. They detect known malware and suspicious behavior after the fact, but can’t intercept a malicious npm package before install, evaluate an IDE extension before it runs, or protect teams when an AI coding agent pulls hundreds of dependencies to build internal tools.

This now impacts IT leaders because intellectual property and other key data are at risk due to an expanded attack surface driven by coding agents, OSS packages, and build tools. Securing your workstations’ rapidly changing software supply chain is now a first-order problem for CISOs, AppSec teams, and IT leaders — not an edge case.

Securing workstations in the AI-era

Risk has moved to workstations — mitigating it requires four key capabilities that build on one another.

Observability — you can’t manage what you don’t track. For workstations, this includes every OSS package, IDE and its extensions, package managers, AI models and tools, MCP tooling used on the workstation, and anything running inside virtual environments, containers, or virtual machines.

Pre-emptive governance — tracking changes isn’t enough. You must know what’s about to change and be able to intervene before it happens. Enforcement has to live on endpoints, where the context exists, and must happen when a developer tries to install a package, enable a new IDE extension, or when an AI agent decides to pull in dependencies or connect to MCP tools. For AI-driven workflows, this means giving agents access to authoritative, real-time security and health data — turning assistants into enforcers of your policies from the start.

Accurate, real-time data — you need intelligence to make informed decisions; without accurate, real-time intelligence on the asset being pulled in, you can’t reliably protect against malicious attacks or other risks.

Public datasets like NVD are incomplete and delayed. Most vulnerabilities never become CVEs at all, and those that do often appear weeks or months after discovery. Behavioral signals matter. Timing matters. Malicious packages require immediate detection — not retrospective labeling.

Silent, scalable deployment — this is the most underappreciated requirement. Workstation security must deploy at scale without requiring teams to change tools or workflows. Any approach that requires tool or process change fails in practice, especially in large organizations.

You must secure the messy reality of what people are already using, on the machines they already have, without friction or disruption. Because the only security that survives contact with reality is security that deploys cleanly at scale and doesn’t require every team to “buy in” through workflow changes.

Introducing Safety Workstation

Safety became a leader in scanning codebases for open source risk with 2–3x broader vulnerability coverage. Today, we process millions of scans each month for organizations like Wiz, Nokia, AWS, and Fannie Mae.

Safety Workstation is endpoint security for the AI-era, helping you govern and secure employee workstations, prevent malicious attacks, surface risky tool use, and reduce vulnerabilities. It’s agentless and runs only when needed, requiring no tool or process changes.

You get an accurate inventory of what’s actually being used on employee machines and apply governance at the moment it matters — allow, block, or constrain — based on your policies and Safety’s real-time intelligence.

Over the coming weeks, we’ll share what we’ve built, how it works, and why we believe “workstation supply chain security” is going to become a pillar for modern AppSec, IT, and security teams.

If you want early access or you’re already feeling the pain of developer workstation blind spots, reach out — we’d love to partner with a small set of teams shaping this with us.

Footnote: “State of Code” survey statistics are referenced from Sonar’s developer survey coverage.