T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:36
- Finding
- Mutable Container Image Tag Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:34-42` **Vulnerability Type**: Unpinned third-party container dependency **Risk Level**: Medium **Vulnerable Code Snippet**: ```yaml services: searxng: image: searxng/searxng:latest container_name: searxng ports: - "8080:8080" volumes: - ./searxng:/etc/searxng:rw environment: - SEARXNG_BASE_URL=http://localhost:8080/ ``` ### Technical Analysis The deployment instructions use the mutable image tag `searxng/searxng:latest`. A mutable tag does not identify the exact container artifact reviewed or originally installed. The registry owner—or an attacker who compromises the image repository—can replace the image referenced by that tag without changing this Skill. When the user subsequently pulls or deploys the image, Docker may execute code that differs from the version expected during review. The container also receives a writable bind mount at `./searxng:/etc/searxng:rw`, allowing code inside the image to modify the host-side SearXNG configuration directory. The actual privileges available beyond that directory depend on the Docker configuration and host environment. ### Attack Path 1. The upstream image repository, publishing account, or build pipeline is compromised, or the `latest` tag is updated with an unsafe image. 2. A user follows the documented instructions and runs `docker compose up -d`, or later pulls the mutable tag during an update. 3. Docker retrieves the new image referenced by `searxng/searxng:latest`. 4. Attacker-controlled code executes inside the container. 5. That code can access the container's network and modify data exposed through the writable `./searxng:/etc/searxng` bind mount. ### Impact Assessment Successful exploitation permits arbitrary execution inside the deployed container with the container's assigned privileges. It may expose search traffic, alter search responses, access reac ...[truncated 255 chars]
- Remediation
- ## Remediation Suggestions - Pin the container image to a reviewed immutable digest, for example: ```yaml image: searxng/searxng@sha256:<verified-image-digest> ``` - Record the corresponding release version and establish a controlled process for reviewing and updating the digest. - Verify image signatures or provenance attestations where supported. - Configure automated vulnerability scanning for the pinned image. - Run the container as a non-root user with dropped Linux capabilities and a read-only root filesystem where compatible. - Change the configuration mount to read-only after initial setup if runtime writes are unnecessary.