Repository navigation
feat(security): prepare base policy for trusted SARIF reporting - #180
Draft
richards-ensono wants to merge 2 commits into
Draft
richards-ensono wants to merge 2 commits into
richards-ensono wants to merge 2 commits into
Conversation
The authoritative workflow policy runs from the protected base revision during pull_request_target, so a pull request cannot authorize the permissions or pins its own workflows introduce. Land the allowances first, in a change that is valid against the current topology. Two allowances are added. A non-executing workflow_run SARIF reporter becomes acceptable as the only pull-request-scoped holder of security-events: write: an envelope that forbids caches, secrets, containers and pull-request checkout, a protected-main validator, an artifact download bound to the resolved provenance, and a pinned uploader bound to the verified ref and revision. It is accepted when present but not required, so the pull request that starts producing the artifact makes it mandatory. The SonarCloud scanner pin becomes a list of reviewed SHAs rather than a single value. Pinning exactly one SHA makes every scanner upgrade unmergeable, because the base checker rejects the pin the pull request introduces; this is why an automated bump cannot currently pass. The successor pin is reviewed here and the superseded entry is removed by the change that performs the upgrade. Only explicitly reviewed SHAs are accepted, and each must still be an immutable 40-character SHA. The provenance body is pinned by digest rather than by matching substrings of shell text, following the existing convention for reviewed inline scripts. Steps are matched by action identity, step id and position rather than by display name, and job permissions stay asserted only in the existing permission table, so renaming a step can neither fail validation nor disguise a change of trust boundary. Tests cover one case per invariant: tampered provenance, provenance not scoped to the upstream run, unverified upload ref or revision, a checkout_path inside a Git worktree, alternate or unpinned upload actions, permission elevation, pull-request checkout, post-download command execution, an untrusted validator, secret exposure, scanner pin supersession, and the regression that any job executing pull-request content is refused security-events: write.
|
richards-ensono
marked this pull request as draft
October 2, 2026 08:29
This branch has not been deployed
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.



Summary
workflow_runSARIF reporter topology; preserve the current read-only lint workflow.Landing order
First of four: this policy-only change must land before the pinned action bump, reporter workflow, and PR #179. No SARIF producer or write-enabled workflow is introduced here.
Verification
The real protected-base checker was exercised locally against this branch before publication. Please review the trust boundary and wait for the protected-base workflow-policy check before merging.