T08 · Insecure Dependencies
Warning
- Location
- references/setup.md:27
- Finding
- Mutable Third-Party Container Image Is Executed Without Version or Digest Pinning## Vulnerability Details **File Location**: `references/setup.md:27` and `references/setup.md:35` **Vulnerability Type**: Supply-chain exposure through an unpinned container image **Risk Level**: Medium ### Vulnerable Code ```bash docker run --rm -p 127.0.0.1:8000:8000 psyb0t/wickworks:latest ``` ```yaml services: wickworks: image: psyb0t/wickworks:latest restart: unless-stopped ports: - "127.0.0.1:8000:8000" environment: LOG_LEVEL: INFO MAX_BARS: "5000" MIN_BARS: "50" WORKERS: "2" ``` ### Technical Analysis Both documented installation methods execute the third-party `psyb0t/wickworks:latest` container image. The `latest` tag is mutable and does not identify the exact image reviewed when this Skill was audited. A registry publisher can replace the tag without changing the instructions in this repository. Running a container is necessary for the declared indicator-computation functionality, but executing an unpinned image is not the minimum supply-chain risk required. An immutable release digest would provide the same functionality while preventing silent substitution. ### Attack Path 1. An attacker compromises the image publisher account, registry credentials, build pipeline, or upstream image. 2. The attacker publishes a modified image under `psyb0t/wickworks:latest`. 3. An operator follows the documented installation command or recreates the Compose deployment. 4. Docker resolves `latest` to the attacker-controlled image and executes it. 5. The modified service receives all OHLC data submitted by clients and can perform arbitrary actions available inside the container. ### Impact Assessment A substituted image could read or transmit submitted OHLC datasets, falsify indicator results, consume CPU and memory, or make arbitrary outbound network requests from the container. It would obtain the permissions available to the containerized process. ...[truncated 309 chars]
- Remediation
- ## Remediation Suggestions - Replace `latest` with a reviewed, immutable image reference using both a release version and SHA-256 digest. - Apply the same pinned reference to the `docker run` and Docker Compose examples. - Publish expected image digests through a trusted release channel. - Verify image signatures and provenance before execution, such as through Sigstore/Cosign attestations. - Use automated dependency monitoring to review and deliberately update the pinned digest. - Retain the existing loopback binding and avoid adding host mounts, elevated capabilities, or privileged mode. - Consider documenting a read-only root filesystem, capability dropping, resource limits, and a non-root container user as additional defense in depth.