Is your feature request related to a problem? Please describe.
The releaseWorkflowsMustNotRestoreUntrustedCache control (ISSUE-705) flags release-triggered jobs that restore a cache, and its message suggests scoping the cache key (and restore-keys) to the release ref. That remediation is only actionable when the workflow uses actions/cache directly, where the key is user-controlled.
A large share of real-world hits come from the setup actions' built-in caching instead: actions/setup-node with cache: npm, actions/setup-go, actions/setup-python and similar. Those actions compute their cache keys internally (platform + lockfile hash) and expose no input to scope the key to a ref. For these hits the suggested fix cannot be applied. The only real options are turning the cache off on the publish path or restructuring to a raw actions/cache step, and the message says neither.
The practical consequence: repos that accept the residual risk for now have no way to acknowledge one specific job, so they disable the whole control in .plumber.yaml, which also silences future, unrelated 705 findings in other workflows.
Describe the solution you'd like
Two improvements, independently useful:
-
Detection-aware remediation text. When the flagged restore comes from a setup action's cache: input rather than actions/cache, the finding message should say so and suggest the applicable fixes: disable the cache on release triggers (cache: false or dropping the input), or move to an explicit actions/cache step with a ref-scoped key. The rule already knows which action produced the restore, so this is a message-level change.
-
Per-job acknowledgment. Allow the control to accept a scoped exemption instead of a global enabled: false:
Configuration in .plumber.yaml
controls:
releaseWorkflowsMustNotRestoreUntrustedCache:
enabled: true
acknowledgedJobs:
- workflow: release.yml
job: publish
reason: "npm cache via setup-node, removal planned"Findings on acknowledged jobs would report as acknowledged (visible, zero points lost or a reduced malus, whichever fits the scoring model) while any new 705 hit elsewhere still fails the gate.
Implementation Hints
- Data source: the IR already distinguishes the action reference producing the cache restore (the rule needs the action owner/name of the flagged step, which the collector has).
- Logic: same detection, branch only on the source action family for the message; the acknowledgment list is config plumbing plus a match in the Rego rule.
- Severity + ISSUE code: unchanged (ISSUE-705, High).
- Default state: message change is unconditional;
acknowledgedJobs defaults to empty.
Why It's Valuable
Cache poisoning on publish paths is a real attack vector, and the control is right to flag it. But an unactionable remediation pushes users toward the bluntest response available, disabling the control entirely, which is strictly worse for them and hides future regressions. Detection-aware guidance plus scoped acknowledgment keeps the control on in exactly the repos that hit this most, the ones using the setup actions' ergonomic caching.
Is your feature request related to a problem? Please describe.
The
releaseWorkflowsMustNotRestoreUntrustedCachecontrol (ISSUE-705) flags release-triggered jobs that restore a cache, and its message suggests scoping the cache key (and restore-keys) to the release ref. That remediation is only actionable when the workflow usesactions/cachedirectly, where the key is user-controlled.A large share of real-world hits come from the setup actions' built-in caching instead:
actions/setup-nodewithcache: npm,actions/setup-go,actions/setup-pythonand similar. Those actions compute their cache keys internally (platform + lockfile hash) and expose no input to scope the key to a ref. For these hits the suggested fix cannot be applied. The only real options are turning the cache off on the publish path or restructuring to a rawactions/cachestep, and the message says neither.The practical consequence: repos that accept the residual risk for now have no way to acknowledge one specific job, so they disable the whole control in
.plumber.yaml, which also silences future, unrelated 705 findings in other workflows.Describe the solution you'd like
Two improvements, independently useful:
Detection-aware remediation text. When the flagged restore comes from a setup action's
cache:input rather thanactions/cache, the finding message should say so and suggest the applicable fixes: disable the cache on release triggers (cache: falseor dropping the input), or move to an explicitactions/cachestep with a ref-scoped key. The rule already knows which action produced the restore, so this is a message-level change.Per-job acknowledgment. Allow the control to accept a scoped exemption instead of a global
enabled: false:Configuration in
.plumber.yamlFindings on acknowledged jobs would report as acknowledged (visible, zero points lost or a reduced malus, whichever fits the scoring model) while any new 705 hit elsewhere still fails the gate.
Implementation Hints
acknowledgedJobsdefaults to empty.Why It's Valuable
Cache poisoning on publish paths is a real attack vector, and the control is right to flag it. But an unactionable remediation pushes users toward the bluntest response available, disabling the control entirely, which is strictly worse for them and hides future regressions. Detection-aware guidance plus scoped acknowledgment keeps the control on in exactly the repos that hit this most, the ones using the setup actions' ergonomic caching.