Supply Chain Security for Developers
Have you ever stopped to ask yourself why is it normal that your applications have unrestricted to your home directory? I hadn’t until recently. The more I thought about it, the more I became uneasy.
In this post I want to explore the trust we have in our software development tools, why that trust can be a risk, and the steps I took to feel better about my own setup.
This discussion fits into the broader topic of supply chain security, a subject that has received increasing attention lately not least due to some high-profile incidents (for example).
At its core, supply chain security is about the risks introduced by everything that goes into building a product. In software development, that includes tools, libraries, frameworks, and services. I’ll refer to these things collectively as dependencies because we rely on them not just to help us work, but also to not cause harm. And the story doesn’t end there.
The issue is not limited to our direct dependencies. It also includes transient ones: the dependencies of our dependencies. Something we had previously vetted and deemed to be safe can later go onto to become a security problem.
In practice, these problems can happen for a variety of reasons: a maintainer’s account gets hacked; a maintainer turns malicious; projects become unmaintained; name squatting; or a change of ownership that goes unnoticed.
If you look closely at modern development workflows, you’ll notice how deeply they’re rooted in trust: We trust our tools, we trust our dependencies and their dependencies and, above all, we trust the maintainers of all of these projects. I think we often trust just because that’s how we always did it. And to be clear, some level of trust is unavoidable.
We tend to trust well-known Linux distributions and their maintainers. By extension, we also trust the software that we install through their package managers.
We trust our browsers and our editors. Or do we?
In recent months and years, many tools – and especially editors – have gone all-in on AI features. Some are genuinely useful. But the idea that there is a code that sends my editor contents straight to Big Corp’s servers makes me uneasy.
You can hide the AI stuff from the UI. But that doesn’t change the fact the editor can do it.
Thinking about this led me into a deeper re-examination of the “trust contract” behind my development environment.
I started to look at the dependencies I work with every day and asked myself, how can I reduce the amount of trust they require. Some of these we trust almost completely (such as the OS) while others we trust mostly (editors), and some we probably shouldn’t trust much at all (a cool new tool we found online).
Different tools serve different purposes, and that means they warrant different levels of trust. There’s no one-size-fits-all solution here. For every dependency, there’s a sweet spot somewhere between “just run it with sudo” and “only use it on an air-gapped OpenBSD machine” that balances practicality and security.
First, we have to think about what we actually intend to achieve. For me, this boils down mostly to reducing the number of dependencies that I rely on – and restricting the rest.
Next is the question of threat models. The main attack vectors that I consider are dependencies that go rogue and try to exfiltrate sensitive data, or tools from companies such as Microsoft, Google that are overly dependent on telemetry.
These are not the most sophisticated attacks and compared to securing an internet server this problem is a little bit more relaxed.
Everything I considered here is doable on the developer’s machine.
Elaborate firewall and network setups or air-gapping an entire organization is out of scope of this post. While this is not watertight security, I think it already goes a long way.
This is the first part of a two-part series. In the next post I’ll talk about the techniques I explored to mitigate supply chain attacks in software development.
In the meantime, if you have any thoughts on Supply Chain Security get in touch, we’d love to hear from you.