The Build Step You Approved Can Change Later: How Mutable GitHub Actions Tags Can Become a Software-Supply-Chain Backdoor.

1. What the vulnerability is

A GitHub Actions workflow can call reusable code with the uses: keyword. The value normally combines a repository or action path with a selector after an @ symbol:

• actions/checkout@v6 names a public action and a major-version tag.
• octo-org/release-helper@main names a fictitious action and a branch.
• octo-org/automation/.github/workflows/deploy.yml@v2 names a remote reusable workflow and a tag.
• ./.github/actions/local-check names a local action stored in the same repository.

The dangerous assumption is that a version-looking selector is equivalent to a permanent copy of the reviewed code. It is not. A branch is designed to advance. A major tag such as v1 is commonly moved so consumers receive compatible updates. Even a specific-looking tag such as v1.4.2 is still a Git reference and can be replaced when repository permissions allow it.

A full 40-character commit SHA identifies the exact commit the workflow should load. GitHub’s secure-use guidance describes a full-length commit SHA as the current way to consume an action as an immutable release reference. The practical distinction is simple: a name is resolved; a commit identifier is selected.

2. Why a familiar tag can change

Git stores commits under object identifiers and uses human-friendly references to point at them. A tag such as v1 is a name in the repository’s reference namespace. Git’s own documentation includes git tag --force, which replaces an existing tag with the same name. Publishing policies may forbid or restrict that operation, but the data model itself does not make every tag permanent.

When a workflow starts, the automation platform resolves the selector in the upstream repository. If the selector now points somewhere else, the consumer can receive different code even though its workflow file, application commit, pull-request history, and approval record are unchanged.

MONDAY — reviewed state
refs/tags/v1 -> 3f4c2b1a...  approved action code

THURSDAY — after the upstream reference moves
refs/tags/v1 -> a81d9e70...  different action code

THE CONSUMER WORKFLOW DID NOT CHANGE
uses: octo-org/release-helper@v1

The upstream change can originate from several conditions:

• A maintainer intentionally moves a compatibility tag to a new release.
• An upstream maintainer account, token, GitHub App, or automation credential is compromised.
• A repository administrator or malicious insider replaces the tag.
• A transfer of repository ownership, abandoned project, or weak release process changes who controls the reference.
• A compromised release workflow publishes or retargets references without the expected human review.

The attacker does not need to break your repository or generate a hash collision. They need control over a reference your workflow already trusts. The next normal build, scheduled task, release, or deployment supplies the execution opportunity.

3. How the attack chain works

This is a software-supply-chain attack because the business delegates part of its build or deployment to externally maintained executable code. The compromise occurs upstream, while the effect appears downstream in every consumer that automatically follows the changed reference.

1. The business adopts a useful action. A developer adds a formatter, test helper, build tool, release publisher, cloud login, deployment helper, or reusable workflow.
2. The workflow follows a mutable selector. The entry uses a branch or tag such as @main, @v1, or @v1.4.2.
3. The initial review appears legitimate. The action works, tests pass, and the workflow is merged. Future runs no longer require a change in the consumer repository.
4. Control of the upstream reference is lost or abused. An attacker obtains the ability to change the action repository, release process, or tag mapping.
5. The trusted selector is redirected. The same name now identifies changed code. Consumers following a full commit SHA are not moved by this reference update; consumers following the name are.
6. A routine event triggers execution. A push, pull request, schedule, manual release, issue event, tag creation, or downstream workflow starts the job.
7. The changed action runs inside the job’s trust boundary. It receives the runner, workspace, token permissions, exposed credentials, network path, and files available to that job.
8. Impact follows the job’s privileges. A read-only lint job may expose source or metadata. A release job can have package publishing, artifact signing, cloud deployment, or production access.
9. The normal pipeline can hide the intrusion. The workflow may still report success, publish a plausible artifact, or deploy a working application while also performing an unauthorized action.

Conditions that determine severity

