T08 · Insecure Dependencies
- Location
SKILL.md:223- Finding
Unpinned Container Image Executed During Privileged Instance Bootstrap
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 223-229
Vulnerability Type: Untrusted or mutable third-party container dependency
Risk Level: Mediumhcl user_data = <<-EOF #!/bin/bash apt-get update apt-get install -y docker.io systemctl start docker docker run -d -p 80:8080 ${var.docker_image} EOFTechnical Analysis
The EC2 bootstrap script installs Docker and immediately executes the image supplied through
${var.docker_image}. The example does not require an immutable image digest, approved registry, signature verification, or provenance validation. A tag such aslatestor another mutable version can therefore resolve to different image contents after the infrastructure configuration has been reviewed.The container also runs with Docker's default root user unless the image defines another user. No runtime restrictions are specified, such as capability removal, a read-only root filesystem, resource limits, or restricted access to the instance metadata service. Although container root does not automatically equal host root, a malicious image can attack exposed kernel or runtime vulnerabilities and access network services or cloud metadata available to the instance.
Attack Path
- A deployment uses a mutable image tag, or an attacker gains control of the referenced registry repository or image-selection variable.
- The attacker replaces the tag's contents or supplies a malicious
${var.docker_image}value. - Terraform provisions or reprovisions the EC2 instance and executes the
user_datascript as root. - Docker retrieves the currently resolved image without digest or signature verification.
- The malicious image starts automatically and executes attacker-controlled code inside the instance environment.
- The code can probe the instance metadata service, internal network, mounted data, container runtime, and kernel for credentials or escalation opp ...[truncated 522 chars]
- Remediation
View remediation
Remediation Suggestions
- Restrict images to explicitly approved registries and repositories.
- Pin every production image by immutable digest, for example
registry.example/app@sha256:..., rather than relying only on a mutable tag. - Verify image signatures and provenance before deployment, using a mechanism such as Sigstore Cosign or an equivalent registry admission policy.
- Scan images for malware, known vulnerabilities, embedded credentials, and prohibited packages in CI.
- Run the application as a dedicated non-root user and enforce that requirement in both the image and runtime configuration.
- Drop unnecessary Linux capabilities, enable
no-new-privileges, use a read-only root filesystem where possible, and set CPU and memory limits. - Require IMDSv2, limit metadata hop access where appropriate, and attach only a least-privilege IAM instance profile.
- Prefer a controlled image deployment mechanism that records and validates the expected digest before the instance starts it.