Skip to main content

CC7.1 — Vulnerability detection and remediation

Status: Implemented Owner: Agent #38 (Senior Compliance Lead, SOC 2 + ISO 27001) Last reviewed: 2026-05-28 Next review: 2026-08-28

Trust Services Criteria reference​

To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. The control covers the inbound vulnerability-discovery path (internal research, automated tools, external researcher reports), the triage rubric, the remediation SLA per severity, and the regression-prevention layer.

How ZeroAuth meets this control​

Three discovery channels feed the vulnerability-handling pipeline.

Channel 1: nightly CVE monitor. scripts/cve-monitor.sh (commit f8a756c) runs on a nightly schedule, querying the GitHub advisory database against the dependency tree. A finding at high severity pages the on-call rotation. The fixture-based regression guard tests/cve-monitor.test.ts (also commit f8a756c) plus tests/fixtures/vulnerable-lockfile/ verifies the monitor itself is not drifting silent. Closes audit finding C-14 ("No CVE monitoring; supply-chain attacks invisible until they bite").

Channel 2: sub-agent reviews on every PR. The security-reviewer and cryptographer-reviewer sub-agents (installed at .claude/agents/security-reviewer.md and .claude/agents/cryptographer-reviewer.md) read docs/threat_model.md at session start. Per 06-ways-of-working.md "Sub-agent rules", any PR touching auth, crypto, audit, tenant boundaries, key handling, network ingress, circuits, or contracts is reviewed by the relevant sub-agent. A REQUEST_CHANGES on a PR is the in-cycle vulnerability-discovery signal; the PR is not mergeable until addressed.

Channel 3: external research + bug-bounty. SECURITY.md at the repo root is the GitHub-recognised security-policy file giving an external researcher a single inbox. The bug-bounty programme (compliance roadmap D-Q3-03, target week 27) layers a formal scoped channel with HackerOne / BugCrowd / YesWeHack — the choice is the Phase 3 deliverable. Disclosure timing is 90 days standard with an emergency-disclosure path documented in docs/security/bug-bounty-disclosure-policy.md (lands week 27 alongside the programme).

The triage rubric is the P0/P1/P2/P3 ladder defined at the top of docs/security/audit-findings.md:

  • P0 — production-blocking. Must close before any pilot.
  • P1 — pilot-blocking. Must close before Phase 2 pilot kickoff.
  • P2 — phase 2-blocking. Must close before pilot exit.
  • P3 — phase 3-blocking. Must close before SOC 2 Type II evidence period.

The remediation trail is the canonical artefact. Every Phase 0 finding has a row in audit-findings.md with status + closing commit hash. The 5 P0 closures are visible: C-1 (02e1734), C-3 (ee6aad4), C-7 (e98d158), C-4 (5e3b79d + a475ed8 + d634b2d), C-8 (c09c081). C-2 (mobile fake prover) is tracked-to-Phase-1-Sprint-3 with the closing commit pre-allocated as C-149.

Regression prevention is the closed-finding regression guard. Every closed finding has at least one test that pins the closure; the suite at tests/security/regression.spec.ts (lands C-023 / sprint 2) runs the union of those tests on every PR. Any regression on a closed finding fails the build. Examples wired in today: tests/proof-pairing.test.ts::"P0 audit finding C-1 closure", tests/console-auth.test.ts::"P0 audit finding C-3", tests/zkp-version.test.ts (C-7), tests/audit-chain.test.ts (C-4), tests/biometric-rejection.test.ts (C-8).

For circuit + contract vulnerabilities the external review path is the Trail of Bits / equivalent engagement (compliance roadmap D-Q2-08, weeks 16–24). The external cryptographer engagement (compliance roadmap §6.2, Agent #27 owns) covers the circuit + protocol + trusted-setup ceremony — sign-off letter due week 11.

Threat-model row inventory itself is the vulnerability-class inventory. The opening note instructs every new endpoint / dependency / circuit change to extend the document; the Phase 0 update (commit 573ff5d) added rows A-27, A-28 for the closed demo-bypass + access-token-query findings — demonstrating the pattern.

Evidence references​

  • scripts/cve-monitor.sh (commit f8a756c) — nightly CVE monitor.
  • tests/cve-monitor.test.ts + tests/fixtures/vulnerable-lockfile/ (commit f8a756c) — monitor regression guard.
  • .claude/agents/security-reviewer.md, .claude/agents/cryptographer-reviewer.md — sub-agent review framework.
  • SECURITY.md (repository root) — inbound vulnerability-report channel.
  • docs/security/audit-findings.md — Phase 0 trail with severity rubric + closing commits.
  • Commits 02e1734, ee6aad4, e98d158, a475ed8, d634b2d, c09c081 — P0 + P1 closure trail.
  • Commit 573ff5d — threat-model + audit-findings update on closure.
  • docs/compliance/compliance-roadmap-v1.md D-Q2-08, D-Q2-09 — Trail of Bits engagement.
  • docs/compliance/compliance-roadmap-v1.md D-Q3-03 — bug-bounty programme.

Open gaps + remediation roadmap​

  • Closed-finding regression suite (tests/security/regression.spec.ts) — target C-023 sprint 2 (week 6, 2026-07-06).
  • Bug-bounty programme launch — D-Q3-03, target week 27 (2026-11-16).
  • Trail of Bits smart-contract audit — D-Q2-08 / D-Q2-09, target weeks 24–26.
  • Per-severity remediation SLA documented — explicit hours/days target per severity. Today implicit via Phase exit gates; written SLA target week 14 (2026-08-24).
  • docs/security/bug-bounty-disclosure-policy.md — Phase 3 week 27 deliverable.

Test or audit query​

cat scripts/cve-monitor.sh | head -20 shows the GHSA advisory query. cat tests/cve-monitor.test.ts shows the monitor regression guard. cat docs/security/audit-findings.md | grep -c "CLOSED" returns ≥ 9 closures. cat SECURITY.md shows the disclosure channel.