The reference weakness and the business impact are separate questions. A useful assessment maps both:

• Which exact upstream repository, action path, reusable workflow, and selector are used?
• Which triggers can cause the job to run, and can untrusted contributors influence its inputs?
• What permissions does the job’s GITHUB_TOKEN receive?
• Which repository, organization, environment, package, cloud, signing, or vendor credentials are exposed?
• Does the job build only, or can it publish, approve, release, deploy, modify, or delete?
• Does it use a clean hosted runner, an ephemeral self-hosted runner, or a persistent machine with internal network access?
• Can one job influence later jobs through artifacts, caches, outputs, shared storage, images, or deployment inputs?
• Would responders be able to identify the exact action commit and verify the released artifact after the fact?

4. What a compromised action can reach

An action normally executes as JavaScript, a container, or a composite set of shell steps on the workflow runner. From a risk perspective, it should be treated like any other program launched in that job. It can read files the operating-system account can read, alter files the account can write, make network requests allowed from the runner, and use credentials or tokens made available to the job.

GitHub creates a repository-scoped GITHUB_TOKEN for each job. The token expires when the job ends or reaches its effective lifetime, but it can still perform meaningful operations during the run if the workflow grants write permissions. The token is also available through the job context, so simply omitting it from one action’s explicit input is not the same as removing its capabilities. Set the job’s permissions: deliberately.

Repository and environment secrets require careful qualification. Do not assume every stored secret is automatically printed into every process. Actual exposure depends on the workflow, action inputs, environment variables, scripts, generated configuration, credential helpers, and platform behavior. The safe rule is that a third-party action should share a job only with secrets and privileges you are prepared for that action to use.

OIDC reduces secret storage, not job trust

OpenID Connect can replace stored cloud keys with short-lived cloud credentials. That removes a valuable long-lived secret from GitHub and enables more granular cloud-side authorization. It does not make a compromised deployment job harmless. If the job has id-token: write and the cloud trust policy accepts its repository, branch, environment, audience, and other claims, code running in that job may be able to request the same short-lived session. OIDC must therefore be combined with narrow cloud roles, restrictive trust conditions, protected environments, and separation between untrusted build activity and privileged deployment activity.

Self-hosted runners expand the trust boundary

GitHub-hosted runners are provisioned as clean, ephemeral virtual machines for jobs. Self-hosted runners do not automatically provide that same clean-room guarantee. A persistent runner can contain deployment tools, cached credentials, SSH material, mounted sockets, internal DNS access, or routes to private services. An affected action may therefore threaten more than the repository. Sensitive self-hosted workloads should use strong isolation, minimal network access, dedicated runner groups, clean images, and preferably ephemeral just-in-time execution.

5. A vulnerable release workflow

The following fictitious workflow is intentionally unsafe. It combines mutable action references, broad repository permissions, a publishing token, and the build and release operations in one job.

name: Vulnerable release example

on:
  push:
    tags:
      - "v*"

permissions: write-all

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Check out source
        uses: actions/checkout@v6

      - name: Build with a third-party helper
        uses: octo-org/release-helper@v1
        env:
          PACKAGE_TOKEN: ${{ secrets.DEMO_PACKAGE_TOKEN }}

      - name: Publish package
        run: ./scripts/publish.sh

Several small conveniences combine into one high-impact path:

• actions/checkout@v6 follows a major tag rather than an exact reviewed commit.
• octo-org/release-helper@v1 is fictitious, but it represents any third-party build or release action followed by a movable tag.
• permissions: write-all grants every available GITHUB_TOKEN permission at its write level where supported, instead of naming the few capabilities required.
• DEMO_PACKAGE_TOKEN is placed in the same job as the third-party helper.
• The build helper can influence files that the next step publishes.
• Creating a tag starts the process automatically, so a routine release supplies the trigger.

