Stay Safe(r) with Dev Containers
Quick Points
- Supply chain attacks are increasing and everyone is at risk
- Dev Containers can lessen your attack surface
- Combined with other principles, they can keep you much safer
- Tutorial writers and teachers need to do their best to help keep beginners safe
Outline
- Supply Chain Attacks are Increasing
- How Can Dev Containers Help
- Other Principles to Follow
- Conclusion and A Word to Teachers and How-To Authors
Supply Chain Attacks are Increasing
The last few weeks have shown that there is a cost to the rapid development and evolution of software that AI is enabling. On 2026-03-24 LiteLLM had its package compromised with a vibe-coded virus that quietly harvested affected computers’ keys, environment files, etc., and sent them off to a Vercel endpoint for the attackers to use at their leisure. It did this while also compromising Kubernetes clusters by installing back doors. Yesterday, the hugely popular Axios NPM package had a compromised version uploaded that did something similar but also installed a RAT (Remote Access Trojan) onto Windows machines.
It should go without saying that those responsible for these attacks and the damage they cause are at fault. However, humans have been stealing from each other for thousands of years and that won’t stop. So, it falls to us to build our cyber walls and software as strong as we can. Hopefully this article can help with that.
How Can Dev Containers Help
So how can we keep ourselves safe? One option is to mitigate what your projects know about one another. Containers themselves do this wonderfully. Combine them with Dev Containers and you not only limit what is on your machine, but secrets and .env files for your various projects are completely isolated. So if one project gets compromised, whether it’s a database password, a cloud provider access key, or something else, you only need to rotate the ones that belong to that project.
Where they get really powerful is the ability to control how they are built not only with Dockerfiles, but also with Docker Compose files. You can run multiple containers simulating your environment, targeting particular build layers, all while keeping your main computer and its secrets safe.
While a full setup is beyond the scope of this article, the Visual Studio Code team has done a great write up and I highly recommend it. Combine this with a Dockerfile with a non-root user and you have a solid start to keeping yourself safe both locally and when you deploy your application.
Other Principles to Follow
While this will help, it’s far from adequate. However, following the 80/20 rule, I believe this type of approach will keep most people decently safe. For true security though, I have a few more recommendations.
-
Pin dependency versions
I know this will annoy some people and is more of a “pick your poison” suggestion because let’s face it, no one enjoys “update package x” stories in our sprints. Dependency spaghetti, weird caching issues, “builds on my machine” conversations, they aren’t fun. However, keeping them pinned does keep you safer from these types of attacks. Yes, CVEs are discovered every day and those carry their own risks and you’ll still need to monitor your packages. But personally, I pick this “poison.”
-
Egress control
Egress control is miserable. New integrations, onboarding new vendors, etc., all lead to configuration updates. And in some attack cases, like LiteLLM, if your app happens to call Vercel, it might not protect you anyway. But again, it can significantly lower your risk. It can prevent the downloading of packages from command-and-control servers and prevent data from being sent off to unknown servers. The method of doing this will differ between Kubernetes, servers, and containers, but it is well worth doing to limit your attack surface.
Conclusion and A Word to Teachers and How-To Authors
With the extent that all computers are now connected, it is no longer just the security team’s responsibility to keep a company safe. The more everyone learns about how security, computers themselves, and the packages/programs we all depend on function, the safer we can keep ourselves.
To this end, while it has never been a good idea to blindly copy a command from the internet and run it on a computer, we all know it happens. To those who write articles and set up instructions (I include myself here), we have to do our best to at least call out any shortcuts we take or any additional configuration that should be done. We never know the level of the people who will come across our article.
Stay safe, everyone.