This is the second part of a series touching on issues related to supply chain security.

In the first part of this series “Supply Chain Security for Developers” I talked about the trust we place in the countless dependencies and tools that make up our software development environments. I explored how this web of trust extends not just to the obvious parts‚ like our operating system‚ but also to editors, libraries, and even the maintainers behind them.

It’s clear that this level of implicit trust can be problematic, so I laid out my goal to reduce both my reliance on, and the capabilities of, the tools I use on a daily basis. The result was a spectrum of trust, where different tools should be treated differently depending on their role and your level of comfort.

Now, I’d like to take this discussion further and share some of the methods I have explored so far.

The Operating System

At the most basic level, I looked at my operating system. I have almost complete trust in my OS, so this required the least amount of change. In the past I enjoyed trying the cutting edge of software with distributions such as Fedora – but I eventually took a step back and moved to an OS with a slower release cycle.

There have been a number of ‘incidents’ where supply chain attacks have been detected surprisingly quickly. Probably the most notable is the XZ backdoor that was quickly mitigated due to a performance degradation and one very attentive developer.

Because these attacks or vulnerabilities are often discovered quickly, I find that simply waiting before you update your software is a surprisingly effective strategy. Of all the changes, this was the least intrusive one and even today I would have no trouble sleeping if I still used Fedora. But every small step counts.

High-Risk Experiments

Next I looked at things I don’t really trust, such as the AI editors I mentioned earlier, or some interesting projects I found on Codeberg or GitHub. When I want to sample things like this, I just start up a new Virtual Machine (VM). It is easy and it provides a healthy degree of isolation from your machine.

But it also introduces a lot of friction which might be fine for experiments but working with that every day is just too much hassle for me. VMs are also a bit more demanding on compute resources, and running several at once can be problematic.

Development

For actual development, most people will steer clear of using a cumbersome setup in the long term. I think a more streamlined method is needed and development containers (or devcontainers), promise to be such a solution. Based on containers they are designed to be seamlessly integrated with editors.

There are some downsides to devcontainers though: only a few editors currently support devcontainers; devcontainers are too closely tied to the VS Code ecosystem;I also believe devcontainers add more layers of abstraction and dependencies, which goes against my goal of reducing how much I need to trust my tools. So, I kept looking for alternatives.

There are other tools, like Distrobox and Toolbox (`toolbx`), that also use containers. With Distrobox, however, the goal is not to sandbox but to integrate containers closely with your host system‚ for example by giving them access to your home directory. On top of that, these tools add yet another layer of abstraction. That helps them support many different use cases, but my use case does not need all the bells and whistles. So I started to experiment directly with Podman containers, and I’m very happy with the results so far.

Plain containers are based on well-supported standards from the Open Container Initiative (OCI), and there is plenty of documentation available. Security is not the primary focus of containers, yet I believe they can help address the security concerns I mentioned earlier.

With a little setup, containers allow fine-grained control over what resources (such as directories, networks, or device access) are available to the processes within it. Building a new container is a little bit of work, but once you have done it once, doing it again becomes much easier. Running a container is easy, but having a small wrapper script that takes care of some housekeeping can improve the workflow significantly.

I have written such a small wrapper tool that makes handling permissions (like network access, shared directories, or sharing of the GUI system) effortless. After a few months of daily use I’m still very pleased with my container setup. Of course I had to learn a lot of new things (never a bad thing!) and it took me some time. In the end though, it allowed me to find a good tradeoff between day-to-day ergonomics and peace of mind, and sometimes that is the cost of sovereignty.

Are you also concerned about the current state of supply chain security? How much time and effort have you invested to feel comfortable with your level of security? Share your insights, experiences, and ideas. I’m convinced that we need to work together to make our tech ecosystems safer for everyone.

Get in touch and let me know!