Three items on the same day’s CISA KEV addition: a code-signed Windows installer, an npm package, and a VS Code extension. All three targeting the same population — developers — through the tools they use every day. This is not a coincidence. It is the adversarial completion of a threat model that the security industry has been building towards for several years but has not yet operationalised as a first-class risk.
The conceptual shift required is simple to state and difficult to execute: developer tooling is production infrastructure. The npm registry is infrastructure. The VS Marketplace is infrastructure. A code signing certificate is production-critical credential material. When any of these components is compromised, the downstream impact is equivalent to a server breach — because a compromised developer environment has the credentials to become a server breach within minutes.
Why the Mental Model Hasn’t Caught Up
The legacy model of software development security focused on the code. Secure coding practices, SAST tools, dependency vulnerability scanning, penetration testing of the application before release. All of these are valuable. None of them address what happens when the tool used to write the code, or the package manager used to install dependencies, or the IDE extension used to structure the project, is itself the attack vector.
The SolarWinds compromise in 2020 was the first major public demonstration that the build process itself was a target — not the application, not the developers’ credentials, but the automated build pipeline that assembled and signed the software. The lesson was absorbed slowly. Five years later, TeamPCP is running a campaign that simultaneously compromises an installer signing chain, a package registry distribution, and an IDE extension store — the build pipeline’s supply chain, distributed across three commercial platforms.
The reason the mental model hasn’t caught up is structural. The teams responsible for developer tooling (DevOps, platform engineering, developer experience) and the teams responsible for security operations (SOC, vulnerability management, identity) often have limited overlap. Developer tooling is “for developers” and security controls are “for IT.” The governance gap between them is where supply-chain attacks live.
What Closing This Gap Actually Requires
The problem is not that organisations lack awareness of supply-chain risk in general. After SolarWinds, MOVEit, and a string of npm and PyPI compromises, the concept is well-established. The problem is that awareness has not translated into operational controls that treat the developer environment as a security boundary to be defended.
Operational closure requires three things that most organisations have not done:
First, inventory. An organisation cannot defend what it cannot see. If you do not know which npm packages your developers have installed globally (not just in projects), which VS Code extensions are running on developer machines, or which developer tools have network access during the development session — you cannot detect a compromise and you cannot set a security baseline to detect deviations from.
Second, classification. Developer workstations that hold production credentials need to be classified and governed as production-equivalent systems. This is a political and organisational change, not a technical one. It requires engineering leadership to accept that developer machines are subject to security governance requirements that may create friction, and security leadership to accept that developer experience constraints are a valid input into that governance design.
Third, toolchain validation. The same mindset applied to third-party vendor risk (SOC 2 assessments, security questionnaires, contractual requirements) needs to be applied to the toolchain components in the development environment. Not every npm package or VS Code extension needs a SOC 2 report, but the high-use, high-access components in the developer environment — package managers, IDE extensions, build tools — need a defined approval process and ongoing monitoring.
None of this is technically complex. It is organisationally difficult because it requires changing how development and security teams understand the boundary between their responsibilities. TeamPCP is betting that the difficulty of that organisational change is durable. This week’s CISA KEV additions suggest the bet is paying off.
Share this article