ci(security): phase-1 CI hardening — affected-area tests, least privilege, action pinning, dependency governance (#336 )

* ci(security): run deterministic eval tests in affected-area CI (Task 04)

The build-check job validated build + suite structure but never ran the
tests, and its summary referenced a `test:ci` script that did not exist.
Make affected-area CI meaningful:

- Add `test:ci` to evals/framework running the offline, deterministic
  Vitest allowlist (7 files / 112 tests) — no model, network, or paid
  execution.
- Add a required "Run deterministic tests" step to build-check; a failure
  fails the job and the existing PR summary gate (which keys on
  build-check.result) fails closed.
- Correct the summary note to state test:ci runs the deterministic
  allowlist and that model/network agent suites are excluded on PRs.

The broader deterministic suite has 3 pre-existing failing files
(framework-confidence, logger, test-runner; confirmed failing before this
work) which are intentionally out of the allowlist and tracked separately.

Validated locally: build, validate:suites:all, and test:ci all exit 0.

* ci(security): least privilege permissions + pin actions to SHAs (Task 05)

Harden all 9 GitHub Actions workflows:

Least privilege:
- Add explicit top-level `permissions: contents: read` to installer-checks,
  validate-test-suites, and opencode (opencode's job keeps the writes it
  needs; the top level now defaults to read).
- Every workflow now declares an explicit top-level permissions block.
- Write scopes retained only where justified (releases, doc/registry
  commits, follow-up PRs, and sync-docs' issues.create).

Immutable action pinning:
- Pin every `uses:` to a full 40-char commit SHA with a version comment,
  including first-party actions/* (checkout, github-script, setup-node,
  upload-artifact) and third-party (oven-sh/setup-bun).
- Replace the two mutable refs that could change under us at any push:
  ludeeus/action-shellcheck@master and sst/opencode/github@latest.

Record all SHAs, versions, and permission justifications in
docs/maintenance/repository-recovery/action-pin-inventory.md.

Verified: all 9 workflows parse as valid YAML; no floating tag/branch refs
remain; every workflow has a top-level permissions block.

* docs(security): add SECURITY.md and private-reporting checklist (Task 06)

- Add root SECURITY.md: supported versions (0.7.x), private reporting via
  GitHub's "Report a vulnerability", best-effort response expectations,
  coordinated disclosure, and no-secret guidance.
- Add private-vulnerability-reporting checklist that separates repository
  file work (this PR) from GitHub settings changes that require their own
  approval (Task 07: enabling private vulnerability reporting).

No external links to validate; the reporting path uses the repo Security
tab. SECURITY.md documents the private reporting path ahead of Task 07
enabling it.

* ci(security): add dependency governance and ownership controls (Task 08)

- .github/dependabot.yml: weekly grouped github-actions updates (keeps the
  Task 05 SHA pins current). Scoped to actions only — the primary lockfile
  is bun.lock and Dependabot's npm ecosystem would desync it; npm
  dependency risk is covered by dependency-review below.
- .github/workflows/dependency-review.yml: runs on PRs with contents: read,
  SHA-pinned actions, fail-on-severity: high to block newly introduced
  high-severity vulnerabilities (exceptions documented inline).
- .github/CODEOWNERS: default owner @darrenhinde with explicit ownership of
  security-sensitive paths (workflows, dependabot, CODEOWNERS, SECURITY.md,
  scripts/validation).

Verified: dependabot.yml and dependency-review.yml are valid YAML;
dependency-review actions are SHA-pinned with contents: read; CODEOWNERS
owner is the repository owner.

* docs(security): record GitHub security settings evidence (Task 07)

Enable private vulnerability reporting and record read-back evidence.

Settings changed (each approved immediately before, verified by read-back):
- Private vulnerability reporting: enabled=false -> enabled=true. The
  Security tab now offers "Report a vulnerability", making the path
  documented in SECURITY.md live.
- Dependency Graph / Dependabot alerts: 404 -> 204. This was an
  undocumented prerequisite of Task 08's dependency-review.yml, which
  failed with "Dependency graph is not enabled"; the Dependency Review
  check on PR #336 went fail -> pass after enabling it.

No other repository setting was modified; secret scanning and push
protection are unchanged, and dependabot_security_updates remains disabled
(out of scope, would need its own approval). Both changes are reversible
via the corresponding DELETE calls.

Marks Part B of the private-vulnerability-reporting checklist complete.

2026-07-15 00:19:28 +01:00

1.9 KiB

Raw Permalink Blame History

Security Policy

Supported Versions

Security fixes are provided for the latest released minor version. Older versions are not maintained; please upgrade before reporting.

Version	Supported
0.7.x	✅
< 0.7	❌

Reporting a Vulnerability

Please do not report security vulnerabilities through public GitHub issues, pull requests, or discussions.

Report vulnerabilities privately through GitHub's built-in private vulnerability reporting:

Go to the repository's Security tab.
Select Report a vulnerability.
Provide a clear description, affected versions, reproduction steps, and potential impact.

This opens a private advisory visible only to the maintainers and to you.

What to include

The affected component and version.
Steps to reproduce, or a proof of concept.
The impact you believe the issue has.

What not to include

Do not include real secrets, credentials, API keys, or access tokens in your report. If a secret has been exposed, say so and rotate it — do not paste its value.

Response Expectations

This project is maintained on a best-effort basis. Reports are reviewed and addressed as maintainer availability allows; there is no guaranteed response time. We will engage with the private advisory as we triage and work on a fix.

Coordinated Disclosure

We follow coordinated disclosure. Please give the maintainers a reasonable opportunity to investigate and release a fix before disclosing the issue publicly. We will coordinate the timing and content of any public disclosure with you through the private advisory.

Scope

This policy covers the code in this repository. Vulnerabilities in third-party dependencies should be reported to the respective upstream projects; if a dependency issue affects this project specifically, you may still report it here so we can track remediation.

1.9 KiB Raw Permalink Blame History