Yes. A Dev Container Feature is more than a list of packages. It carries an install script that runs as root and metadata that can request privileged mode, extra capabilities, security options, mounts and an entrypoint. Adding one line to the features object can change the container's security posture.
What a Feature is
The specification defines a Feature as a self contained, shareable unit of installation code and container configuration. At minimum it has a metadata file, devcontainer-feature.json, and an entry point script, install.sh. You reference one from devcontainer.json by its identifier, usually a path in a container registry, and pass options that become environment variables for the script.
The reference gives two facts worth stating plainly. Feature scripts run as the root user, and Feature metadata can set container level options.
The settings a Feature can declare
From the Features reference, the metadata properties that change runtime behavior include:
| Property | Effect when the Feature is used |
|---|---|
| privileged | Sets privileged mode, which the reference says is required by things like Docker in Docker |
| capAdd | Adds container capabilities |
| securityOpt | Sets security options, such as updating the seccomp profile |
| mounts | Adds mounts, using the same fields as the Docker mount flag |
| entrypoint | Runs an entrypoint script at container start |
| init | Adds the tiny init process |
| containerEnv | Sets or overrides environment variables |
The same specification shows a Docker in Docker example that adds a volume mount for the Docker data directory. That is a normal, legitimate use of the mechanism. It also shows how a Feature changes the container beyond installing software.
Why this matters for review
A reviewer looking at devcontainer.json sees only the Feature's identifier and options. The privileges it requests live in its own metadata, and the script it runs lives in its own folder. A short features block can hide a large change.
Version handling matters too. Check how your tooling resolves a Feature's version. Pinning an exact version, or a content digest where your tooling supports it, makes changes arrive as a visible diff.
How to review a Feature
- Open its
devcontainer-feature.jsonand read the privileged, capAdd, securityOpt, mounts and entrypoint fields. - Read
install.shand any other files in the folder, since it runs as root. - Check the publisher and whether the source repository is one you trust.
- Pin the version so updates arrive as reviewable changes.
- Compare against what you need. If you need one tool, installing it in your own Dockerfile may be simpler.
- Record the answer in the pull request.
Settings from Features also apply to the container. Review the resulting container configuration, not only your own file. See the settings review table and lifecycle commands.
When a Feature is the right tool
Features are convenient for installing common tooling consistently across projects, and many are plain installs. The point is not to avoid them. It is to treat each as third party code with root during setup, and to look at what it asks for.
Safeguard's dependency scanning covers packages installed into the image, and you can try the free scan at gold.safeguard.sh/scan.
Quick check
Do Feature scripts run as my normal user?
No. The Features reference says they run as root. It also passes the container user and remote user to the script as environment variables.
Where do I find what a Feature requests?
In its devcontainer-feature.json file, in the properties such as privileged, capAdd, securityOpt and mounts.
Sources
Last reviewed: 19 October 2026.
