T08 · Insecure Dependencies
Warning
- Location
- selfhosted.md:20
- Finding
- Mutable Docker Image Tags Permit Unreviewed Runtime Changes<![CDATA[ ## Vulnerability Details **File Location**: `selfhosted.md`, lines 20-65 **Vulnerability Type**: Unpinned third-party container dependencies **Risk Level**: Medium ### Vulnerable Code ```yaml # docker-compose.yml services: heyform: image: heyform/heyform:latest ports: - "3000:3000" environment: DATABASE_URL: postgres://... SESSION_SECRET: your-secret SMTP_HOST: smtp.example.com ``` ```yaml services: opnform-api: image: jhumanj/opnform-api:latest opnform-client: image: jhumanj/opnform-client:latest ``` ```bash docker run -d -p 3000:3000 \ -e DATABASE_URL=postgres://... \ formbricks/formbricks:latest ``` ### Technical Analysis The deployment examples use the mutable `latest` tag for HeyForm, OpnForm, and Formbricks images. A mutable tag does not identify a specific, previously reviewed artifact. Its associated image can change whenever the publisher updates the tag. Consequently, repeating the same documented deployment command can execute different code without any change to the Skill or deployment configuration. This weakens reproducibility and creates a supply-chain boundary in which a compromised publisher account, compromised registry, or malicious upstream release could replace a trusted image with attacker-controlled content. The issue is especially sensitive for form platforms because these containers may receive submitted personal data and access database URLs, session secrets, SMTP credentials, storage services, and mounted volumes. ### Attack Path 1. A user follows the documented deployment example and configures a service using an image tagged `latest`. 2. The upstream publisher account, build pipeline, or container registry is compromised, or an unsafe upstream release is assigned to the mutable tag. 3. The user initially pulls the image, redeploys the service, or runs an automated update process. 4. Docker resolves `latest` to the newly published, unreviewed image. 5. Attacker- ...[truncated 804 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Replace every mutable tag with a reviewed, immutable image digest, for example: ```yaml image: heyform/heyform@sha256:<reviewed-digest> ``` - If a human-readable version is retained, pin both the version and digest and treat the digest as authoritative. - Verify image signatures and provenance before deployment, such as with Sigstore/Cosign where the publisher supports it. - Scan pinned images for known vulnerabilities and secrets before promotion. - Use a controlled update process that reviews release notes, regenerates the digest, scans the new image, tests it, and requires approval before production rollout. - Run containers as non-root with a read-only root filesystem and minimal Linux capabilities. - Do not mount the Docker socket or unnecessary host directories. - Restrict outbound network access and provide only narrowly scoped credentials required by each service. ]]>