[rgarcia]

Workflows now reference exact action releases (vX.Y.Z) and .github/workflows/actions.lock holds the commit for each one. Previously they used full SHA pins with version comments, plus a few floating refs (@v4, @master) that only the lockfile held in place.

Workflow refs

• Regenerated with gh actions-lock (narrowing on). gh actions-lock --verify passes (all 13 workflows valid).
• Every narrowed ref locks the same commit as before. Each old SHA pin, and each old lockfile commit for a floating ref, equals the new lockfile commit:

Before	After	Commit
actions/checkout@11bd719…	v4.2.2	11bd719
actions/checkout@34e1148…	v4.3.1	34e1148
actions/checkout@11d5960…, @v4	v4.4.0	11d5960
actions/create-github-app-token@d72941d…	v1.12.0	d72941d
actions/upload-artifact@ea165f8…, @v4	v4.6.2	ea165f8
actions/download-artifact@d3f86a1…, @v4	v4.3.0	d3f86a1
actions/setup-node@49933ea…	v4.4.0	49933ea
actions/setup-go@40f1582…	v5.6.0	40f1582
actions/setup-python@a26af69…	v5.6.0	a26af69
oven-sh/setup-bun@0c5077e…	v2.2.0	0c5077e
aws-actions/configure-aws-credentials@7474bc4…	v4.3.1	7474bc4
aws-actions/amazon-ecr-login@03f1aad…	v2.1.7	03f1aad
aquasecurity/trivy-action@master (container-scan)	@38b337f… (full SHA)	38b337f

• aquasecurity/trivy-action stays a full SHA everywhere. 38b337f has no release tag, and a plain gh actions-lock run rewrites it to @master. container-scan.yml used @master and now uses the same SHA as container-remediation.yml.
  • After any future gh actions-lock run, check that trivy-action is still the SHA. The tests below fail if it becomes @master.
• The semgrep.yml step kernel/security-workflows/.github/actions/llm-credentials@main is unchanged. Regenerating moved its lock from 56bdfc0 to af49085, and the action's files are identical between those commits.
• The breakglass-merge.yml comment now says the lockfile pins the app-token action.

Tests

• test_container_remediation.py and test_vuln_remediation_workflow.py no longer require 40-character SHAs. Each uses: must now be:
  • an exact vX.Y.Z tag, or
  • a full SHA whose lockfile ref is not a release tag (an untagged commit), or
  • $/.
• It must also have an actions.lock entry for that exact ref under that workflow. The shared check is in scripts/action_pins.py.
• The llm-credentials exception, persist-credentials, permissions and every other check are unchanged.
• A new test covers the rejected cases: floating tag, branch, unlocked tag, and a SHA that has a release tag.
• Both test workflows now also run when actions.lock or scripts/action_pins.py changes.

Semgrep rule

• The registry rule github-actions-mutable-action-tag (from p/github-actions) only accepts SHAs, so it would flag every exact-tag line in every repo that calls semgrep.yml.
• semgrep.yml now excludes that rule and runs a copy written inline in the scan step. The copy also allows exact vX.Y.Z tags and $/ actions. It still flags floating tags (@v4, @v4.4), branches (@main), and prerelease tags. Its message points to the lockfile.
• I checked it locally with semgrep 1.185.0 on a fixture: the registry rule flagged @v4.4.0 and $/, and the replacement flags only the floating and branch refs. test_semgrep_triage.py checks the rule's allow/flag cases.
• Because the rule ID changes, this repo's own semgrep self-test may report the llm-credentials@main lines as new findings.

Not covered

Job-level reusable workflow calls (the self-tests calling ./.github/workflows/*.yml, and callers referencing kernel/security-workflows/...@main) aren't covered by the lockfile. The mirror.gcr.io/semgrep/semgrep container image isn't covered either.