You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pilot for the estate remediation of GitHub Workflow Dependency Locking. See hyperpolymath/standards#657.
Four steps, in this order, because each blocks the next.
1. workflow-linter.yml was unparseable.
permissions: read-allactions: read # <- mapping indented under a scalar
Blind-permissions:-insertion damage. The consequence reaches far past the one file: gh actions-lock refuses to run when ANY workflow in the repo fails to parse, so the repo can never acquire a lockfile, so every workflow that needs one stays dead. One broken file kills the repo.
2. Generated the lockfile with gh actions-lock v0.1.6.
3. The generated lockfile was PARTIAL — 10 of 15. The five omitted are exactly the reusable-workflow callers; the tool emits no entries for them. Hand-added each as '<path>': [].
⚠️ This is the estate-wide trap: a partial lock is worse than none. Measured across 218 repos, P(startup_failure | has lock) = 91.7% vs 15.8% without — because every workflow the lock omits is rejected. Running gh actions-lock and stopping there is how 55 repos got into that state.
4. The tool restamps its banner above line 1, displacing the SPDX header that the workflow-security linter greps with head -1. Restored in 14 files; main-estate-audit.yml had none at all, so one was authored (MPL-2.0, Rule 1 default — a new header, not a relicensing, so A2 is not engaged).
Verified before pushing: 0 unparseable workflows · SPDX on line 1 in 15/15 · lockfile covers 15/15, no omissions.
Follows #82, which repinned the standards callee off a pre-lockfile SHA and removed the other half of the rejection.
Pilot for the estate remediation of GitHub's Workflow Dependency Locking.
Four steps, in this order, because each blocks the next.
1. workflow-linter.yml was UNPARSEABLE:
permissions: read-all
actions: read <- mapping indented under a scalar
This is blind-permissions-insertion damage. Consequence beyond the one
file: `gh actions-lock` refuses to run at all when ANY workflow in the
repo fails to parse, so the repo can never acquire a lockfile, so every
workflow needing one stays dead. One broken file kills the repo.
2. Generated the lockfile with gh actions-lock v0.1.6.
3. The generated lockfile was PARTIAL - 10 of 15 workflows. The five it
omitted are exactly the reusable-workflow callers (governance,
hypatia-scan, mirror, scorecard, secret-scanner); the tool does not
emit entries for them. Hand-added each as '<path>': [].
This matters estate-wide: a PARTIAL lock is worse than none. Measured
across 218 repos, P(startup_failure | has lock) = 91.7% vs 15.8%
without, because every workflow the lock OMITS is rejected. Running
gh actions-lock and stopping there is how 55 repos got into that state.
4. The tool restamps its own banner ABOVE line 1, displacing the SPDX
header, which the workflow-security linter greps with head -1.
Restored SPDX to line 1 in 14 files; main-estate-audit.yml had none at
all, so one was authored (MPL-2.0, Rule 1 default - new file header,
not a relicensing, so LICENCE-POLICY A2 is not engaged).
Verified before pushing: 0 unparseable workflows, SPDX on line 1 in
15/15, lockfile covers 15/15 with no omissions.
Follows the callee repin in #82, which removed the other half of the
rejection (the standards reusable at a pre-lockfile SHA).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Updated automated workflows to use current, clearly identified action versions.
Standardised workflow management markers across automation, security scanning, auditing, and deployment processes.
Improved workflow permission declarations for clearer access control.
Added licensing metadata where applicable.
No build, deployment, or job behaviour was changed.
Walkthrough
The pull request updates GitHub Actions references across multiple workflows, adds gh actions-lock management comments, adds one SPDX header, and makes workflow permissions explicit.
Changes
Workflow maintenance
Layer / File(s)
Summary
Update action references .github/workflows/*.yml
Third-party actions now use release tags instead of commit SHA references. Updated actions include checkout, CodeQL, Pages, caching, setup, repository dispatch, and email notification actions.
Add workflow metadata and permissions .github/workflows/*.yml
Management comments were added to workflows. main-estate-audit.yml now has an SPDX header. workflow-linter.yml now grants explicit contents: read and actions: read permissions.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR addresses workflow syntax errors and introduces an actions.lock file to manage dependency pinning. While the YAML structure is now valid and SPDX headers are standardized, the repository is currently not up to standards according to Codacy analysis.
A critical gap exists: the 'Check pinned actions' step in the security linter will fail because it is not configured to recognize the actions.lock strategy. It currently flags any version tag that lacks a trailing SHA comment as a security violation. Furthermore, several actions handling sensitive credentials (SMTP and repository tokens) are still using mutable version tags in the workflow files, which should be pinned to immutable commit SHAs to ensure supply-chain security.
About this PR
The repository's custom security linter logic specifically flags version tags that lack a trailing comment. Since this PR removes those comments in favor of an actions.lock file, the 'Check pinned actions' linter step will trigger failures for every updated workflow. The linter logic must be updated to exempt files managed by the actions-lock header.
Test suggestions
Verify workflow-linter.yml and all updated workflows are valid YAML
Verify SPDX header is correctly placed on the first line of all 15 workflows
Verify that actions.lock includes entries for reusable workflow callers
Verify that the 'Check pinned actions' linter step passes with the new tag-pinned format
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that the 'Check pinned actions' linter step passes with the new tag-pinned format
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Pinning peter-evans/repository-dispatch to a SHA is necessary to protect the FARM_DISPATCH_TOKEN. Tags are mutable and do not guarantee that the code will not change in the future.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
This action handles your SMTP credentials and project data. Using a mutable version tag like v3.12.0 is insecure as it can be reassigned. Pinning to a full commit SHA ensures the code remains immutable.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
This change removes the SHA comments that the security linter uses to verify pinned actions. Since you are moving to an actions.lock strategy, the linter's 'Check pinned actions' step will now flag these as unpinned. You should update the linter logic to exempt files that contain the header '# This workflow is managed by gh actions-lock.'
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
This update to a tag-pinned version without a trailing comment will trigger a failure in the 'Check pinned actions' step of this workflow, as the linter specifically looks for tags without comments to identify unpinned dependencies.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pilot for the estate remediation of GitHub Workflow Dependency Locking. See
hyperpolymath/standards#657.Four steps, in this order, because each blocks the next.
1.
workflow-linter.ymlwas unparseable.Blind-
permissions:-insertion damage. The consequence reaches far past the one file:gh actions-lockrefuses to run when ANY workflow in the repo fails to parse, so the repo can never acquire a lockfile, so every workflow that needs one stays dead. One broken file kills the repo.2. Generated the lockfile with
gh actions-lockv0.1.6.3. The generated lockfile was PARTIAL — 10 of 15. The five omitted are exactly the reusable-workflow callers; the tool emits no entries for them. Hand-added each as
'<path>': [].P(startup_failure | has lock) = 91.7%vs15.8%without — because every workflow the lock omits is rejected. Runninggh actions-lockand stopping there is how 55 repos got into that state.4. The tool restamps its banner above line 1, displacing the SPDX header that the workflow-security linter greps with
head -1. Restored in 14 files;main-estate-audit.ymlhad none at all, so one was authored (MPL-2.0, Rule 1 default — a new header, not a relicensing, so A2 is not engaged).Verified before pushing: 0 unparseable workflows · SPDX on line 1 in 15/15 · lockfile covers 15/15, no omissions.
Follows #82, which repinned the
standardscallee off a pre-lockfile SHA and removed the other half of the rejection.🤖 Generated with Claude Code