chore(security): bootstrap sscs-bootstrapper and close the gaps it found

[p4gs]

Update 2026-10-06: Gitleaks is kept alongside TruffleHog, by owner decision. TruffleHog only finds credentials for providers it has a detector for, and with --results=verified,unknown it reports a match only when the provider confirms it live or the verification attempt errors; it drops matches it could not verify, including those from detectors that have no verifier. Gitleaks matches on shape, so it also catches generic secrets such as passwords, internal tokens and keys for services TruffleHog has no detector for. Restored in 1f4133c.

What

First-time sscsb init bootstrap of this repository (47 controls, 32 enabled), plus a fix for every real finding the first sscsb verify produced.

sscsb verify before → after: 23 pass / 3 fail / 3 degraded / 3 info (the first verify run after sscsb init, before any fixes) → 27 pass / 1 fail / 2 degraded / 2 info (at the original bootstrap commit 12094c5, with controls.secrets.gitleaks = false; 15 controls deliberately disabled in both runs). Not re-run since Gitleaks was turned back on in 1f4133c. The signed local scan record committed in 10a0d73 (.sscsb/scan-record.local.json + .sig) was also taken at 12094c5 and still lists gitleaks: disabled in config; it has not been regenerated or re-signed since 1f4133c.

Scanner choice per surface

Surface	Tool	Why
Credentials	TruffleHog + Gitleaks + Trivy's secret scanner (controls.secrets.trufflehog = true, controls.secrets.gitleaks = true; Trivy via vuln-scan.yml's scanners: vuln,secret,misconfig)	TruffleHog only finds credentials for providers it has a detector for, and with --results=verified,unknown it reports a match only when the provider confirms it live or the verification attempt errors; it drops matches it could not verify, including those from detectors that have no verifier. Gitleaks matches on shape, so it also catches generic secrets such as passwords, internal tokens and keys for services TruffleHog has no detector for. Trivy's filesystem scan runs its own built-in secret-detection rules as a third, independent pass, outside the dedicated secrets-scan.yml job. CI runs the MIT-licensed gitleaks binary directly (pinned v8.30.1, checksum-verified before execution), not gitleaks-action, since that action (non-OSS EULA since v2.0.0) refuses to scan org-owned repos without a GITLEAKS_LICENSE key. The key itself is free from gitleaks.io, but none is configured for this org, and running the binary avoids both obtaining the key and the action's license-validation call.
SAST	CodeQL + OpenGrep, both on	Two engines with genuinely different reach: OpenGrep is rule-driven and fast, CodeQL is interprocedural. Both genuinely support this repo's languages (Rust + Actions).

sscsb's secrets-scan.yml template emits a gitleaks-action job. That job was dropped at bootstrap (12094c5) and replaced in 1f4133c by a hand-written job that runs the pinned, checksum-verified gitleaks 8.30.1 binary over the PR/push commit range, with a hand-written .gitleaks.toml ([extend] useDefault = true) as its ruleset. controls.secrets.gitleaks = true also turns Gitleaks back on in the local sscsb pre-commit hook — which passes that same --config .gitleaks.toml — alongside TruffleHog, and in what sscsb verify checks for. The pre-push range scan never read this key: it runs Gitleaks whenever the binary is on PATH, passing no --config flag at all. Gitleaks itself defaults to <target path>/.gitleaks.toml when --config is omitted, and the pre-push scan's target path is the repo root — so it already ran Gitleaks at 12094c5 (under gitleaks' built-in default ruleset, since no .gitleaks.toml existed in the repo yet) while the key was false, and from 1f4133c on it picks up the same .gitleaks.toml ruleset as the CI job and pre-commit hook automatically, with nothing to wire up.

The archived semgrep/semgrep-action@v1 job in security.yml is retired. OpenGrep is Semgrep's open fork and resolves the same registry rulesets, so p/rust and p/security-audit were added to the OpenGrep run: same rule coverage, now on a pinned cosign-verified binary with SARIF uploaded to code scanning. CI on 1f4133c: Ran 19 rules on 63 files: 0 findings (SAST (OpenGrep) run 37414610635).

Findings fixed

1. CODEOWNERS was completely inert. All ten rules named @grcengineering/security, a team that does not exist. GET /repos/grcengineering/cvm/codeowners/errors returned Unknown owner for every line, so no rule bound to anyone — including the branch-protection "require review from Code Owners" path. Rules now name @p4gs and additionally cover the new .sscsb/ policy surface. Swap back if a real, publicly-visible @grcengineering/security team with write access is ever created.
2. deny.toml could not be parsed at all. cargo-deny 0.19.4: error[unexpected-value] ... unmaintained = "warn". The v2 schema turned unmaintained into a scope, and removed vulnerability, unlicensed, copyleft. The deny job — a required status check on main — could therefore never have run. Rewritten to the v2 schema, same intent, and tightened (unmaintained = "all"). cargo deny check now exits 0.
3. Two Renovate config files. sscsb init wrote renovate.json5 next to the pre-existing renovate.json; Renovate aborts with "Found multiple config file names" when both exist. Merged into renovate.json5 (old cool-down rules preserved, isVulnerabilityAlert migrated to the modern vulnerabilityAlerts block); renovate.json deleted.
4. Dockerfile base images were tag-pinned, not digest-pinned. Both cgr.dev/chainguard/rust:latest-dev and cgr.dev/chainguard/static:latest now carry sha256 digests (resolved 2026-09-12).
5. CodeQL analysed actions only — not this workspace's Rust. rust added to the matrix with build-mode: none.
6. release.yml and security.yml were unhardened. harden-runner added to all nine jobs, persist-credentials: false on every checkout, --locked on cargo install.
7. security-insights.yml REPLACE-ME administrator placeholder filled in; reporting channel aligned with SECURITY.md.

Left open, with reasons

• branch-protection — FAIL. main is missing Require signed commits; everything else already passes (required PRs, force-push block, required checks, deletion protection, stale-review dismissal, strict up-to-date). required_approving_review_count is 0 (checked 2026-10-06), so no reviewer-count gate applies here. This is a repo-admin remote write, deliberately not made by an agent. sscsb harden branch-protection --apply is not the fix here — it only edits rulesets, and this repo uses classic branch protection, so its plan output is no ruleset targets this branch — skipped. The one-line fix is:

  gh api -X POST repos/grcengineering/cvm/branches/main/protection/required_signatures

  Three Scorecard sub-gaps (≥1 required approving review, currently 0; code-owner review; last-push approval) need a second reviewer and cannot be satisfied by a solo maintainer.
• signing-model — DEGRADED. Remaining items are account-level attestations only the maintainer can truthfully assert (github-web vigilant mode + phishing-resistant MFA, Codespaces GPG verification, Claude GitHub App authorization). The agent-claude-code lane wants a distinct agent commit identity, which conflicts with this operator's standing one-signer directive — a policy call, not a config gap.
• scorecard — DEGRADED. No published Scorecard results yet; scorecard.yml runs on push to the default branch, so this resolves once this PR lands.

Merge note

main currently requires a PR but 0 approving reviews, with enforce_admins: true (checked 2026-10-06); PR #6 reports mergeStateStatus: CLEAN / mergeable: MERGEABLE, so no reviewer or protection change is needed to merge it. Required signed commits are still missing (see branch-protection above), which remains a repo-admin action.

AI-Assisted: true
AI-Tool: Claude Code
AI-Model: claude-opus-5
AI-Role: draft

🤖 Generated with Claude Code

https://claude.ai/code/session_017N6Qc2T7buVAXHZ9vYa1xm

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.