The exploit does not require a pull request against this repository. If the upstream v1 reference changes, the next release can load that changed code without a local diff. Code review in the application repository sees the workflow that was approved months ago, not necessarily the action implementation executing today.

6. Safe local demonstration: one tag, two behaviors

This lab models the essential reference behavior with local Git repositories. It creates an approved action, tags it v1, runs that tag, commits a harmless changed action, force-moves v1, and runs the same tag again. It finally runs the original full commit SHA to show that the pinned selection still resolves to the reviewed behavior.

• Requires Bash and Git.
• Creates files only under ~/sunimod-mutable-action-lab.
• Refuses to overwrite that path if it already exists.
• Contacts no network service and uses the reserved address lab@example.invalid.
• Writes one harmless marker file only inside the second cloned repository.
• Does not delete the lab automatically, so you can inspect every commit and file.

Save the following file as mutable_action_lab.sh.

#!/usr/bin/env bash
set -Eeuo pipefail

LAB_ROOT="${HOME}/sunimod-mutable-action-lab"
UPSTREAM="${LAB_ROOT}/upstream-action"
FIRST_RUN="${LAB_ROOT}/run-by-tag-before"
SECOND_RUN="${LAB_ROOT}/run-by-tag-after"
PINNED_RUN="${LAB_ROOT}/run-by-sha"

if [[ -e "${LAB_ROOT}" ]]; then
  printf 'Refusing to overwrite existing path: %s\n' "${LAB_ROOT}" >&2
  exit 2
fi

mkdir -p "${UPSTREAM}"
git -C "${UPSTREAM}" init --quiet
git -C "${UPSTREAM}" config user.name "Sunimod Local Lab"
git -C "${UPSTREAM}" config user.email "lab@example.invalid"

cat > "${UPSTREAM}/action.sh" <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail
printf 'action_behavior=approved\n'
EOF
chmod 0755 "${UPSTREAM}/action.sh"
git -C "${UPSTREAM}" add action.sh
git -C "${UPSTREAM}" commit --quiet -m "Approved action release"
git -C "${UPSTREAM}" tag v1
APPROVED_SHA="$(git -C "${UPSTREAM}" rev-parse HEAD)"

run_ref() {
  local label="$1"
  local ref="$2"
  local destination="$3"

  git clone --quiet "${UPSTREAM}" "${destination}"
  git -c advice.detachedHead=false -C "${destination}" checkout --quiet "${ref}"
  printf '\n=== %s ===\n' "${label}"
  printf 'requested_ref=%s\n' "${ref}"
  printf 'resolved_commit=%s\n' "$(git -C "${destination}" rev-parse HEAD)"
  (
    cd "${destination}"
    ./action.sh
  )
}

run_ref "First run through mutable tag" "v1" "${FIRST_RUN}"

cat > "${UPSTREAM}/action.sh" <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail
printf 'action_behavior=changed-upstream\n'
printf 'Harmless local marker: changed code executed.\n' > changed-code-ran.txt
printf 'harmless_marker=%s\n' "$(pwd)/changed-code-ran.txt"
EOF
chmod 0755 "${UPSTREAM}/action.sh"
git -C "${UPSTREAM}" add action.sh
git -C "${UPSTREAM}" commit --quiet -m "Changed upstream action"
git -C "${UPSTREAM}" tag --force v1 >/dev/null
CHANGED_SHA="$(git -C "${UPSTREAM}" rev-parse HEAD)"

printf '\n=== Upstream reference changed ===\n'
printf 'v1_before=%s\n' "${APPROVED_SHA}"
printf 'v1_after=%s\n' "${CHANGED_SHA}"

run_ref "Second run through the same mutable tag" "v1" "${SECOND_RUN}"
run_ref "Pinned run through the original commit" "${APPROVED_SHA}" "${PINNED_RUN}"

printf '\nLocal-only lab complete. No network service or external repository was contacted.\n'
printf 'Review files under %s, then remove that directory manually.\n' "${LAB_ROOT}"

Run it from a terminal:

