Why I Develop in a Disposable VM | Ali Kayar

DevelopmentSecurity

Why I Develop in a Disposable VM

Take-home assignments, malicious Git hooks, and why I moved my development environment into an isolated VM.

September 19, 20265 min read

Recently, I've started seeing developer-targeted attacks more often.

Most of them are supply chain attacks like malicious Git hooks, npm scripts, or package lifecycle hooks.

What makes it worse is that many of these attacks are hiding behind job interviews and take-home assignments that look totally normal at first.

Recently, I came across an example of this in a developer's post. He got a ZIP file sent by a recruiter, which included their project for a take-home assignment.

When he examined the code, he found hidden Git hooks.

Those hooks were designed to execute malicious code. When you run a Git command that triggers the hook, it might steal anything your user can access on the computer.

Your personal files, SSH keys, environment secrets, API tokens — everything is potentially at risk.

That made me curious and a bit paranoid.

So, I changed the way I work.

1. Architecture

Host tools connect to an isolated, disposable development VM

I recommend working inside a virtual machine instead of directly on your host.

There are several tools you can use depending on your operating system:

OrbStack on macOS
Hyper-V Manager on Windows
KVM/QEMU on Linux

The tool itself is not that important. They all serve the same purpose: create a VM, install Ubuntu inside it, and move your development environment there.

Your host keeps things like:

GUI applications such as VS Code
DBeaver, Redis Insight, and similar tools
Your browser and pretty much everything personal

And the VM keeps pretty much everything related to development:

Source code and repositories
Programming languages
CLI tools, databases, and containers

VS Code works very well with this setup thanks to the Remote - SSH extension.

← More articles

2. What Does This Architecture Offer?

2.1. A Clean Host

One thing I really don't like about development tools is how much they spread across your system.

You install something - maybe a package manager, programming language, or CLI tool - and suddenly you have files in several different directories.

Then, when you decide to remove it, good luck with that.

At least from my experience, uninstalling development tools rarely means actually removing everything they introduced.

With a VM, it doesn't really matter. If the VM gets messy, just recreate it.

It feels a bit like formatting your computer, except you don't lose your actual machine or data.

2.2. Better Isolation Against Malicious Code

If you run malicious code directly on your main machine, it runs inside an environment that probably contains a lot of valuable data.

It can potentially steal anything under your user directory.

If you're running with elevated privileges, things can get even worse, including breaking the system entirely.

When your development environment lives inside a VM, the code can't reach the host filesystem if the VM is configured correctly.

But that doesn't mean it's perfectly safe.

If you connect your host filesystem through shared folders or configure networking carelessly, you might weaken the VM isolation.

So you still need to isolate it properly.

There is also another possibility: malware can theoretically escape a VM through a hypervisor vulnerability.

But at that point, we're talking about a completely different class of attack, not a basic supply chain attack.

My goal is not perfect security. I'm just trying to reduce the blast radius.

2.3. Native Playground

Since most servers run Linux, many tools and programming languages are designed and optimized for Unix-like environments.

If you work on macOS or Windows, you might notice some incompatibilities while developing, especially when you deploy your code to production.

Inside the VM, you get a native Ubuntu/Linux environment.

In some cases, it might also be faster or more predictable than running the same tooling directly on the host.