CI actions and container images use mutable tags instead of pinned digests

[raballew]

Description

GitHub Actions across workflow files use mutable tags (@v4, @v3, @v6) instead of commit SHA pins. A compromised upstream action repository can silently inject malicious code into the CI pipeline.

The same pattern applies to container images:

• secrets-job.yaml:24 uses quay.io/jumpstarter-dev/jumpstarter-utils:latest without digest pinning
• Flasher driver hardcodes :latest OCI bundles at jumpstarter_driver_flashers/driver.py:19

SLSA attestation (attest-build-provenance@v1) exists but verification is consumer-opt-in.

Suggested Fix

• Pin GitHub Actions to commit SHA digests
• Add Dependabot configuration for GitHub Actions updates
• Pin container images by digest

[mangelajo]

What is secrets-job?

I think it's not feasible currently to hardcode flasher driver artifact sha's or check for attestation at this point;

[ambient-code]

Investigation: CI actions and container image tagging

Re: secrets-job

secrets-job refers to the Helm chart template at controller/deploy/helm/jumpstarter/charts/jumpstarter-controller/templates/secrets-job.yaml. It's a Kubernetes Job that runs at Helm sync time (ArgoCD hook) to create jumpstarter-router-secret and jumpstarter-controller-secret if they don't already exist. It uses quay.io/jumpstarter-dev/jumpstarter-utils:latest as its container image. This is a valid finding — the image could be pinned to a digest — but it's an internal image you control, so the risk is low.

On flasher driver SHA pinning

Agreed that pinning flasher bundle OCI references to digests is not feasible right now. Those defaults (e.g. quay.io/jumpstarter-dev/jumpstarter-flasher-test:latest) are configurable per-instance and are meant to track the latest available bundle. Hardcoding digests would require coordinated releases across repos, which adds complexity without proportional security benefit for internally-published artifacts. Low priority.

GitHub Actions pinning — the actionable part

The repo already pins several third-party actions to commit SHAs (e.g. backport.yaml pins actions/checkout, actions/create-github-app-token, and korthout/backport-action; lint.yaml pins astral-sh/ruff-action and crate-ci/typos). But the majority of action references still use mutable version tags:

• actions/checkout@v4 (used in ~12 places, only pinned in backport.yaml)
• actions/setup-go@v5, actions/cache@v5
• actions/configure-pages@v5, actions/upload-pages-artifact@v4, actions/deploy-pages@v5
• actions/upload-artifact@v7, actions/attest-build-provenance@v4, actions/github-script@v8
• dorny/paths-filter@v3, peter-evans/repository-dispatch@v4
• astral-sh/setup-uv@v7 (pinned in some files but not in e2e.yaml)
• docker/setup-qemu-action@v4, docker/setup-buildx-action@v4, docker/login-action@v4, docker/metadata-action@v5, docker/build-push-action@v7

Proposed plan (high priority):

1. Pin all GitHub Actions to commit SHAs with a version comment, matching the pattern already used in backport.yaml and lint.yaml (e.g. actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2). This is a one-time mechanical change across the workflow files.

2. Add a .github/dependabot.yml configured for github-actions to automatically propose PRs when pinned actions have new versions:

   version: 2
   updates:
     - package-ecosystem: "github-actions"
       directory: "/"
       schedule:
         interval: "weekly"

Low priority (no action needed now):

• jumpstarter-utils:latest in secrets-job.yaml — internal image, low risk, can be pinned to a digest when convenient.
• Flasher driver OCI bundle defaults — configurable at runtime, not feasible to pin as discussed.

Happy to submit a PR for items 1 and 2 if that would be helpful.

---

This investigation was performed by an automated agent (Ambient/Claude).