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 will recognize on sight. One stage. A FROM ubuntu:24.04 with no digest. apt-get install for curl and unzip. A bash loop to pull the AWS CLI zip and the kubectl binary. No USER directive, so the container runs as root by default. 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 is a different image entirely. Multi-stage, so the build tools never ship in the runtime. Base digest pinned. An explicit USER 10001:0 so the container runs as a non-root account with root group (GID 0) for OpenShift SCC compatibility. A full set of OCI labels so Scout and GitHub actually know what they are scanning. The example below shows the structural changes only; 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.

That missing USER directive is one of the most common findings in container security audits. In regulated industries it shows up 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. Skip it, and the cost compounds every year the image gets pulled.

Full source, including CI workflows, the 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. A 156% rise year-over-year.

Containers are a smaller slice of that total than npm or PyPI. The propagation model is the same. 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.

Then there is the silence between the build and the consumer. Most public images carry no signature, no SBOM, 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 not that the tooling is hard. It is that nobody ran the migration.

And there is recency. OpenSSF Scorecard is new enough that most maintainers have never seen their own score. Running it once is a ten-minute workflow. Run it today and most public images would come back somewhere between 3 and 5.

Risk and blast radius#

Direct exposure scales with pulls. Past 730,000 the image is well beyond 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#

For a solo maintainer the trade-off space is narrower than it is 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. Getting from 7.8 to 8.5 costs forty hours of process overhead and tops out at a ceiling you do not control. I stopped at 7.8. For a solo maintainer the marginal return on the next tier goes negative.

Framework: supply chain hardening for solo maintainers#

Three layers. Each one is a deploy cycle. The names track the migration topic family on purpose, because this is a migration from insecure defaults to attested defaults, not a fresh 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 roughly one hour a 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 after.

Now price the alternative. A supply chain incident response engagement, forensics and containment and 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 whole argument. Look at the Codecov bash uploader compromise in 2021: it exposed credentials from customer CI environments across a two-month window before anyone detected it, through a single injected line of shell. Shell script, not container. Same propagation graph as 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, and 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 run under 300 lines of YAML. Skip the migration and the cost compounds every month the image stays insecure by default. Run it and the cost is one sustained weekend of work plus about an 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 stuck with the do-nothing path 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.