Harden

harden — dedicated security review

Look at the system the way an attacker would, then report what a defender must fix. This is the focused security pass; inspect covers general quality with a security axis, but a real hardening review deserves its own depth.

Read references/disciplines/security.md — the shared security reference (STRIDE, OWASP Top 10 + LLM Top 10, secrets, abuse cases). Read CONVENTIONS.md for the workspace (§1), the ledger (§2), the resume sweep (§5), git isolation (§11), multi-agent rules (§8), grounding (§14), and freshness (§17 — check current CVEs/advisories against today's date), and workspace integrity (§20).

Step 1 — Scope & threat model

The iron rule: no finding without a reachable path from an attacker to an asset. A checklist item that fails in the abstract is not a finding until you can name who reaches it and what they get. Build the model before auditing, in this order:

1. Assets — what is actually worth stealing or breaking here? Credentials, personal data, money movement, the ability to act as another user, availability. Rank them; the audit's attention follows this list, not the checklist's order.
2. Entry points — every place untrusted input enters: routes and handlers, webhooks, queue consumers, file/image uploads, third-party callbacks, admin surfaces, CLI flags, environment and config. The API is the surface, not the UI — enumerate endpoints from the router, never from the screens.
3. Actors and their starting privilege — anonymous · self-registered user · another tenant's user · low-privilege staff · compromised dependency · someone with a stolen session. For each finding later, you will name which of these can reach it.
4. Trust boundaries — draw the lines where data crosses from one privilege level to another. Every boundary is a place validation and authorization must exist; missing checks cluster there.
5. STRIDE per boundary — spoofing · tampering · repudiation · information disclosure · denial of service · elevation of privilege. Walk the six against each boundary and keep what is concrete for this system.

Load security.md for the checklist that the audit works through.

Step 2 — Audit (read-only)

Work the checklist against the code and config:

• Access control — authz on every route/action, deny-by-default, no IDOR.
• Injection & input — parameterized queries, boundary validation.
• Crypto & secrets — TLS, encryption at rest, strong hashing; no secrets in code/logs (scan the diff).
• Auth & sessions — rate-limited login, safe session/JWT handling.
• Dependencies/supply chain — known-vulnerable packages (web-check current advisories, §17).
• SSRF, deserialization, misconfig, debug endpoints.
• LLM features — prompt injection, unsafe tool permissions, data leakage.

In multi-agent mode, dispatch parallel auditors by category and merge; the orchestrator owns writes (§8). Single-agent: work the checklist inline with fresh eyes.

These thoughts mean stop — you are about to dismiss a real finding:

Dismissing a finding is a decision with the same weight as raising one — it needs the same evidence.

Step 3 — Report

Write security-review.md in the task folder (bootstrap per §1), ranked by severity:

# Security review — <target> · <date>
### Critical  — exploitable now: <boundary violated> → <impact> → <fix>
### High      — likely exploitable / sensitive-data exposure
### Medium    — defense-in-depth gaps
### Info      — hardening suggestions

Calibrate severity by reachability × impact, not by how alarming the category sounds:

A category does not set the rank — a hardcoded key in a repo nobody can read is not Critical, and a missing authorization check on one route is not Info.

A finding is valid only with a violated boundary + demonstrated impact + a concrete fix, and each one names which actor reaches it (Step 1) — no speculative "could be risky". Never invent a CVE or a vulnerability — verify and cite, or label it a hypothesis to confirm (§14). No secret is ever written into the report: name the file and line, never the value, and if a live credential is found say so plainly and treat rotation as part of the fix — a leaked secret that was committed is already public to anyone with repo history.

Step 3b — Variant analysis (report the class, not the instance)

Every confirmed finding triggers a hunt: search the whole codebase for the same pattern (same sink, same missing check, same unsafe construct) before closing. One SQL-injection finding usually means several; fixing the instance while its siblings ship is a false sense of security. Report the class with all its locations.

Step 4 — Close the loop

Write security-review.md to disk and confirm it is non-empty (§20.2) before touching the ledger — then record a harden entry in state.json.phases — approved: true on a clean pass, or waived: true only on the user's explicit acceptance of open findings (§2) — so a resumed run re-proves the security gate instead of trusting it. Critical/High must be fixed (or defensibly, explicitly accepted by the user) before ship. Route fixes through construct → verify, then re-audit the changed part. Record accepted risks in decisions.md.

Composition

• Consumes: the code/diff/config, security.md, project memory, current advisories (web).
• Produces: security-review.md; fixes routed to construct/verify.
• Receives from: engineer (auto-scheduled when a change touches auth, PII, payments, secrets, or a new public surface — a rule, not luck) or a direct user request.
• Hands off to: construct (fixes), release (blocks ship on unresolved Critical). Distinct from inspect (general code review) and assess (whole-app feature health).

Self-review (author's notes)

• Mis-routed? engineer routes here when a change touches auth, secrets, payments, or untrusted input; wrong for general quality review (inspect) or app health (assess). Pick this over inspect when the threat model, not the diff, is the question.
• Single-agent safe? Yes — the checklist runs inline; parallel auditors are optional.
• Leaks specifics? No — checklist is framework-neutral; findings cite real boundaries.
• Grounded? CVEs/advisories web-checked with today's date; nothing invented (§14, §17).