T08 · Insecure Dependencies
Error
- Location
- SKILL.md:82
- Finding
- Unverified Mutable Third-Party Container Image Receives Account Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 82-89; additionally referenced in lines 139-146 **Vulnerability Type**: Untrusted and unpinned third-party container dependency **Risk Level**: High ### Vulnerable Code ```bash docker run -d \ --name grass-node \ --restart unless-stopped \ -e GRASS_USER=your@email.com \ -e GRASS_PASS=yourpassword \ mrcolorrain/grass:latest ``` The equivalent Docker Compose configuration also uses the same mutable image: ```yaml grass: image: mrcolorrain/grass:latest container_name: grass-node restart: unless-stopped environment: - GRASS_USER=${GRASS_EMAIL} - GRASS_PASS=${GRASS_PASSWORD} ``` ### Technical Analysis The instructions execute `mrcolorrain/grass:latest`, a third-party container image published under an individual namespace, and provide Grass account credentials directly to that image. The mutable `latest` tag does not identify an immutable, reviewed artifact. Its contents can change without any corresponding modification to the audited skill. The documentation does not require an image digest, signature verification, source-code review, software bill of materials, or other provenance validation. Consequently, compromise of the image publisher or registry account could cause future installations or container recreations to retrieve attacker-controlled content. The `unless-stopped` restart policy also allows the downloaded image to operate persistently as a long-running workload, although that persistence is part of the declared node functionality. ### Attack Path 1. An attacker compromises the publisher account, registry credentials, or build pipeline associated with `mrcolorrain/grass`. 2. The attacker replaces the image referenced by `mrcolorrain/grass:latest` with a malicious version. 3. A user follows the documented installation instructions or later recreates/pulls the container. 4. Docker downloads and executes the changed image. 5. The malicious container r ...[truncated 857 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Prefer an official, vendor-maintained image. If no official image exists, audit the source and build the container internally from a reviewed commit. 2. Pin the image to an immutable cryptographic digest, for example: ```yaml image: trusted/repository@sha256:VERIFIED_DIGEST ``` 3. Verify image signatures and provenance with a mechanism such as Sigstore/Cosign before deployment. 4. Review the image's SBOM and scan it for known vulnerabilities and unexpected binaries. 5. Use a dedicated low-value account with a unique password instead of credentials reused elsewhere. 6. Restrict container egress to only the destinations required by the service where technically feasible. 7. Run the container as a non-root user, drop unnecessary Linux capabilities, use a read-only root filesystem, and enable `no-new-privileges`. 8. Establish an explicit update process in which each new digest is reviewed before deployment rather than tracking `latest`. ]]>