Docker supply chain hardening — from Scout D to OpenSSF 7.8 on a 730K-pull image

What grade D actually looked like#

The starting Dockerfile was the version most maintainers recognize. One stage. A FROM ubuntu:24.04 without a digest. apt-get install for curl and unzip. A bash loop to download the AWS CLI zip and kubectl binary. No USER directive, which means implicit root. No OCI labels. No hadolint. No lockfile for the base image.

1
# Before: single stage, implicit root, no labels, no digest pin
2
FROM ubuntu:24.04
3

4
RUN apt-get update && apt-get install -y curl unzip \
5
    && curl -o awscliv2.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip \
6
    && unzip awscliv2.zip && ./aws/install \
7
    && curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl \
8
    && install kubectl /usr/local/bin/kubectl
9

10
ENTRYPOINT ["/bin/bash"]

The secure version after Phase 3 looks like a different image. Multi-stage so the build tools never ship in the runtime. Base digest pinned. Explicit USER 10001:0 so the container runs as a non-root account with root group (GID 0) for OpenShift SCC compatibility. Full set of OCI labels so Scout and GitHub actually know what they are scanning. The example below illustrates the structural changes; the production Dockerfile in the repo additionally ships jq, envsubst, curl, and unzip in the runtime, writes the resolved kubectl version to /etc/kube-version as a drift-detection marker, and uses /usr/local/aws-cli as the AWS CLI install path.

1
# After: multi-stage, digest-pinned, non-root, OCI-labeled
2
FROM ubuntu:24.04@sha256:c4a8d5503dfb2a3eb8ab5f807da5bc69a85730fb49b5cfca2330194ebcc41c7b AS builder
3

4
ARG KUBE_VERSION=latest
5
RUN apt-get update && apt-get install -y --no-install-recommends \
6
        ca-certificates curl unzip \
7
    && curl -fsSL -o /tmp/awscliv2.zip \
8
        https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip \
9
    && unzip -q /tmp/awscliv2.zip -d /tmp \
10
    && /tmp/aws/install -i /opt/aws-cli -b /usr/local/bin \
11
    && curl -fsSL -o /usr/local/bin/kubectl \
12
        https://dl.k8s.io/release/${KUBE_VERSION}/bin/linux/amd64/kubectl \
13
    && echo "$(curl -fsSL https://dl.k8s.io/release/${KUBE_VERSION}/bin/linux/amd64/kubectl.sha256)  /usr/local/bin/kubectl" | sha256sum -c - \
14
    && chmod +x /usr/local/bin/kubectl
15

16
FROM ubuntu:24.04@sha256:c4a8d5503dfb2a3eb8ab5f807da5bc69a85730fb49b5cfca2330194ebcc41c7b AS final
17

18
LABEL org.opencontainers.image.source="https://github.com/heyvaldemar/aws-kubectl-docker"
19
LABEL org.opencontainers.image.licenses="MIT"
20
LABEL org.opencontainers.image.description="AWS CLI v2 + kubectl on Ubuntu 24.04"
21

22
RUN apt-get update && apt-get install -y --no-install-recommends \
23
        ca-certificates \