chmod 0755 mutable_action_lab.sh
./mutable_action_lab.sh

A tested run produces the following shape. Commit identifiers and your home-directory path will differ:

=== First run through mutable tag ===
requested_ref=v1
resolved_commit=9d54324fecb8e2122ce61696c8fedc97a77a267f
action_behavior=approved

=== Upstream reference changed ===
v1_before=9d54324fecb8e2122ce61696c8fedc97a77a267f
v1_after=9daae22d9fee4465455dc7b7aa505438076e0bd6

=== Second run through the same mutable tag ===
requested_ref=v1
resolved_commit=9daae22d9fee4465455dc7b7aa505438076e0bd6
action_behavior=changed-upstream
harmless_marker=/home/demo/sunimod-mutable-action-lab/run-by-tag-after/changed-code-ran.txt

=== Pinned run through the original commit ===
requested_ref=9d54324fecb8e2122ce61696c8fedc97a77a267f
resolved_commit=9d54324fecb8e2122ce61696c8fedc97a77a267f
action_behavior=approved

Local-only lab complete. No network service or external repository was contacted.

What the lab proves

The requested selector is v1 in both tag-based runs. The first run resolves to the approved commit. After the tag moves, the second run resolves to a different commit and executes changed behavior. The pinned run requests the original full SHA and continues to execute the approved behavior.

The consumer did not need to edit a workflow, accept a pull request, or change an application commit. Only the upstream mapping from v1 to a commit changed. That is the trust gap a mutable action reference creates.

What the lab does not prove

The demonstration does not model GitHub account compromise, secret access, malicious exfiltration, a real release, or cloud deployment. It also does not prove that every moved tag is hostile. It isolates one technical fact: a stable reference name can select different executable code over time.

After reviewing the files, remove the exact lab directory using your normal file-management process. Confirm the path before deleting anything.

7. How to audit your own workflows

Begin with an authorized repository inventory rather than an internet-wide search. Review every workflow under .github/workflows, every local action under .github/actions, and every organization-level reusable workflow or policy that can be called by those files.

Use a read-only reference scanner

The following script inventories remote uses: entries that are not pinned to a full 40-character hexadecimal commit SHA. It ignores local actions and docker:// image references because those require different review logic. Run it from the root of a repository you are authorized to inspect.

Save it as audit_github_actions_refs.py.

#!/usr/bin/env python3
"""Flag remote GitHub Actions references that are not full commit SHAs."""

from __future__ import annotations

import re
import sys
from dataclasses import dataclass
from pathlib import Path

WORKFLOW_DIR = Path(".github/workflows")
USES_LINE = re.compile(
    r"^\s*(?:-\s*)?uses:\s*(?P<quote>['\"]?)(?P<reference>[^'\"#\s]+)(?P=quote)\s*(?:#.*)?$"
)
FULL_SHA = re.compile(r"^[0-9a-fA-F]{40}$")


@dataclass(frozen=True)
class Finding:
    path: Path
    line_number: int
    reference: str
    reason: str


def classify(reference: str) -> str | None:
    if reference.startswith(("./", "docker://")):
        return None
    if "@" not in reference:
        return "remote action or workflow is missing an @ selector"

    _, selector = reference.rsplit("@", 1)
    if FULL_SHA.fullmatch(selector):
        return None
    return f"selector is not a full 40-character commit SHA: {selector}"


def scan_file(path: Path) -> list[Finding]:
    findings: list[Finding] = []
    for line_number, line in enumerate(
        path.read_text(encoding="utf-8", errors="replace").splitlines(),
        start=1,
    ):
        match = USES_LINE.match(line)
        if match is None:
            continue
        reference = match.group("reference")
        reason = classify(reference)
        if reason is not None:
            findings.append(Finding(path, line_number, reference, reason))
    return findings


