Devcontainer Skills

devcontainer-skills

Skills for setting up and working with development containers.

Skills

skill	purpose
devcontainer-setup	Creates devcontainers with Claude Code, language-specific tooling (Python/Node/Rust/Go), and persistent volumes.

---

devcontainer-setup

Attribution: forked from trailofbits/skills @ e8cc5ba on 2026-04-21.

Why forked: the upstream skill's Dockerfile and install.sh pull and execute code from multiple unverified remotes at build time (curl | bash patterns, floating feature tags, git pull against an assumed upstream). The skills CLI flagged the upstream as High Risk (Gen) / Critical Risk (Snyk). This fork replaces each remote fetch with pinned, hash-verified local copies so the devcontainer image never executes code fetched from an unpinned remote during build.

Changes from upstream

Dockerfile

• Replaced all curl -fsSL ... | bash / curl ... | tar / curl ... | dpkg calls with COPY vendor/ (manifest + text installers) followed by vendor/fetch.sh, which pulls any binary artifacts at build time and verifies every artifact against pinned SHA256SUMS.
• Dropped the three claude plugin marketplace add calls (anthropics/skills, trailofbits/skills, trailofbits/skills-curated) — each was a standing supply-chain RCE vector for future claude plugin install calls. Opt in manually per-project if desired.
• Replaced the ghcr.io/devcontainers/features/github-cli:1 feature (unpinned floating tag) with apt-get install of a pinned gh .deb (hash-verified, fetched at build time).

devcontainer.json

• Removed the features block (it only contained github-cli, now handled in the Dockerfile).

install.sh

• Removed cmd_update and its update dispatcher case. The upstream implementation ran git pull --ff-only in whatever directory the script happened to live in — in fork context this either pulled the wrong repo (skill-plugins-factory) or the user's own project, which was misleading enough to warrant removal.
• Extended cmd_template to copy vendor/ alongside the other template files so the COPY vendor/ step in the Dockerfile has its build context.

resources/vendor/ (new)

• Committed in-repo (text): claude-install.sh, fnm-install.sh, zsh-in-docker-1.2.1.sh.
• Fetched at build time (binary): git-delta_0.18.2_{amd64,arm64}.deb, fzf-0.67.0-linux_{amd64,arm64}.tar.gz, gh_2.90.0_linux_{amd64,arm64}.deb. URLs live in SOURCES; fetch.sh pulls the artifacts matching the host arch and verifies them against SHA256SUMS.
• SHA256SUMS is the single trust anchor — every artifact (committed or fetched) is verified before the Dockerfile consumes it.
• vendor/README.md records the committed/fetched split, provenance, and refresh procedures.
• Rationale for the split: multi-MB binaries bloat the repo and slow clones without adding security — the hash is what makes the artifact trustworthy, not its location in the tree.

Residual supply-chain links (not closed)

Intentionally out of scope for this fork; documented for future remediation:

1. claude-install.sh fetches Claude Code binaries from downloads.claude.ai at build time. Anthropic-signed, HTTPS-served — treated as an acceptable trust anchor for Claude itself.
2. fnm-install.sh downloads the fnm binary release zip from github.com/Schniz/fnm/releases at build time; no version is pinned in our Dockerfile call, so this floats to latest.
3. zsh-in-docker-1.2.1.sh pulls Oh My Zsh from robbyrussell/oh-my-zsh master branch at build time — the most open remaining vector. Closing this would require either vendoring the OMZ install script at a pinned commit or replacing zsh-in-docker with a direct apt install zsh plus static .zshrc.