T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:37
- Finding
- Unpinned Container Image Receives Read-Write Workspace Access## Vulnerability Details **File Location**: `SKILL.md`, lines 37–41 **Vulnerability Type**: Untrusted and mutable container dependency **Risk Level**: Medium ### Vulnerable Code ```bash docker run -it --name rose-tools-dev \ -v /home/liao/rose-install:/rose/install:ro \ -v $(pwd):/work \ -w /work \ rose-dev:latest bash ``` ### Technical Analysis The command uses `rose-dev:latest`, an unqualified image name with a mutable tag. It does not identify a trusted registry or publisher and is not pinned to an immutable SHA-256 digest. Consequently, the effective image can change after the Skill has been reviewed. Depending on Docker's configuration, an unavailable local image may also be resolved through a configured image registry. The container receives read-write access to the complete current working directory through `-v $(pwd):/work`. The ROSE installation is correctly mounted read-only, but the project workspace is not. The command also does not specify a non-root container user or disable network access. A malicious or compromised image could therefore inspect, alter, delete, or transmit workspace content as soon as it starts. This finding concerns supply-chain trust and excessive exposure to a third-party runtime image. The audited project contains only `SKILL.md`; no embedded malicious scripts or confirmed malicious payloads were present. ### Attack Path 1. An attacker compromises, replaces, or publishes the image resolved as `rose-dev:latest`, or a trusted image later changes under the mutable `latest` tag. 2. A user follows the documented `docker run` command. 3. Docker starts the attacker-controlled image with the current project mounted read-write at `/work`. 4. Image startup logic or an invoked shell command enumerates files under `/work`. 5. The image modifies or deletes source files, inserts malicious build artifacts, or exfiltrates project data through its available network connection. 6. Modified files may subsequently be built, com ...[truncated 916 chars]
- Remediation
- ## Remediation Suggestions 1. Use a fully qualified image reference from a trusted registry and pin it to an immutable digest, for example: ```bash docker run --rm -it --name rose-tools-dev \ --user "$(id -u):$(id -g)" \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,nodev \ -v /home/liao/rose-install:/rose/install:ro \ -v "$(pwd)":/work/src:ro \ -v "$(pwd)/build":/work/build:rw \ -w /work/src \ registry.example.org/trusted/rose-dev@sha256:<verified-digest> \ bash ``` 2. Verify the image digest, publisher, provenance, and signature before use. Document the expected digest and provide reproducible image build instructions. 3. Replace the mutable `latest` tag with a reviewed version tag plus digest. A version tag alone is insufficient because registry tags can be reassigned. 4. Run the container as the invoking user's UID and GID rather than relying on the image's default user. 5. Mount source code read-only and expose only a dedicated output directory as writable. 6. Disable networking with `--network none` when dependency retrieval or other network activity is unnecessary. 7. Apply additional hardening where compatible, including a read-only root filesystem, dropped Linux capabilities, `no-new-privileges`, resource limits, and temporary filesystems for required writable runtime paths. 8. Before committing or distributing outputs, inspect workspace changes and generated artifacts made during the container run.