def main() -> int:
    if not WORKFLOW_DIR.is_dir():
        print(f"Workflow directory not found: {WORKFLOW_DIR}", file=sys.stderr)
        return 2

    workflow_files = sorted(
        {
            *WORKFLOW_DIR.rglob("*.yml"),
            *WORKFLOW_DIR.rglob("*.yaml"),
        }
    )
    findings = [
        finding
        for path in workflow_files
        for finding in scan_file(path)
    ]

    if not findings:
        print("No unpinned remote uses: references were found.")
        return 0

    for finding in findings:
        print(
            f"{finding.path}:{finding.line_number}: "
            f"{finding.reference} -> {finding.reason}"
        )
    print(f"\nFound {len(findings)} reference(s) requiring review.")
    return 1


if __name__ == "__main__":
    raise SystemExit(main())

Run the audit:

python3 audit_github_actions_refs.py

Example output:

.github/workflows/release.yml:18: actions/checkout@v6 -> selector is not a full 40-character commit SHA: v6
.github/workflows/release.yml:22: octo-org/release-helper@v1 -> selector is not a full 40-character commit SHA: v1
.github/workflows/deploy.yml:31: octo-org/automation/.github/workflows/deploy.yml@main -> selector is not a full 40-character commit SHA: main

Found 3 reference(s) requiring review.

An exit status of 1 means the script found references requiring review. An exit status of 0 means it found no unpinned remote uses: references in the files it scanned. An exit status of 2 means the workflow directory was not found.

Build a privilege-aware inventory

For every remote action and reusable workflow, record:

• The complete uses: value, selected SHA, and human-readable release or tag.
• The actual upstream repository and evidence that the commit originated there rather than only being reachable through a fork relationship.
• The maintainer or vendor, license, support status, last review date, and business owner.
• Every workflow trigger, especially pull-request, issue, schedule, tag, manual, reusable-workflow, and privileged follow-up triggers.
• The job-level GITHUB_TOKEN permissions and any organization or repository defaults.
• Secrets, OIDC permissions, cloud roles, package registries, signing systems, and deployment environments available to the job.
• The runner type, network reachability, persistent storage, caches, mounted sockets, and other workloads sharing the infrastructure.
• Artifacts, outputs, caches, or images the action can create for later privileged jobs.
• The approved update process and the person responsible for responding when the upstream project publishes a security fix.

Prioritize by executable privilege

Not every finding deserves the same response time. A useful order is:

1. Production deployment, package publication, signing, release creation, infrastructure modification, and workflows with cloud or organization credentials.
2. Workflows on persistent self-hosted runners or runners with access to internal services.
3. Jobs with broad write permissions, repository secrets, environment secrets, or the ability to alter artifacts consumed later.
4. Public-repository workflows influenced by untrusted pull requests, issue content, comments, branch names, or artifacts.
5. Read-only test and lint jobs on clean hosted runners.

A low-privilege unpinned action is still technical debt, but the first remediation effort should follow the paths that can change production, publish trusted software, or expose durable credentials.

8. How to harden the release path

The strongest design does not rely on one control. It prevents silent dependency drift, reduces the privileges available during execution, separates untrusted work from privileged work, and preserves enough evidence to verify what was built.

Pin every remote executable dependency

Pin third-party actions, GitHub-owned actions, and remote reusable workflows to verified full-length commit SHAs. Keep the reviewed tag or release in a same-line comment so a human can understand the intended version and an update tool can propose a controlled change.

# Mutable references: convenient, but resolved again on later runs.
- uses: octo-org/release-helper@v1
- uses: octo-org/release-helper@v1.4.2

# Immutable selector: illustrative only; replace it with a verified SHA.
- uses: octo-org/release-helper@0123456789abcdef0123456789abcdef01234567 # v1.4.2

The SHA above is a fictitious, non-resolving example. A production pin must be copied from the intended upstream repository after source and release review. Confirm that the commit is actually associated with that repository, not merely addressable through a related fork. When updating, review the change between the old and new SHAs before merging.

