TrustScope: suggested Security & Supply Chain improvements for trustscope

[GmanFooFoo]

Hi! This is a friendly, optional set of suggestions for neckarshore-mmps/trustscope, generated by TrustScope from the OpenSSF Scorecard (v5.5.0).

None of these are required — they are common hardening steps that tend to raise a project's supply-chain and governance signals. Take whatever is useful and ignore the rest.

Security & Supply Chain

• Branch Protection — Add a branch-protection rule: require a pull request, a required status check, and dismiss-stale reviews. (Private repositories need a paid GitHub plan for branch protection.)
• Code Review — Require review before merge. Solo projects can satisfy this with an automated reviewer (e.g. CodeRabbit) instead of blocking human approval.
• Token Permissions — Add a top-level least-privilege permissions: block to each workflow file (contents: read, with per-job write scopes only where needed). Scorecard reads the workflow file itself, not the org default setting.
• Vulnerabilities — Enable CI dependency-vulnerability scanning (an npm audit gate plus Dependabot) and triage the open advisories.

---

Assessed via TrustScope (https://trustscope.neckarshore.ai) — an open-source trust report by Neckarshore AI. These are suggestions, not demands.

[GmanFooFoo]

Follow-up on two of the four generic categories above, with the exact root cause and fix — found via a live OpenSSF Scorecard re-run against origin/main this morning (pinned to the same build v5.1.1-45-g40bbc9c9 used by the 2026-07-06 baseline run, so the numbers are comparable). Live aggregate right now: 5.5, down from 7.1 on 2026-07-06.

Token Permissions: 10 → 0 (the one-line fix)

Cause: .github/workflows/dependabot-auto-merge.yml carries a top-level

permissions:
  contents: write
  pull-requests: write

introduced by #64 (2026-07-10) for the auto-merge job. Scorecard flags this as a repo-wide over-grant regardless of intent.

Fix: drop the top-level block to permissions: { contents: read } and move the two write scopes down to the dependabot-auto-merge job only.

Verified in a throwaway clone (git archive of origin/main, candidate change applied, never pushed to this repo): scorecard's Token-Permissions check goes 0 → 10 with this change. e2e.yml's job-level contents: write does not cap the check — that was the open question that made measuring necessary rather than assuming.

DoD for whoever picks this up:

GITHUB_AUTH_TOKEN=$(gh auth token) docker run --rm -e GITHUB_AUTH_TOKEN \
  gcr.io/openssf/scorecard:stable --repo=github.com/neckarshore-mmps/trustscope \
  --checks=Token-Permissions --format=json

must return 10. Pin the build to v5.1.1-45-g40bbc9c9 (or check whatever :stable currently resolves to against that tag) — comparability to the 7.1 baseline depends on it.

Expected effect: aggregate 5.5 → 6.3.

Vulnerabilities: 10 → 0 (separate, slower)

17 open GHSAs against unchanged dependencies (Scorecard's OSV-based check, not the same signal as GitHub's Dependabot alerts UI) — accumulated over 20 days with zero commits to the repo. Not a one-line fix; needs real triage of which advisories have available patches. Tracked here as the second half of the regression, not addressed by the Token-Permissions change above.

Cross-referenced from planning-repo session report 2026-07-26-maschin-planning.md, where this was originally measured.

[GmanFooFoo]

Categories 1–3 worked, 2026-07-28 — measured at a pinned build

Every number below was produced with Scorecard pinned by digest to the same build every other
number in this estate was produced at. Without that pin a before/after pair proves nothing:

gcr.io/openssf/scorecard@sha256:54c7ea4ddec6e3941887cb7933898c352f59e7f59e17a7a730f97ed348a8dfce
GitVersion: v5.1.1-45-g40bbc9c9   GitCommit: 40bbc9c958

Important: this issue was generated by the TrustScope product at v5.5.0; the numbers here are
at v5.1.1-45. They are not interchangeable, and no number from either should be published without
naming its version. Reconciling the two rulers is not resolved here.

---

The baseline moved before any work started

Re-measured first, because three Dependabot PRs merged overnight. Live aggregate is 5,9, not the
5,5 measured on 2026-07-26. Vulnerabilities went 0 → 6: 4 open advisories, down from 17.

Category 1 — Token Permissions: 0 → 10 ✅

.github/workflows/dependabot-auto-merge.yml carried contents: write + pull-requests: write at
workflow level. Scorecard caps this check at 0 for the entire repository on any top-level write.
Both scopes now sit on the job that needs them; the workflow default is contents: read. Effective
job permissions are unchanged.

Measured by git archive-ing origin/main into two throwaway trees and running scorecard --local
against both — the repo itself was never written to during measurement. 0 before, 10 after.

This also settles the question that made measuring necessary: e2e.yml:212 carries a job-level
contents: write, so it was unclear whether the fix would reach 10 or merely leave 0. Job-level
writes are a Warn, not a cap. Both remaining warns are job-level and the check still scores 10.

→ PR #128

Categories 2 and 3 are one decision, not two — and the answer is no

The work order treats Branch-Protection as "one setting" and Code-Review as "measure before
investing." On the ground they are the same lever. All three Branch-Protection gaps —

Warn: branch 'main' does not require approvers
Warn: codeowners review is not required on branch 'main'
Warn: 'last push approval' is disabled on branch 'main'

— require at least one approving review to exist. So does Code-Review. There is one lever here.

Two things were measured rather than argued:

1. Comment reviews do not count. Code-Review reads "Found 0/24 approved changesets". Five of
   the last fifteen merged PRs (a11y(light): WCAG-AA contrast pass — marketing + report pages #108, ci(guard): catch glued words in rendered output — JSX entity whitespace collapse #114, chore(pwg): fail-closed persona-write-guard hook (#813) #117, feat(style-guide): internal design-system reference + discreet footer link #121, fix(report): stop leaking internal error detail to anonymous visitors (claude-security F2/F3) #122) carry CodeRabbit reviews — every one of
   them COMMENTED, never APPROVED. The check still reads 0. That is the second half of this
   issue's open question, answered from data already on the ground.
2. No approving review has ever been issued on this repo, by anyone — bot or human — across the
   fifteen merged PRs checked.

And pulling the lever would lock the repository, not merely slow it. enforce_admins is true,
so an admin cannot bypass branch protection, and GitHub does not permit a PR author to approve their
own pull request. Setting required_approving_review_count: 1 would therefore make every
self-authored PR unmergeable on a repo that ships from a single pair of hands, with no approving
reviewer available to unblock it.

That is not an oversight to be corrected. This repo's own .coderabbit.yaml states the position in
writing as an estate standard: "it advises, it never gates merges … Branch protection does NOT
require its approval — a solo repo stays self-mergeable."

Decision, 2026-07-28: the ceiling is accepted and published rather than bought. Configuring the
bot to approve would satisfy the gate with a reviewer that always says yes — a check that looks like
review and is not one. For a product that sells trust grades, "we did not buy this point because
buying it would have made the review a prop" is the more defensible sentence than one extra point.

Branch-Protection stays at 4. Code-Review stays at 0. Categories 2 and 3 are answered, not open.

A finding nobody had: part of the gap is not for sale

Maintained scores 0, reason: "project was created in last 90 days". That is repository age,
not a defect and not a regression — and it carries the same 7,5 weight as Token-Permissions. It
resolves itself with time and no amount of work moves it sooner.

Where the number actually stands

Weights validated first by reproducing the measured 5,9 exactly from the 16 applicable per-check
scores, then used for the projections:

State	Aggregate
measured today	5,9
+ Token-Permissions (PR #128)	6,7
+ Vulnerabilities fully cleared	7,1
+ Maintained ageing in	7,9

Category 4 (Vulnerabilities, 4 open) is the only remaining buyable item and is not a one-liner.

[GmanFooFoo]

Correction — the live number is 6,8, not the 6,7 I projected

PR #128 merged at 07:40:51Z. Re-measured against production main, same pinned digest:

Token-Permissions: 10  ("GitHub workflow tokens follow principle of least privilege")
aggregate:         6,8

A per-check diff against this morning's baseline confirms Token-Permissions was the only check that moved — 0 → 10, everything else byte-identical. So the aggregate moved 5,9 → 6,8.

My comment above projected 6,7. That figure was arithmetic, and it came in 0,1 low.

The projection method was sound in shape — reproduce the measured aggregate from the per-check scores first, only then use the weights — and it did reproduce 5,9 exactly. But reproducing one rounded value does not pin the weights tightly enough to project a second one to a tenth. At least one weight in my table is slightly off, and I have not isolated which.

Consequence for anything downstream: the two remaining projections in the comment above — 7,1 with Vulnerabilities cleared and 7,9 with Maintained aged in — rest on the same model and carry the same ±0,1 uncertainty. They are directionally right and should not be quoted as precise. Any number that goes into public copy gets measured on the day, not projected. That was already this work order's rule for the Scorecard version; it applies to the arithmetic too.

The measured facts are unaffected: 0 → 10 on Token-Permissions, and 5,9 → 6,8 live.