Scan
Review authorized first-party product code and configuration for likely security defects. Return bounded, source-backed candidates that the regression-testing phase can confirm.
Boundaries
- Work only within the repository, product, or subtree requested by the user.
- Do not mutate project files, Jira, GitHub, production systems, or external services.
- Limit output to source evidence, uncertainty, and local regression-test handoffs.
- Do not run dependency/CVE, secret, compliance, or generic SAST scanners unless separately requested.
- A candidate is not a confirmed finding.
Scope
Include:
- first-party production source;
- runtime and deployment configuration;
- migrations and shipped scripts;
- first-party trust-boundary glue;
- unsafe first-party use or configuration of dependencies.
Exclude:
- defects residing solely in dependencies;
- generated and vendored code;
- CI infrastructure;
- test-only defects;
- correctness or reliability bugs without a plausible security-boundary consequence.
Review loop
1. Preflight
- Resolve the requested repository, product, or subtree.
- Record canonical repository identity, current ref, exact commit, and initial working-tree state.
- Identify explicit scope limits and unavailable surfaces.
2. Understand the system
Infer relevant deployment assumptions, roles, data boundaries, entry points, and security invariants from repository evidence. Keep the model proportional to the requested scope. A supplied diff may set priority but never replaces surrounding-flow inspection.
3. Inspect behavior
Trace user-controlled data, identity, authorization, state transitions, isolation, and cross-component assumptions through production paths. Prefer concrete data and control flow over language-specific checklists. Inspect callers and shared routes before attributing a defect to a leaf function.
4. Form candidates
A reportable candidate requires:
- one named security invariant;
- affected production paths or configuration;
- source-backed expected and apparent behavior;
- a plausible security consequence;
- explicit assumptions and uncertainty;
- one minimal local regression-test seam.
Discard generic hardening advice, checklist matches without a concrete flow, and suspicions lacking production-source evidence. Group manifestations sharing one root cause and invariant.
Do not validate candidates in this phase. If runtime confirmation is needed, provide a concise handoff for the regression-testing phase.
5. Account and report
Confirm the working tree still matches the preflight snapshot. Report only assessed surfaces, limitations, and source-backed candidates.
Completion
Status is:
complete: requested surfaces were reviewed to the declared depth and every candidate was resolved for handoff or discarded;partial: useful review completed, but named surfaces or evidence remained unavailable;blocked: repository state or missing context prevented meaningful review.
Completion means the bounded review finished. It does not mean the product is secure or that candidates are confirmed defects.
Report schema
Return exactly one concise Markdown report in the session. Do not create a local report file.
Header
# Defensive security review: <target>
**Status:** complete | partial | blocked
**Revision:** <repository> · <ref> · <commit>
**Working tree:** unchanged | changed unexpectedly
Add one direct warning when source state or review integrity is unreliable.
Coverage and limitations
## Coverage and limitations
- Examined: <product surfaces and boundaries>
- Partial: <surface and reason>
- Skipped: <surface and reason>
Name behavior surfaces and boundaries, not file counts. Never use coverage percentages or claim security assurance.
Candidate index
Omit this section when no candidate met the evidence gate.
## Candidates
| # | Candidate | Product surface | Confidence |
| - | ---------------------------------------- | --------------- | ---------- |
| 1 | Session rotation may preserve old access | Authentication | medium |
Confidence describes source evidence, not impact severity:
high: production flow and invariant conflict are directly visible;medium: source flow is concrete, but a deployment or runtime assumption remains;low: do not report; keep inspecting or discard.
Candidate cards
Use the same structure for every candidate:
---
## 1. Session rotation may preserve old access
**Confidence:** medium
### Security invariant
<One sentence describing required behavior.>
### Source evidence
- `<path>` · `<symbol>` · <role in the relevant flow>
<Concise expected-versus-apparent source behavior.>
### Security consequence
<Concrete consequence if the source interpretation and assumptions hold.>
### Assumptions and uncertainty
<Only facts that affect whether the candidate is real.>
### Regression-test handoff
- Test seam: <existing test area or smallest suitable fixture>
- Expected property: <observable invariant>
- Control: <nearby allowed or invariant-preserving case>
Keep candidate reports source-focused and bounded. Candidates remain unconfirmed until regression testing exercises the production path.
No candidates
Use direct language:
## Result
No source-backed security-defect candidate met the reporting gate within the assessed scope.
This does not establish that the product is secure.