fix(ci): harden workflow permissions

docs/openssf-assurance.md

@@ -35,26 +35,40 @@ Scorecard `v5.5.0` or later.
 - **Purpose:** create the GitHub release after publishing the verified packages and release artifacts.
 - **Owner:** repository maintainer.
 - **Validation evidence:** workflow YAML parsed successfully and a manual permission-boundary inspection on 2026-07-22 confirmed that `build-and-test` remains `contents: read`, while all publishing write scopes remain on `publish`.
-- **Exit criterion:** remove this authority when a narrower GitHub release-creation permission or a changed release design makes it unnecessary, or record a fresh Scorecard result that confirms resolution. Until then, alert #13 is an open, justified residual signal—not a resolved alert.
+- **Exit criterion:** remove this authority when a narrower GitHub release-creation permission or a changed release design makes it unnecessary, or record a fresh Scorecard result that confirms resolution. The fresh result below confirms resolution of the reported finding; this boundary record remains as the rationale for any future change.
+
+## External verification — 2026-07-22
+
+- **Scorecard source:** [GitHub code-scanning alerts](https://github.com/Scetrov/FrontierSharp/security/code-scanning)
+- **Observation time:** 2026-07-22T20:29:38Z (the latest `updated_at` reported for these alerts)
+- **Alert #13:** `TokenPermissionsID`, `fixed`
+- **Alert #14:** `TokenPermissionsID`, `fixed`
+- **Alert #15:** `TokenPermissionsID`, `fixed`
+
+This is a fresh observed service result, not an inference from the workflow edits. Alert #13's former required publishing scope remains documented above; the service now reports all three Token-Permissions alerts fixed.
+
+- **Best Practices source:** [`projects/13670.json`](https://www.bestpractices.dev/projects/13670.json)
+- **Public record updated:** 2026-07-22T20:53:33.357Z
+- **Badge level:** `passing` (Passing 100%, Silver 11%, Gold 17%)
+- **Submission and processing evidence:** the public record advanced from its 2026-07-20 `in_progress` snapshot after the truthful root `.bestpractices.json` evidence was submitted through the supported project flow. The service-reported record is authoritative for the result.
+- **Remaining required criteria:** none indicated for Passing. The record still has six `Unmet` status fields, which are outside the service-reported Passing threshold and are not represented as satisfied.
+- **README verification:** the badge link remains [`projects/13670`](https://www.bestpractices.dev/projects/13670), matching the service-reported Passing project.
 
-Alerts #14 and #15 are separate open TokenPermissionsID findings pending a fresh Scorecard analysis after the scoped `prerelease.yml` and `sync-release-notes.yml` changes. No TokenPermissionsID alert is claimed resolved without that fresh result.
 
 ## Best Practices baseline — 2026-07-21
 
 - **Project:** [FrontierSharp 13670](https://www.bestpractices.dev/projects/13670)
 - **Source:** [`projects/13670.json`](https://www.bestpractices.dev/projects/13670.json)
 - **Downloaded:** 2026-07-21
 - **Public record updated:** 2026-07-20T16:05:52.114Z
-- **Badge status:** `in_progress` (Passing 94%, Silver 7%, Gold 17%)
+- **Badge status at this baseline:** `in_progress` (Passing 94%, Silver 7%, Gold 17%)
 
-The downloaded record contains 196 criterion status fields: 45 `Met`, 13
+This historical snapshot contained 196 criterion status fields: 45 `Met`, 13
 `N/A`, 9 `Unmet`, 128 unknown (`?`), and one unsupported numeric value
-(`OSPS-BR-01.02_status: 0`). The `Met`, `N/A`, and `Unmet` entries are the
-currently answered inventory; unknown and unsupported entries are not claims.
-The public record includes both legacy Best Practices criteria and newer OSPS
-fields. Any repository automation input must use only keys and values accepted
-by the service at submission time, and must retain unknown criteria as unknown
-or omit them.
+(`OSPS-BR-01.02_status: 0`). The `Met`, `N/A`, and `Unmet` entries were the
+then-current answered inventory; unknown and unsupported entries were not
+claims. See the 2026-07-22 external verification above for the authoritative
+post-submission result.
 
 ## ClusterFuzzLite compatibility assessment — 2026-07-21
 
@@ -135,11 +149,13 @@ functioning, proven AFL++ integration and does not claim detection success.
 
 - **Local file:** `.bestpractices.json` at root
 - **Public record:** [project 13670](https://www.bestpractices.dev/projects/13670)
-- **Badge status:** `in_progress` (Passing 94%, Silver 7%, Gold 17%)
+- **Badge status at this evidence snapshot:** `in_progress` (Passing 94%, Silver 7%, Gold 17%)
 - **Criteria included:** 67 answerable (45 Met, 13 N/A, 9 Unmet)
 - **Unknown criteria:** 128 omitted (not fabricated)
 - **Mismatch with public record:** 0
 
+The later service result is recorded in the 2026-07-22 external verification above; this section deliberately preserves the pre-submission inventory.
+
 The local evidence file uses the documented criterion key naming convention,
 preserves the public project's truthful status values, and includes
 repository-local evidence URLs for all answerable Met and N/A criteria.

openspec/changes/harden-workflow-permissions/tasks.md → openspec/changes/archive/2026-07-22-harden-workflow-permissions/tasks.md

@@ -9,10 +9,10 @@
 
 - [x] 2.1 Validate workflow syntax and inspect the affected jobs to confirm each release, tag, changelog, package, OIDC, and PR-label operation retains exactly its required permission.
 - [x] 2.2 Update `docs/openssf-assurance.md` with alert #13's required scope, trusted trigger boundary, owner, validation evidence, and exit criterion; distinguish it from resolved alerts.
-- [ ] 2.3 Trigger or await a fresh Scorecard analysis and record the resulting status of alerts #13, #14, and #15 without claiming an unobserved result.
+- [x] 2.3 Trigger or await a fresh Scorecard analysis and record the resulting status of alerts #13, #14, and #15 without claiming an unobserved result.
 
 ## 3. Verify the Best Practices outcome
 
-- [ ] 3.1 Submit the existing truthful `.bestpractices.json` evidence through the supported Best Practices flow for project 13670.
-- [ ] 3.2 Retrieve the public project record after processing and record its timestamp, badge level, and any remaining required criteria in assurance evidence.
-- [ ] 3.3 Verify the README Best Practices badge continues to resolve to project 13670 and reflects the service-reported status.
+- [x] 3.1 Submit the existing truthful `.bestpractices.json` evidence through the supported Best Practices flow for project 13670.
+- [x] 3.2 Retrieve the public project record after processing and record its timestamp, badge level, and any remaining required criteria in assurance evidence.
+- [x] 3.3 Verify the README Best Practices badge continues to resolve to project 13670 and reflects the service-reported status.

openspec/specs/repository-security-governance/spec.md

@@ -88,3 +88,36 @@ The repository SHALL record enough non-sensitive evidence to reproduce verificat
 - **WHEN** GitHub, Scorecard, or bestpractices.dev has not yet processed a merged assurance change
 - **THEN** the repository records the pending state and does not fabricate a successful score, badge level, or criterion result
 
+### Requirement: Automation write authority is least-privilege
+GitHub Actions workflows SHALL use a read-only workflow-level permission baseline. A job SHALL declare a write permission only when that job performs the corresponding repository, release, package, identity-token, or pull-request operation, and the declaration SHALL contain no unrelated write scopes.
+
+#### Scenario: A workflow includes both read-only and release operations
+- **WHEN** a workflow contains a job that reads source code and a different job that creates a release, tag, changelog commit, package, or pull-request label
+- **THEN** only the job that performs each write operation receives its corresponding write permission
+
+#### Scenario: A new job is added to an affected workflow
+- **WHEN** a maintainer adds a job without an explicit permissions declaration
+- **THEN** the job receives only the workflow's read-only baseline and no inherited write authority
+
+### Requirement: Necessary publishing authority is an auditable residual risk
+When trusted main-branch publishing requires `contents: write` to create a GitHub release, the repository SHALL keep that authority isolated to the publishing job and SHALL record its alert identifier, purpose, trigger boundary, owner, validation evidence, and exit criterion in assurance evidence. The record MUST NOT characterize the alert as resolved unless the permission is removed or a fresh scanner result confirms resolution.
+
+#### Scenario: Main publishing creates a GitHub release
+- **WHEN** the trusted publishing job creates the project's GitHub release after a successful main-branch build
+- **THEN** it receives `contents: write` only at that job boundary and retains only the other write scopes required for its existing publication operations
+
+#### Scenario: Scorecard continues to flag the publishing permission
+- **WHEN** a fresh Scorecard analysis reports the Token-Permissions alert for the scoped publishing job
+- **THEN** assurance evidence identifies it as a justified residual signal with an owner and exit criterion rather than falsely claiming it is fixed
+
+### Requirement: Best Practices badge submission is externally verified
+The maintainer SHALL submit truthful repository evidence through the supported Best Practices flow for project 13670 and SHALL record the resulting service timestamp, badge level, and any unmet required criteria. The repository MUST NOT claim a Passing badge until bestpractices.dev reports it.
+
+#### Scenario: Best Practices awards Passing
+- **WHEN** bestpractices.dev reports a Passing badge for project 13670 after evidence submission
+- **THEN** assurance evidence records the reported timestamp and badge level, and the README badge continues to resolve to that project
+
+#### Scenario: Best Practices remains in progress
+- **WHEN** bestpractices.dev does not award Passing after evidence submission
+- **THEN** assurance evidence records the actual `in_progress` result and the outstanding required criteria without modifying repository claims to imply a Passing grade
+