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
Remediates GitHub Workflow Dependency Locking (public preview, no changelog entry), which rejects runs at startup_failure — zero jobs, no logs, nothing in REST or GraphQL. Full analysis: hyperpolymath/standards#657.
Proven on hyperpolymath/anamnesis: 6 of 6 workflows dead → 0 startup_failure, 13 running.
Five steps, in order — each blocks the next
1. Unbreak the workflow YAML. Any permissions: carrying a scalar with an indented mapping under it:
permissions: read-allactions: read # <- mapping under a scalar. Unparseable.
This reaches 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 and can never self-heal.
2. Repin standards reusables off commits with no actions.lock. The rejection requires the callee to be covered at the pinned SHA — unsatisfiable at a pre-lockfile commit.
3. Generate the lockfile with gh actions-lock.
4. Hand-add the reusable-caller entries the tool omits, as '<path>': [].
⚠️ Measured across 218 repos: P(startup_failure | has lockfile) = 91.7% vs 15.8% without — because every workflow a lockfile omits is rejected. A partial lock is worse than none. Running gh actions-lock and stopping there is how this outage spread.
5. Restore SPDX-License-Identifier to line 1, which the tool displaces with its own banner and which the workflow-security linter greps via head -1.
Verified before this PR was opened
0 unparseable workflows · lockfile covers every workflow, no omissions · SPDX on line 1 in every file. The script refuses to push if any of the three fails.
Remediates GitHub Workflow Dependency Locking (public preview), which
rejects runs at startup_failure with zero jobs and no logs. See
hyperpolymath/standards#657.
Five steps, in order, because each blocks the next:
1. Unbroke any workflow whose `permissions:` carried a scalar with an
indented mapping under it - blind-permissions-insertion damage. This
matters beyond the one file: gh actions-lock refuses to run when ANY
workflow in the repo fails to parse, so the repo could never acquire a
lockfile and could never self-heal.
2. Repinned hyperpolymath/standards reusables off commits that have no
actions.lock. The rejection requires the CALLEE to be covered at the
pinned SHA, which is unsatisfiable at a pre-lockfile commit.
3. Generated the lockfile with gh actions-lock.
4. Hand-added the reusable-workflow caller entries the tool omits, as
'<path>': []. Measured across 218 repos: P(startup_failure | has
lockfile) = 91.7% vs 15.8% without, because every workflow a lockfile
OMITS is rejected. A PARTIAL lock is worse than none - running
gh actions-lock and stopping there is how this outage spread.
5. Restored SPDX-License-Identifier to line 1, which the tool displaces
with its own banner and which the workflow-security linter greps with
head -1.
Verified before push: 0 unparseable workflows, lockfile covers every
workflow with no omissions, SPDX on line 1 in every file.
Proven on hyperpolymath/anamnesis: 6 of 6 workflows dead -> 0
startup_failure, 13 running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
While this PR successfully addresses several YAML parsing issues and establishes a standard for workflow metadata, it introduces significant security regressions and logic flaws that should prevent merging in its current state. Most notably, three workflows have been moved from secure commit SHA pinning to mutable semver tags, increasing the risk of tag-floating attacks—especially concerning for workflows handling sensitive secrets and credentials.
Additionally, the Codacy analysis indicates the PR is not up to standards. A logic error in the Secret Scanner workflow's permission block effectively disables required permissions for the job, and the 'actions.lock' file mentioned in the PR description is entirely missing from the diff. These gaps must be addressed to ensure the CI pipeline is truly 'unbroken' and secure.
About this PR
The critical '.github/workflows/actions.lock' file is excluded from the diff, preventing verification of the 'complete lock' claim or the manual additions described in the PR description.
1 comment outside of the diff[REDACTED:HIGH_ENTROPY]
line 23 🟡 MEDIUM RISK
Suggestion: This workflow uses 'actions/checkout@v4.4.0', which is inconsistent with the v6.0.2 standard being applied to other workflows in this PR. Consider updating this to match the repository baseline.
Test suggestions
Verify that all workflows are parseable by the GitHub Actions engine (no YAML syntax errors in permissions).
Verify that 'actions.lock' contains entries for all 13 workflows mentioned in the description.
Verify that the security linter correctly identifies the SPDX license on the first line of all modified files.
Verify that reusable workflow calls succeed with the newly added 'actions: read' permission.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that all workflows are parseable by the GitHub Actions engine (no YAML syntax errors in permissions).
2. Verify that 'actions.lock' contains entries for all 13 workflows mentioned in the description.
3. Verify that the security linter correctly identifies the SPDX license on the first line of all modified files.
4. Verify that reusable workflow calls succeed with the newly added 'actions: read' permission.
Low confidence findings
There are no automated tests or linting steps added in this PR to ensure that future workflow changes maintain the SPDX-on-line-1 requirement or lockfile completeness.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The 'actions: read' permission added at the top level is shadowed by the job-level 'permissions' block on line 16. Since other reusable workflows in this PR were updated to include 'actions: read', it is likely the 'scan' job also requires it. You should explicitly add 'actions: read' to the job-level block on line 17.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Suggestion: Pinning third-party actions to a full commit SHA is required to ensure the integrity of code processing sensitive information like the 'FARM_DISPATCH_TOKEN'. Moving to a semver tag (v4.0.1) represents a loss of immutability.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Suggestion: Pinning third-party actions to a full commit SHA is a security requirement to ensure immutability. The current use of a semver tag (v2.11.0) is vulnerable to tag-floating attacks. The diff indicates this workflow previously used SHAs.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Suggestion: Pinning third-party actions to a full commit SHA is a security requirement to ensure the immutability of the code being executed. This is critical for actions handling sensitive credentials (like SMTP secrets). Reverting from a SHA to a semver tag (v3.12.0) is a regression from the project's security standards.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Suggestion: The version of 'actions/checkout' used here (v7.0.1) is inconsistent with most other workflows in the repository (e.g., 'boj-build.yml') which were updated to v6.0.2. Consider standardizing to ensure a predictable CI environment.
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.
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
Remediates GitHub Workflow Dependency Locking (public preview, no changelog entry), which rejects runs at
startup_failure— zero jobs, no logs, nothing in REST or GraphQL. Full analysis:hyperpolymath/standards#657.Proven on
hyperpolymath/anamnesis: 6 of 6 workflows dead → 0startup_failure, 13 running.Five steps, in order — each blocks the next
1. Unbreak the workflow YAML. Any
permissions:carrying a scalar with an indented mapping under it:This reaches 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 and can never self-heal.2. Repin
standardsreusables off commits with noactions.lock. The rejection requires the callee to be covered at the pinned SHA — unsatisfiable at a pre-lockfile commit.3. Generate the lockfile with
gh actions-lock.4. Hand-add the reusable-caller entries the tool omits, as
'<path>': [].P(startup_failure | has lockfile) = 91.7%vs15.8%without — because every workflow a lockfile omits is rejected. A partial lock is worse than none. Runninggh actions-lockand stopping there is how this outage spread.5. Restore
SPDX-License-Identifierto line 1, which the tool displaces with its own banner and which the workflow-security linter greps viahead -1.Verified before this PR was opened
0unparseable workflows · lockfile covers every workflow, no omissions · SPDX on line 1 in every file. The script refuses to push if any of the three fails.🤖 Generated with Claude Code