This post was completed in collaboration with the team at Koi Security.

One of the challenges I often faced as a systems engineer was dealing with developer endpoints. The security controls we had in place often just didn’t apply; whether it was exemptions from VPN policies, or trying to patch third party libraries, no one was ever quite sure what developer risks were or how to mitigate them.

I don’t typically do vendor specific pieces like this around product launches; however, Koi Security is a great example of identifying an overlooked security gap, and building a no-nonsense tool to fix it. Additionally, I wanted to write about some of the approaches to securing developer endpoints in light of the NPM malware attacks this week. In this article we’ll cover the challenges protecting & managing developer endpoints, and how Koi is tackling it.

The Developer Endpoint Gap

In 2024, I met with three founders on the verge of publishing a research project that covered a malicious VSCode extension called “Darcula.” This extension advertised as a dark mode extension (spoofing a known good one), but in reality sent the contents of every opened file to a remote host. To their surprise, this fake IDE plugin took off in popularity, and infected developer machines at some of the largest organizations in the United States.

In response to their surprising success, they published a project called ExtensionTotal (now Koidex), allowing you to check for malicious VSCode extensions.

Koidex is a quick way to query if an extension is malicious. While the success of their fake plugin might be surprising to some, IT teams have been long aware that their developer workstations are basically unprotected targets due to generous exemptions from their existing security tools. Furthermore, there are now many types of spoofing attacks targeting developers, from software supply chain takeovers to browser extensions.

In my Sysadmin life, there was an unbelievably common workflow when it came to onboarding developers: they would quickly ask for an exemption from any and all endpoint security controls. I once even had a developer get clearance on an Mobile Device Management (MDM) exemption before they accepted the role. This back and forth struggle between product leadership and IT leadership was never-ending, from false positive vulnerabilities to broken staging environments.

What is a Developer MDM

I use Mobile Device Management (MDM) as shorthand for a broad suite of tools focused on controlling end user devices, from phones to tablets to laptops and desktops.

Typically, IT teams try to consolidate their device management tooling into an Mobile Device Management (MDM) tool to manage:

1. User onboarding/offboarding

2. Maintaining approved applications

3. Deploying software

4. Handling routine tasks like password resets.

Traditional MDM tools are often part of securing endpoints alongside network and endpoint protection. However, these security functionalities typically break for developers as they either don’t support developer tools, flag a ton of false positives, or break existing applications.

While it can be easy to point and call developers primadonnas, the reality is endpoint security controls weren’t designed to make developers' lives easier. Older endpoint security solutions break several workflows: The VPN would break staging connections, SASE tools would break local host port-forwarding, EDR would break local application tools, vulnerability scanners would lead to nonsensical results as they detected application dependencies, and MDM would hinder productivity as they waited weeks for approval of every new developer tool.

Why Developer MDMs are an Emerging Need

CISOs spend millions on endpoint security controls, just for their most privileged workers to need exemptions. In the business world, developer productivity out ranks every other concern, and typically these machines are given wide exemptions to the normal controls, creating a massive blindspots in organizations. Unfortunately, the developer workstation has become the focal point of many modern attacks.

With open source and extension ecosystems becoming the defacto standards, it’s never been easier to trick developers (or even AI agents) into running malicious actions. While security solutions exist for each of these areas, but deployment and maintenance has been untenable. Open source malware protection requires a specialized wrapper, IDE extension adoption is always low, and MCP gateways are a pain to setup and maintain.

Threat Modelling Developer Endpoints

Just as developer workflows require unusually privileged access to their workstations, they’re also vulnerable to unusual attacks. It’s worth walking through some of these in detail:

1. AI Security Concerns. I’ve been pretty anti-FUD when it comes to AI model usage. After all, what real risk is there in an employee asking ChatGPT for help responding to an email? However, developers are vulnerable due to their specific ecosystems: MCP Servers, Hugging Face Models, and various prompt injection techniques via rules or public channels make them more susceptible than the average user. Security teams have been left scrambling for visibility into developer environments in order to detect if these attacks or vulnerabilities are being exploited.

2. Supply Chain Attacks. As open source repository takeovers grow increasingly common, with the latest series of supply chain attacks like the NX attack leaking many tokens that are still exploitable, this trend isn’t going to stop any time soon. Developer workstations are often the first place these packages are installed to build local versions of their applications, and traditional vulnerability scanning just doesn’t matter here, as patching application vulnerabilities is significantly harder than running an Adobe update.

3. Extension Manipulations. Developers often use specialized, privileged extensions in IDE and browser environments. Malicious IDE extensions continue to be deployed with little protection options available to teams.

Mitigating these risks is why I call Koi a developer MDM - existing device management tools exist for mitigating each of these concerns, but they’re all niche parts of other platforms making them difficult to deploy and maintain. AI security solutions provide visibility into MCP and model misuse, SCA tools sometimes provide a wrapper for safeguarding against malware installs, and secure browsers offer protections for chrome extensions. Koi is unique for bringing all of these tools together in a single place to make protecting developer systems obtainable for the average organization.

Everywhere I’ve seen, this developer endpoint security problem has been recognized, but the juice just is not worth the squeeze to prevent potential exploits. Setting up NPM wrappers, secure browsers, VPNs, and more just didn’t seem worth the risk prevention, especially knowing the developer backlash that would inevitably come. Furthermore, I’m unaware of any solutions that organically do malicious VSCode extension tracking. An example of how widespread this challenge is comes from Figma’s experience rolling out the open source solution Santa to secure their endpoints.

Designed to Give Visibility Where and How it Matters

Koi works by injecting endpoint visibility functionalities via existing agents - from ZScaler to Crowdstrike - to give visibility and control into developer workstations. Using this approach, they’re able to create some very native developer experiences without requiring a new agent deployment. This organically keeps developer workstations safe from malware, without compromising their workflow.

To highlight one specific aspect of the tool that shows the team’s focus, I often bring up how traditional AppSec advice is to patch as quickly as possible; however, the tradeoff here of using unstable packages or ones that have been taken over increases. For example, the XZ-utils attack was only mitigated because most people were not on bleeding edge Linux distros. Similarly, several vendors are now offering pipeline checks for not installing packages updated within a set amount of time.

Security teams have a well defined process for managing these risks in Windows environments, rolling latest patches to a small test group before deploying them system wide. However, these processes haven’t been automated for developer packages, which this example policy from Koi is doing for teams.

Conclusion

These are my favorite types of security tools: ones that come from organic research into vulnerabilities, and building platforms around unknown niches that solve real organizational challenges. As attacks on developer tooling and workstations only increase, it’s exciting to see a solution that promises a holistic solution rather than more isolated features around particular angles. Shout out to the Koi team for trying to build a product that works for developers, not against them.

Thank you for reading Latio Pulse, if you’re a security practitioner, please consider taking this brief survey for our upcoming Cloud Security Report.