fix(hypatia): ack the workflow_hardening copy of the lock finding (unblocks red main) - #965
Merged
Merged
Conversation
main has been red since #954 (9c256b6). The round-2 acknowledgement covers the invalid_actions_lock finding as emitted by rule_module "workflow_audit", but Hypatia emits the SAME defect a second time from rule_module "workflow_hardening", carrying file ".github/workflows/actions.lock". scripts/apply-baseline.sh:188 matches rule_module by exact string equality, so one copy was suppressed and the other kept blocking. The file_pattern was never the problem: "**actions.lock" globs to \A.*actions\.lock\z and matches the full path fine. Reproduced locally against main's own committed apply-baseline.sh, schema and baseline, using the finding copied verbatim from the failing run 35716729172: before: kept=1 suppressed=0 ::error::Gate failed: 1 unfiltered finding(s) at or above 'high'. exit=1 after: kept=0 suppressed=1 exit=0 Four negative controls confirm the new entry suppresses only this exact finding - a critical-severity copy, a different rule_module, a different type, and a non-lock file are all still KEPT (kept=4). Suites: apply-baseline-test.sh 15/0, filter-sarif-by-baseline-test.sh 13/0, hypatia-blocking-gate-test.sh 4/4. The exposure is unchanged and is NOT newly accepted here: asana/push- signed-commits@d615 (immutable pin, ref v1.3) declares transitive actions/setup-python@v2, which floats upstream and can never be a lock key. gh-actions-lock v0.1.6 verify says valid:true on the same file. The exit remains #951's: Asana pins setup-python, we replace the action, or Hypatia downgrades float-transitives. Ratchet-exception: .hypatia-baseline.json -- second module emitting an already-acknowledged finding; this documents the existing #951 debt at its second emission site rather than accepting new debt. Entry count 211 -> 212, exposure unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR
Contributor
|
Warning Review limit reachedNext included review available in 37 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
4 tasks
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
hyperpolymath
deleted the
fix/hypatia-baseline-workflow-hardening-ack
branch
September 22, 2026 10:53
|
4 tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.



mainis red, and round 2 only half-landedmainhas been red on both Hypatia checks since #954 (9c256b67) —scan / Hypatia Neurosymbolic Analysisandgovernance / Validate Hypatia Baseline. Every PR opened since inherits it, including #961.The cause is not the lockfile. It is that one defect is emitted by two rule modules, and round 2 acknowledged only one of them.
rule_moduleworkflow_auditworkflow_hardeningfileactions.lock.github/workflows/actions.locktypeinvalid_actions_lockinvalid_actions_lockseverityhighhighreasonscripts/apply-baseline.sh:188matches by exact string equality:The
file_patternwas never the problem.**actions.locktokenises to\A.*actions\.lock\z, which matches the full path correctly.Evidence
Reproduced locally against main's own committed
apply-baseline.sh, schema and baseline, using the finding copied verbatim from the failing run 35716729172:The
beforeline is byte-identical to what CI printed.Four negative controls confirm the entry suppresses only this exact finding — all four stay
KEPT:criticalrule_module: some_other_moduletype: unpinned_actionon the same file.github/workflows/release.ymlSuites, all green on this branch:
apply-baseline-test.sh15/0 ·filter-sarif-by-baseline-test.sh13/0 ·hypatia-blocking-gate-test.sh4/4. Full pre-commit hookset passes.Exemption ratchet, both directions:
The mutant was a throwaway branch, asserted and deleted — the gate has teeth here, it is not being taken on trust.
What this does not do
It does not accept new exposure. The underlying risk is unchanged and still owned by #951:
asana/push-signed-commits@d615(immutable pin, refv1.3) declares a transitiveactions/setup-python@v2, which floats upstream and can never be a lock key.gh-actions-lockv0.1.6verifyreportsvalid:trueon the same file — Hypatia is stricter than the authoritative tool. The exits remain exactly #951's: Asana pinssetup-python, we replace the action, or Hypatia downgrades float-transitives.The diff is +9 / −0, a pure append. No existing entry is touched.
Follow-up worth considering (not in this PR)
One triage decision now needs two baseline entries that differ in a single field, and nothing warns you when you write only one — which is precisely how
mainwent red. Lettingrule_moduleaccept a list would make one decision one entry. That is a schema +apply-baseline.sh+ test change, so it is deliberately out of scope here; filing separately.🤖 Generated with Claude Code
https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR