Skip to content

feat(security): prepare base policy for trusted SARIF reporting - #180

Draft
richards-ensono wants to merge 2 commits into
mainfrom
security/prepare-base-policy
Draft

richards-ensono wants to merge 2 commits into
mainfrom
security/prepare-base-policy

Conversation

@richards-ensono

Copy link
Copy Markdown
Contributor

Summary

  • Pre-authorize only the non-executing trusted workflow_run SARIF reporter topology; preserve the current read-only lint workflow.
  • Pre-approve the reviewed successor SonarCloud scanner SHA while keeping immutable pin enforcement.
  • Add negative policy fixtures for provenance, permissions, untrusted execution, and action identity.

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.

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
richards-ensono requested a review from a team September 29, 2026 10:47
@sonarqubecloud

Copy link
Copy Markdown

@richards-ensono
richards-ensono marked this pull request as draft October 2, 2026 08:29

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant