edc-review

name	edc-review
description	Performs security/adversarial differential review of code changes (PRs, commits, diffs). Use this for auth, validation, trust-boundary, injection, crypto, memory-safety, external-call, state-mutation, or security-regression risk. It leverages git history and edc-context for blast radius and writes markdown security reports.
allowed-tools	["Read","Write","Grep","Glob","Bash","Skill"]

Security Review

Review code changes for exploitable or misuse-oriented security risk. This is not a generic code-quality or delivery/spec review.

Use edc-audit for code quality, maintainability, bloat, duplication, and test-value analysis. Use edc-delivery-review for goal/spec delivery and architecture-fit review. Use this skill when the important question is: can this change break a trust boundary, remove a protection, expose attacker-controlled input, or reintroduce a security bug?

Invocation modes

Check arguments first.

Mode A — scoped (--task-file <path>)

The edc-review.sh orchestrator invokes this mode for per-module security reviews.

1. Read the task file at <path>.
2. Parse:
   • Target under ## Target
   • Baseline under ## Baseline when present
   • Files to review under ## Files to review
3. Derive {module} from the task file basename.
4. Load context in this order, skipping missing files silently:
   • edc-context/index.md for routing/coupling/blast-radius guidance
   • edc-context/reports/issues.md
   • edc-context/modules/{module}.md
5. Scope review strictly to listed files. Inspect callers/dependencies only when security blast radius or reachability requires it.
6. Follow methodology.md, adversarial.md, patterns.md, and reporting.md.
7. Write edc-context/review-tasks/report-{module}.md. The report file is mandatory.

Do not write elsewhere, update manifest.json, or consolidate. The orchestrator handles consolidation.

Mode B — standalone

When no task file is provided, classify the target, build/load context, run the same security workflow, and write a durable report such as review-{target}.md.

Core rules

• Security-only: report vulnerabilities, security regressions, trust-boundary breaks, attacker-controlled data flow bugs, and missing security tests. Do not report style, bloat, generic maintainability, or spec-delivery issues.
• Evidence-first: every finding needs file:line evidence and a concrete attack path or misuse path. If reachability is unproven, say so and lower confidence.
• History-aware: inspect git history for removed auth, validation, escaping, sandboxing, crypto, memory-safety, or CVE/security-fix code.
• Context-aware: use EDC invariants, trust boundaries, known issues, and coupling notes to focus analysis.
• No false drama: a report with No security findings is valid when no exploitable or security-relevant issue is found.
• Output-first: create the required report early and finalize it even when there are no findings.

Risk triggers

Treat these as security-relevant until proven otherwise:

Risk	Examples
Access control	authn/authz, roles, permissions, tenant boundaries
Input/data validation	parsing, escaping, deserialization, path handling, SQL/shell/templates
State mutation	money, ownership, config, persistence, irreversible operations
Trust boundaries	public APIs, CLI args, env/config, filesystem, network, subprocesses
Crypto/secrets	key handling, randomness, signing, tokens, credentials, logs
Memory safety	C/C++ buffers, allocation math, signedness, lifetime/free patterns
Regression	removed/reintroduced security checks, code from CVE/fix/security commits

Supporting docs

• methodology.md — triage, history, security test confidence, blast radius, context checks
• adversarial.md — attacker model, concrete attack path, exploitability
• patterns.md — vulnerability pattern reference
• reporting.md — security report shape and no-finding format