Build ROSE tools using a container

• Outcome: Review
• Latest audit: Sep 10, 2026 · 5:47 PM UTC
• Version: 1.0.0

Overview

This ROSE build helper is coherent, but it tells users to run an unverified Docker image with write access to their project workspace.

Review before installing or using. Only run the Docker command if you trust or built the `rose-dev` image, preferably pin it to a verified digest, and consider using a disposable checkout or narrower mounts so the container cannot freely modify the whole project. Treat `make clean` as deleting the configured build directory.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:37

Finding

Unpinned Container Image Receives Read-Write Workspace Access

Content

View full analysis

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

View 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.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 92% confidence

Finding

The skill instructs users to run a container from rose-dev:latest, which is a mutable tag rather than an immutable version or digest. This creates supply-chain risk because the image content can change over time or be replaced in a compromised registry, leading users to build and run untrusted code in a development environment that mounts the current workspace into the container.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The markdown instructs users to run rm -rf $(BUILDDIR) as part of the clean target, which deletes the build directory recursively. The document does not include any warning that this operation removes files, nor any caution about ensuring BUILDDIR is set correctly before running it.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.