It’s a done deal. In terms of market share, mindshare and innovation, open source developer tools have won the battle for the hearts and tool belts of engineers everywhere. From IDEs to build tools to package managers, open source has become the backbone of modern software development environments. 

While this is a clear triumph for open source, we must also acknowledge the elephant in the room — the potential for massive supply chain risks. Developer tools are the ultimate supply chain attack vector. Any successful attacks would be exposing not just a productivity tool that holds sensitive data, but one that is used to write and build software. This means attackers can compromise not only an organization’s technology environment, but also the code its developers write and commit. Developer tools are granted privileged status in almost every organization. 

None of this is to say that open source tools are inherently less secure than proprietary tools. On the contrary. But the likely impact of this dominant market position is a lot more malicious attention from very smart yet bad folks — including the most sophisticated advanced persistent threat groups (APTs) on the planet and hacking crews sponsored by nation-states. To deal with this reality, the maintainers of open source developer tools will need to work doubly hard to ensure that they maintain software supply security. 

The rise of open source

The evidence that open source developer tools have won is widespread. According to recent research, which surveyed over 400 application developers, security engineers and DevOps practitioners, over 60% of respondents said their organizations have a developer tool stack comprising 50% or greater open source tools. Across the broad landscape of developer tools, open source is everywhere. GitHub and GitLab, the two dominant source code repositories and version control platforms, are both built on the core Git project. VS Code, which is built on an open source core, is by far the dominant integrated development environment (IDE). 

The StackOverflow 2023 Developer Survey of over 80,000 developers found that more than 70% of developers use VS Code. Many of the other commonly used IDEs are open source. In build tools, a significant portion are open source projects. And, of course, Docker and Kubernetes, the dominant application container and the dominant container orchestration platform, respectively, are both open source.

The supply chain risk

Unfortunately, ubiquity loves unsavory company. While open source tools offer numerous benefits, including greater transparency to identify bugs and monitor code activity, they also can magnify software supply chain risks. VS Code, for example, is built on the Electron framework and Chromium browser core. It uses TypeScript, a strongly typed version of JavaScript that improves security. That said, VS Code has hundreds and hundreds of direct and transitive dependencies, which might open it up to attack. 

Other open source dev tools have different weak points. Git is written in C, a language that is notoriously challenging to secure and is most definitely not secure by default. The core group of Git maintainers are gifted engineers, including some security wizards. That said, attackers seeking to compromise Git can easily surmise potential weaknesses based on how C works. Because most popular open source developer tools are backed by significant organizations and companies, the bar for hacking them is high. But when it happens, the potential for disruption and chaos is massive. 

Mitigating the risks: Know what’s running, zero trust 

Mitigating the risks to open source tools is more about infrastructure security than code security. The first step is to know what is running inside your organization. Centralizing on a single IDE and a small set of common tools can simplify this challenge. Other approaches include using a common desktop package manager or cloud IDEs to enable DevEx teams to validate exactly what version of what tool is run by each developer and team. 

Another essential step is to make sure you are monitoring activity emanating from developer, build, and CI/CD tooling. These tend to be “softer” targets in the traditional security approach because they are so far inside the perimeter. When they are in the cloud, of course, then an organization will likely secure them more aggressively using secrets and MFA. In either case, adopting a Zero Trust posture by applying least-privilege management and continuous authorization on all developer-facing tooling can compartmentalize risk and reduce the blast radius of any incidents.  

A third pillar of risk mitigation is automated patching and update management for development tools. Developers often resist these practices because they can, in the near term, disrupt workflows with a river of alerts touting irrelevant vulnerabilities and requesting upgrades of dependencies that could actually break the application. With prim and proper tuning, and by using the right scanning and dependency management systems, DevOps and Platform teams can tune these variables to moderate noise and maximize signal.

With great market share comes even greater responsibility

The dominance of open source developer tools is a testament to their value in the software development landscape. However, with this dominance comes a responsibility to manage the associated supply chain risks. By acknowledging these risks and taking proactive steps to mitigate them, we can continue to harness the power of open source while ensuring the security of our software supply chains. This represents yet another distinct attack surface likely to receive attention from bad actors. It also represents an opportunity to lock down the most critical tools in the organization — the ones that forge the code that, in turn, runs the world.