24
    && rm -rf /var/lib/apt/lists/* \
25
    && useradd --system --uid 10001 --gid 0 --create-home --home-dir /home/app --shell /sbin/nologin --comment "aws-kubectl runtime user" app \
26
    && chmod -R g=u /home/app
27

28
COPY --from=builder /opt/aws-cli /opt/aws-cli
29
COPY --from=builder /usr/local/bin/kubectl /usr/local/bin/kubectl
30
RUN ln -s /opt/aws-cli/v2/current/bin/aws /usr/local/bin/aws
31

32
USER 10001:0
33
WORKDIR /home/app
34
ENV HOME=/home/app
35

36
CMD ["bash"]

The production Dockerfile’s KUBE_VERSION ARG defaults to latest and resolves to the current stable release at build time via kubectl’s stable.txt channel; the example above keeps the same default, with the resolution logic elided for readability.

The missing USER directive is one of the most common findings in container security audits. In regulated industries it surfaces as a late-stage compliance blocker. In security post-mortems it maps to privilege-escalation and lateral-movement patterns documented across years of incident reporting. In cloud-native environments it is the reason OpenShift restricted-v2 SCC refuses your pod. One line. The cost of skipping it compounds every year the image gets pulled.

Full source including CI workflows, SECURITY.md disclosure policy, and the v1-maintenance migration guide lives at github.com/heyvaldemar/aws-kubectl-docker.

Why this keeps happening#

Sonatype’s 2024 State of the Software Supply Chain report logged 512,847 malicious open-source packages over the preceding year. That is a 156% rise year-over-year.

Containers are a smaller slice of that total than npm or PyPI. The propagation model is identical. A base image ships, downstream teams pull it, and the maintainer’s attack surface becomes the attack surface of every production cluster that pulled it. One compromised personal access token reaches a cluster in Frankfurt and a cluster in Singapore by the next morning, because the image digest has already rolled out through the nightly base rebuilds in both places.

The second driver is silence between the build and the consumer. Most public images have no signature, no SBOM, and no build provenance. A pull resolves a tag to a digest. That is the entire audit trail. Sigstore fixed the signing cost by making keyless cosign verification free through GitHub OIDC. BuildKit fixed the SBOM and provenance cost by making both a single build flag. The reason most images still ship without them is that nobody ran the migration, not that the tooling is hard.

The third driver is recency. OpenSSF Scorecard is new enough that most maintainers have not seen their own score. Running it once is a ten-minute workflow. Most public images would return a number between 3 and 5 if they ran it today.

Risk and blast radius#

Direct exposure scales with pulls. At over 730,000 pulls the image is past the threshold where a single supply chain compromise reaches hundreds of downstream CI pipelines inside days. The pulls counter is an adoption metric. It is also a blast radius metric.

Systemic exposure is the harder calculation. A single maintainer account. A single personal access token with write:packages. A single compromised laptop. The OWASP Top 10 for CI/CD Security captures these as CICD-SEC-2 (Inadequate Identity and Access Management) and CICD-SEC-6 (Insufficient Credential Hygiene), and the attack pattern that dominated 2024 was exactly this chain. Hardening the build pipeline matters more than hardening the runtime of the image itself, because the runtime is downstream of whoever signed the image.

Regulatory exposure depends on who pulled the image. If any consumer runs it in a workload subject to EU NIS2, US Executive Order 14028, or financial regulatory frameworks that require SBOM attestations, the maintainer is inside the trust chain whether the maintainer asked to be there or not.

Options compared#

The trade-off space for a solo maintainer is narrower than for a funded team. The table below is the honest comparison for public utility images under 1 GB.

The jump from 5 to 7 costs four hours once. The jump from 7 to 7.8 costs another eight hours plus a breaking release. The jump from 7.8 to 8.5 costs forty hours of process overhead and caps at a ceiling you do not control. I stopped at 7.8 because the marginal return on the next tier goes negative for a solo maintainer.

Framework: supply chain hardening for solo maintainers#

Three layers. Each one is a deploy cycle. The names match the migration topic family because this is a migration from insecure defaults to attested defaults, not a new build from scratch.

1
# Layer 1: run once before any changes
2
# 1. Current Scorecard baseline
3
docker run -e GITHUB_AUTH_TOKEN=$GITHUB_TOKEN gcr.io/openssf/scorecard:stable \
4
    --repo=github.com/OWNER/REPO --show-details
5

6
# 2. Current Scout grade
7
docker scout quickview OWNER/IMAGE:latest
8

9
# 3. Trivy CVE baseline
10
trivy image --severity HIGH,CRITICAL OWNER/IMAGE:latest
11

12
# 4. Pin every base image to a digest and save the old Dockerfile
13
git mv Dockerfile Dockerfile.baseline

1
# Layer 2: .github/workflows/publish.yml (signing + attestation)
2
permissions:
3
  contents: read
4
  id-token: write
5
  packages: write
6
  attestations: write
7

8
jobs:
9
  build:
10
    runs-on: ubuntu-latest
11
    outputs:
12
      digest: ${{ steps.build.outputs.digest }}
13
    steps:
14
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
15

16
      - uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4
17

18
      - uses: docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4
19
        with:
20
          username: ${{ secrets.DOCKERHUB_USERNAME }}
21
          password: ${{ secrets.DOCKERHUB_TOKEN }}
22

23
      - id: build
24
        uses: docker/build-push-action@bcafcacb16a39f128d818304e6c9c0c18556b85f # v7
25
        with:
26
          platforms: linux/amd64,linux/arm64
27
          push: true
28
          provenance: mode=max
29
          sbom: true
30
          tags: ${{ env.IMAGE }}:${{ env.VERSION }}
31

32
      - uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
33
        with:
34
          subject-name: ${{ env.IMAGE }}
35
          subject-digest: ${{ steps.build.outputs.digest }}
36
          push-to-registry: false
37

38
      - uses: sigstore/cosign-installer@cad07c2e89fa2edd6e2d7bab4c1aa38e53f76003 # v4.1.1
39
        with:
40
          cosign-release: "v2.6.1"
41

42
      - run: |
43
          set -euo pipefail
44
          echo "${TAGS}" | while IFS= read -r tag; do
45
            [ -z "$tag" ] && continue
46
            cosign sign --yes "${tag}@${DIGEST}"
47
          done
48
        env:
49
          TAGS: ${{ steps.meta.outputs.tags }}
50
          DIGEST: ${{ steps.build.outputs.digest }}

1
on:
2
  schedule:
3
    - cron: '0 6 * * 2'   # Tue 06:00 UTC
4
  push:
5
    branches: [main]
6

7
permissions: read-all
8

9
jobs:
10
  analysis:
11
    runs-on: ubuntu-latest
12
    permissions:
13
      security-events: write
14
      id-token: write
15
    steps:
16
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
17
        with:
18
          persist-credentials: false
19

20
      # Pinned to commit SHA, not tag SHA (annotated tags dereference differently)
21
      - uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
22
        with:
23
          results_file: results.sarif
24
          results_format: sarif
25
          publish_results: true
26

27
      - uses: github/codeql-action/upload-sarif@95e58e9a2cdfd71adc6e0353d5c52f41a045d225 # v4.35.2
28
        with:
29
          sarif_file: results.sarif

1
# Annotated tag: first call returns tag object SHA
2
gh api repos/ossf/scorecard-action/git/refs/tags/v2.4.3 --jq '.object'
3
# {"sha":"99c09fe...","type":"tag"}
4

5
# Dereference: second call returns the commit SHA
6
gh api repos/ossf/scorecard-action/git/tags/99c09fe... --jq '.object'
7
# {"sha":"4eaacf0543bb3f2c246792bd56e8cdeffafb205a","type":"commit"}
8

9
# Pin the commit SHA, not the tag object SHA
10
# uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a

Tradeoffs#

The full program costs sixteen hours of initial work and about one hour per month of ongoing review. At typical senior DevOps contractor rates, that is a single billable sprint up front and a fraction of a day per month thereafter.

A supply chain incident response engagement — forensics, containment, downstream notification — costs multiples more than a preventive hardening program’s entire first-year budget. An SBOM attestation audit finding inside an enterprise procurement cycle can delay or kill multi-year contracts. The asymmetry is the argument. The Codecov bash uploader compromise in 2021 exposed credentials from customer CI environments across a two-month window before detection, through a single injected line of shell. Shell script, not container. Propagation graph identical to a signed-nothing Docker image today.

The breaking release in Phase 3 costs a migration window, a v1-maintenance floating tag, and a migration guide in the README. Downstream teams can pin to v1-maintenance while they budget for a container base image bump.

The Scorecard findings that stay open at 7.8 are mostly honest. Code-Review scores 0/10 because I am the only reviewer. Branch-Protection scores 4/10 because I kept the admin bypass for emergency fixes. Fuzzing scores 0/10 because the image is a utility, not an application. These are trade-offs, not oversights. The score reflects them accurately. That is the point of the program.

The closing argument#

Public Docker images inherit the supply chain obligations of the projects that pull them, whether the maintainer accepts the responsibility or not. The tooling to sign, attest, and score an image is free and the workflows are under 300 lines of YAML. The cost of skipping the migration compounds every month the image stays insecure by default. The cost of running it is one sustained weekend of work and about one hour a month afterward.

Sixteen hours once. One hour a month after. Seven hundred thirty thousand pulls protected from whatever compromise ships against the maintainer next.

Pull the image and verify it yourself:

1
cosign verify heyvaldemar/aws-kubectl:2.0.0 \
2
    --certificate-identity-regexp "https://github.com/heyvaldemar/aws-kubectl-docker/.*" \
3
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Every signature, SBOM, and build provenance record is public in GitHub Attestations.

Discussion#

If you have hardened a public image past 7.0 on Scorecard, hit a Docker Hub referrers issue in production, or kept the alternative and want to argue the cost-benefit, drop a comment below. Counterarguments welcome and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.