Python virtual environments and security

Python virtual environments are a standard part of Python development. Every modern guide to Python development includes "create a virtual environment first." Security guides often include virtual environments in their recommendations.

But virtual environments are an isolation mechanism, not a security mechanism. They solve a different problem than supply chain attacks.

What virtual environments do

A virtual environment creates an isolated Python environment with its own site-packages directory, its own pip, and its own Python binary (or a symlink to one). Packages installed in one virtual environment are not visible in another, and not visible in the system Python.

This solves the dependency conflict problem: project A needs requests==2.28.0 and project B needs requests==2.31.0. Put each in a virtual environment and both can coexist.

It also provides some accidental security benefit: a malicious postinstall script that writes to ~/.local/lib/python3.11/site-packages/ to persist across virtual environments will fail if the virtual environment is active and those paths are different. But this is a side effect, not a design goal.

What virtual environments do NOT do

Prevent malicious code from executing. When you run pip install evil-package in a virtual environment, the postinstall script runs with your user permissions. It has access to ~/.aws/credentials, ~/.ssh/, and your environment variables. The virtual environment doesn't change the permissions under which the install script runs.

Isolate network access. A malicious postinstall script can make outbound HTTP requests regardless of whether a virtual environment is active.

Prevent filesystem access outside the venv. The virtual environment only controls where packages are installed. It doesn't create a filesystem sandbox. Install scripts can read and write anywhere your user has permission to access.

Contain a compromised package. If a malicious package runs successfully in your virtual environment, it has the same access to your system as any other code you run.

The confusion

The confusion comes from conflating two different kinds of isolation:

Package isolation (what venv provides): packages in one environment can't interfere with packages in another. This is about dependency management.

Process isolation / security sandbox (what venv does NOT provide): code executing within an environment can't access resources outside the sandbox. This is about security.

Virtual environments provide the first. Security sandboxes — containers, VMs, macOS Sandbox, Linux seccomp — provide the second.

What actually protects you at install time

1. Hash verification (pip --require-hashes, uv sync --frozen, poetry install): verifies that the package you downloaded matches a previously-recorded hash. Protects against tampered tarballs and some account takeover attacks.

2. Behavioral sandbox (what Veln uses): actually runs the install code in an isolated environment with no network access and no real filesystem access. Observes what the install script does, prevents it from having real effects, and reports the behavior.

3. Cooling gates and community consensus (what Veln uses): prevents installation of new or anomalous packages before behavioral analysis or community trust has been established.

Does using a venv reduce risk at all?

Slightly, but not significantly:

• A malicious postinstall that writes to the venv's site-packages (to persist across python runs within the venv) is slightly more likely to fail with unusual errors that might be noticed. But writing to the user's home directory or making network requests is completely unaffected.
• Using a venv per project means that a malicious package installed for project A can't directly import itself into project B's venv. But it can still exfiltrate credentials and establish system-level persistence.

Use virtual environments for dependency management. Use Veln for supply chain security. They're solving different problems.

---

Virtual environments isolate packages, not processes. Veln isolates the install itself.