Where the platform and plan support it, enforce an organization or enterprise policy that rejects actions and reusable workflows not pinned to a full SHA. Policy turns a convention into a reliable guardrail and prevents one rushed workflow edit from silently restoring mutable references.

Declare the smallest job permissions

Set permissions: {} at the workflow level, then grant only the permissions each job requires. GitHub’s workflow syntax sets unspecified permissions to none once any explicit permission is declared. A build job may need only contents: read. A release job may need contents: write or packages: write, but those privileges should not be inherited by linting, testing, or third-party setup steps without a demonstrated need.

Do not use write-all as a convenience baseline. Permission errors are valuable design feedback: they reveal which operation actually needs authority and where that authority should live.

Separate build from deployment

Build software without production credentials. Transfer a narrowly defined artifact to a separate deployment job that references a protected environment. This creates a place for required review, branch restrictions, deployment history, and environment-specific secrets or OIDC trust.

The following is a structural example, not a copy-ready workflow. Every repeated-digit SHA is intentionally fictitious and must be replaced with a verified upstream commit. Provider-specific login inputs and the artifact handoff must be adapted to the real platform.

name: Hardened release pattern

on:
  workflow_dispatch:

permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Check out source
        uses: actions/checkout@1111111111111111111111111111111111111111
        with:
          persist-credentials: false

      - name: Build without deployment credentials
        run: ./scripts/build.sh

      - name: Upload release candidate
        uses: actions/upload-artifact@2222222222222222222222222222222222222222
        with:
          name: release-candidate
          path: dist/
          if-no-files-found: error

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Download release candidate
        uses: actions/download-artifact@3333333333333333333333333333333333333333
        with:
          name: release-candidate
          path: dist/

      - name: Obtain a short-lived cloud session
        uses: octo-org/cloud-login@4444444444444444444444444444444444444444
        with:
          audience: https://cloud.example.invalid

      - name: Deploy the approved candidate
        run: ./scripts/deploy.sh

This pattern improves the trust boundary in several ways:

• The workflow starts with no token permissions.
• The build job receives read-only repository access and no production cloud credential.
• Every remote action is represented by a full-length selector.
• The deployment job waits on the build and references the production environment.
• Only the deployment job can request an OIDC token.
• The cloud session can be short-lived and constrained to the protected environment.

Separation does not automatically prove the artifact is clean. The build job still creates the candidate. Add artifact integrity checks, provenance, review gates appropriate to the business, and a deployment process that verifies exactly what it is about to release.

Use restrictive OIDC trust

Replace durable cloud keys with OIDC where the provider supports it, then restrict the provider-side trust policy. The provider’s syntax differs, but the decision should normally bind the session to the intended organization, repository, environment or branch, audience, and role. The following JSON is only a conceptual set of expected claims for the fictitious repository octo-org/example-app:

{
  "issuer": "https://token.actions.githubusercontent.com",
  "audience": "https://cloud.example.invalid",
  "subject": "repo:octo-org/example-app:environment:production"
}

Do not implement this as an unconditional trust of GitHub’s issuer. A broad subject match can allow an unintended repository, branch, pull-request context, or environment to request the same role. Grant the cloud role only the API actions and resources the deployment requires, and remove the old long-lived key after the OIDC path has been tested.

Protect workflow files and updates

Workflow YAML is production code. Use branch protection or rulesets, require review, and assign explicit owners for workflow and local-action directories. GitHub’s CODEOWNERS feature can require designated reviewers when the surrounding branch-protection rules are configured accordingly.

.github/workflows/ @octo-org/platform-owners @octo-org/security-reviewers
.github/actions/   @octo-org/platform-owners @octo-org/security-reviewers

Automated update tooling can open pull requests when action releases change. It should not merge privileged workflow updates blindly. Treat each pin update as a dependency change: verify the new commit, review the source diff, confirm release notes and maintainer identity, run tests, and assess whether permissions or network behavior changed.

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

