Third-Party Actions, Commit-SHA Pinning, Marketplace Risk, and Dependency Governance: Guided Hands-On Workflow

1. Lab scenario: audit before you execute

You maintain a disposable repository called gha-supply-chain-lab. A teammate proposes Docker Setup Buildx for a later container build. The lab does not begin by running it. Instead, you prove upstream ownership, release identity, exact commit, metadata and runtime, then create an immutable reference. Only after those facts are recorded is optional execution allowed.

This is a free path: public GitHub metadata, local Git, Python/shell and a disposable repository are sufficient. No cloud account, package publication, production registry or real secret is required.

2. Preflight and current assumptions

3. Inspect the release and resolve it to an exact commit

Use the release page or GitHub API to identify the intended release. Then ask Git for the exact tag object. A 40-character result is evidence of what the tag points to at inspection time; preserve it before you edit the workflow.

git ls-remote https://github.com/docker/setup-buildx-action.git refs/tags/v4.3.0
# Expected at the verification date:
# 37fe631027851001ddb9b187196cc803df7f5f0e  refs/tags/v4.3.0

For an annotated tag, resolve the peeled commit rather than stopping at the tag object. The general rule is: execution must reference the commit containing the reviewed action files.

4. Inspect metadata and execution model at the exact SHA

Read action.yml at the resolved commit, not on main. At the verified SHA the action is a Node 24 JavaScript action with both a main and post entry point. Review inputs that change host behavior, such as driver options, persistent state and cleanup.

curl -fsSL \
  https://raw.githubusercontent.com/docker/setup-buildx-action/37fe631027851001ddb9b187196cc803df7f5f0e/action.yml \
  -o reviewed-action.yml
sha256sum reviewed-action.yml
sed -n '1,220p' reviewed-action.yml

5. Write the audit record before adding uses:

dependency:
  owner: docker
  repository: setup-buildx-action
  marketplace_signal: verified-creator
  reviewed_release: v4.3.0
  commit_sha: 37fe631027851001ddb9b187196cc803df7f5f0e
  execution:
    using: node24
    main: dist/index.cjs
    post: dist/index.cjs
  caller_permissions: contents:read
  secrets: none
  network: public GitHub/Docker tool download paths as documented
  cleanup: enabled
  review_date: 2026-09-10

This record is not a claim that every transitive npm dependency was manually proven safe. It is an explicit statement of what was reviewed and what limitations remain.

6. Pin the workflow and keep the release mapping visible

name: third-party-pin-lab
on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  bounded-setup:
    runs-on: ubuntu-24.04
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@37fe631027851001ddb9b187196cc803df7f5f0e # v4.3.0
        with:
          cleanup: true
          keep-state: false

The comment is not security-sensitive configuration; it is reviewer context. The SHA is the execution identity.

7. Simulate a compromised or moved tag locally

This simulation never changes an upstream repository. It creates two harmless commits in a local temporary repository, points v1 at the first, then force-moves the tag to the second. A branch/tag consumer silently follows the new object; a recorded SHA remains unchanged.

mkdir tag-move-sim && cd tag-move-sim
git init
git config user.email learner@example.invalid
git config user.name "Disposable Learner"
printf 'reviewed
' > action.txt
git add action.txt && git commit -m "reviewed release"
SAFE_SHA=$(git rev-parse HEAD)
git tag v1

printf 'changed after review
' > action.txt
git commit -am "later change"
NEW_SHA=$(git rev-parse HEAD)
git tag -f v1

printf 'reviewed_sha=%s
' "$SAFE_SHA"
printf 'tag_now=%s
' "$(git rev-parse v1)"
printf 'new_sha=%s
' "$NEW_SHA"
test "$SAFE_SHA" != "$(git rev-parse v1)"

The lesson is not that every moved tag is an attack. The lesson is that mutable names permit code identity to change without a workflow-file diff.

8. Optional bounded execution after review

If you want to execute the pinned action, do it only in the disposable repository, with no secrets and with explicit minimal permissions. Record run ID, attempt, source SHA, runner label and the pinned dependency SHA. The action's success proves that this reviewed commit executed successfully in that context; it does not retroactively certify the upstream project.

# From the run's evidence, record—not secrets:
# GITHUB_RUN_ID
# GITHUB_RUN_ATTEMPT
# GITHUB_SHA
# runner.os / runner.arch
# pinned action SHA from workflow revision

9. Controlled upgrade procedure

When a newer release appears, do not replace the SHA immediately. Resolve the candidate release to its exact commit, read release notes, diff old→new source/metadata, check runtime and permission changes, then update the register and workflow in the same reviewed pull request.

OLD=37fe631027851001ddb9b187196cc803df7f5f0e
NEW=<candidate-full-sha>

git clone --filter=blob:none https://github.com/docker/setup-buildx-action.git upstream-buildx
cd upstream-buildx
git diff --stat "$OLD" "$NEW"
git diff "$OLD" "$NEW" -- action.yml package.json package-lock.json src dist

Large generated bundles may require build/release provenance checks rather than line-by-line visual confidence. State that limitation explicitly instead of pretending the diff was fully audited.

10. Add update automation without surrendering review

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

Dependabot can propose updates, including SHA changes. The PR is a review request, not an authorization to auto-merge. Keep the release comment on the same line as the SHA so the mapping remains understandable and update tooling can maintain it.

11. Evidence packet

12. Cleanup

cd ..
rm -rf tag-move-sim upstream-buildx reviewed-action.yml
# Delete only the disposable repository if you created one for this lab.

13. Challenge: choose the correct control layer

A teammate wants an action that comments on pull requests and requests pull-requests: write. Decide which controls belong in dependency review, which belong in the caller's permissions:, which belong in fork-event policy, and which belong in organization allowlisting. Your answer should not be “trust it because it is popular.”

14. Lesson summary

You audited first, resolved release intent to exact code identity, inspected the execution model, pinned by SHA, bounded authority, demonstrated mutable-tag risk locally and defined an upgrade review loop. That is a repeatable supply-chain workflow rather than a one-time copy/paste decision.

Knowledge check

Official references and version notes

Version-sensitive GitHub Actions behavior in this lesson was rechecked on 2026-09-10. Re-verify release tags, commit mappings, runtime requirements and organization policy before adopting the examples in a production repository.

• GitHub Docs — Secure use reference
• GitHub Docs — Publishing actions in GitHub Marketplace and Verified creator badges
• GitHub Docs — Managing GitHub Actions settings and SHA-pinning policy
• GitHub Docs — Dependency graph support for GitHub Actions workflows
• GitHub Changelog — Actions policy SHA pinning and blocking
• GitHub Changelog — Node 20 deprecation / Node 24 migration
• Docker Setup Buildx v4.3.0 release
• Docker Build Push v7.3.0 release