Record and verify build provenance

Provenance connects an artifact to the repository, workflow, commit, environment, and event that produced it. Artifact attestations can make that claim verifiable, but only when the consumer or deployment process actually verifies it. An attestation is evidence about origin; it is not a guarantee that the source or build instructions were secure.

The action pin below is again fictitious. Replace it with the verified commit for the approved attestation action.

permissions:
  contents: read
  id-token: write
  attestations: write

steps:
  - name: Attest the release artifact
    uses: actions/attest@5555555555555555555555555555555555555555
    with:
      subject-path: dist/example-app.tar.gz

A consumer or deployment gate can then verify the artifact against the expected repository identity:

gh attestation verify dist/example-app.tar.gz --repo octo-org/example-app

Verification should fail closed when the artifact, repository identity, signer, workflow, or other required property does not match policy. Retain artifact hashes and attestation records with the release evidence.

Isolate runners and network access

Use clean hosted runners when they meet the workload’s needs. When self-hosting is necessary, prefer ephemeral or just-in-time runners built from a known image, segregate runner groups by trust level, remove unnecessary credentials and tools, block access to unrelated internal networks, and monitor outbound connections. Never treat a shared persistent runner as a neutral computer after it has executed untrusted code.

Avoid privileged untrusted-code paths

Review triggers and data flow as carefully as action pins. A perfectly pinned action can still be used unsafely if a privileged workflow checks out untrusted pull-request code, evaluates attacker-controlled strings in a shell, trusts an artifact from an unprivileged workflow without validation, or combines review automation with production secrets. Pinning protects dependency identity; it does not repair unsafe workflow logic.

9. Potential repercussions for your business or infrastructure

The technical event is “a trusted automation job executed upstream code the business did not approve.” The business consequence depends on the job’s authority, runner, data, and position in the release path.

Severity should be based on evidence. A mutable tag in a read-only documentation workflow is not equivalent to a mutable tag in a production deployment job. Conversely, a workflow that “only builds” may still be critical when customers install its artifact or a later privileged job deploys that artifact automatically.

10. How to respond to suspected compromise

If a trusted action reference is reported compromised, resolves to an unexpected commit, or appears to have executed unauthorized behavior, treat the workflow as an incident boundary. Do not assume that pinning the reference after the fact reverses actions already taken.

1. Stop new execution. Disable or restrict the affected workflows, cancel active runs where appropriate, block the action or version through platform policy, and pause releases or deployments that consume suspect artifacts.
2. Preserve essential evidence. Retain the workflow YAML at the affected commit, run IDs, job and step logs, timestamps, trigger payloads, resolved action commits, audit logs, artifacts, hashes, attestations, package versions, release records, and relevant cloud or registry logs. Capture self-hosted runner disk or memory evidence when your response plan and expertise support it. Do not delay urgent containment to collect perfect evidence.
3. Establish the exposure window. Determine when the upstream reference changed, which workflow runs resolved the changed commit, which branches or tags triggered those runs, and which artifacts, deployments, or packages they produced.
4. Map actual privileges. Reconstruct the job’s token permissions, explicit secrets, OIDC trust, cloud role, registry access, signing ability, runner network access, workspace contents, and downstream artifact consumers.
5. Revoke and rotate exposed authority. The job’s GITHUB_TOKEN is temporary, but any actions taken with it remain. Revoke package tokens, personal access tokens, deploy keys, cloud credentials, signing access, webhooks, vendor API keys, or sessions that were available or cannot reasonably be excluded from exposure. Review whether OIDC-issued sessions or cloud-side changes need separate revocation or rollback.
6. Contain the dependency. Remove the action, pin a verified known-good commit, or replace it with a reviewed local or alternative implementation. Do not pin the currently resolved SHA merely because it is exact; first determine whether that commit is trusted.
7. Validate repositories and control planes. Review repository settings, branch rules, workflow files, tags, releases, deploy keys, GitHub Apps, organization secrets, package records, cloud audit logs, IAM changes, and deployment histories for unauthorized modification.
8. Quarantine suspect outputs. Withdraw or mark affected releases, packages, containers, installers, and artifacts. Compare hashes with known-good outputs where reproducible builds or prior evidence exist. Notify downstream owners not to deploy or install the suspect versions.
9. Rebuild from a known-good boundary. Use reviewed source, a clean runner image, newly issued credentials, verified action pins, controlled dependencies, and a hardened workflow. Generate and verify fresh provenance before restoring normal release activity.
10. Coordinate the business response. Involve leadership, legal counsel, privacy, cyber insurance, communications, customer support, vendors, and customers according to the evidence, contracts, data involved, and applicable jurisdictions.

Use resolved-commit evidence, not only workflow text

The workflow file answers what selector was requested. Incident scoping also needs the exact commit that was resolved for each run. A mutable selector can point to several commits across the exposure window. Preserve platform logs and metadata early, compare them with upstream reference history and release records, and avoid treating today’s tag target as proof of what ran last week.

11. Build a durable governance model

This problem returns when remediation is treated as a one-time search-and-replace. The sustainable solution assigns ownership to executable workflow dependencies throughout adoption, operation, update, retirement, and incident response.

Use measurable controls

Useful internal measures include:

• Percentage of remote actions and reusable workflows pinned to verified full SHAs.
• Percentage of workflows with explicit top-level and job-level token permissions.
• Number of jobs carrying long-lived cloud, package, or signing credentials.
• Percentage of production deployments gated by a protected environment.
• Percentage of cloud deployments using narrowly scoped OIDC instead of stored keys.
• Number of persistent self-hosted runners executing code influenced by untrusted users.
• Percentage of release artifacts with retained hashes, provenance, and verification results.
• Time between an upstream action update and a reviewed pin-update decision.
• Number of workflow dependencies without a named business or technical owner.

These are management indicators, not universal compliance thresholds. Set targets based on the organization’s release frequency, customer commitments, data sensitivity, platform capabilities, and risk tolerance.

Make safe updates routine

SHA pinning creates an intentional update decision. That decision must not become permanent neglect. Use automated pull requests to surface updates, schedule review capacity, prioritize security fixes, test updates in a lower environment, and preserve the ability to roll back. The goal is controlled change, not frozen dependencies.

12. A solvable Sunimod service: CI/CD workflow trust and release integrity review

For a business that uses GitHub Actions to test, package, publish, or deploy a website, application, integration, internal tool, or customer-facing service, this is a finite engineering problem. The work can be scoped repository by repository and prioritized by the paths that can change production or distribute trusted software.

Sunimod can help turn the findings into an implementable project rather than a generic scanner report. A practical engagement can include:

• An inventory of third-party actions, reusable workflows, downloaded build tools, package registries, runners, and deployment destinations.
• A trust map showing triggers, action selectors, token permissions, exposed secrets, OIDC roles, artifacts, and downstream systems.
• Verification and full-SHA pinning of approved action commits, with readable version comments and an update process.
• Job-level permission reduction and separation of build, release, and production deployment responsibilities.
• Migration from long-lived cloud credentials to narrowly scoped OIDC where the provider and workload support it.
• Protected environments, workflow ownership, review rules, allowed-action policy, and automated dependency-update configuration.
• Runner isolation recommendations for hosted, self-hosted, ephemeral, and internal-network workloads.
• Artifact hashing, provenance, attestation, and verification patterns appropriate to the release process.
• An incident runbook for upstream action compromise, credential rotation, artifact withdrawal, clean rebuild, and business coordination.
• Implementation support, tested workflow changes, and documentation that explains why each control exists.

The deliverable should answer business questions as clearly as technical ones: Which release paths can affect customers? Who owns each dependency? What can a compromised build step reach? Which changes must stop a deployment? What evidence would let the company prove which artifact was released?