Security Architecture Review
A structured security architecture review: walk the stack for secrets, dependencies, auth, and common vulnerability classes, then report findings ranked by severity and confidence.
Steps
Entry step: model-system. Each step names the specialist role it wants; the full working prompt is expandable.
- Map assets and trust boundariessecurity architectentry
Establish the system, sensitive assets, actors, data flows, controls, and review limits.
Show working prompt
Inspect architecture notes, entry points, deployment and dependency metadata, configuration schemas, authentication and authorization code, persistence, network surfaces, and security tests. Map sensitive assets, actors, privilege levels, trust boundaries, inbound and outbound data flows, third parties, and existing controls. Record only secret names or locations, never values. State scope exclusions and missing evidence explicitly. Observable handoff: write the completed result to `security/review-scope.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
- Audit controls and prove findingsapplication security engineer
Walk the attack surface systematically and maintain an evidence-backed findings register.
Show working prompt
Use `security/review-scope.md` to inspect secrets handling, dependency and supply-chain controls, authentication, session management, authorization at every mutation sink, input handling, output encoding, injection boundaries, file and path access, cryptography, logging, privacy, network exposure, update paths, and failure behavior. For every candidate, capture the exact evidence path, attack preconditions, affected asset, impact, confidence, and a safe validation method. Do not claim a vulnerability from a pattern match alone. If external advisory research is unavailable, label dependency status unverified rather than guessing. Before working, open `security/review-scope.md` with `read_artifact`. Observable handoff: write the completed result to `security/findings-register.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
- Write the security architecture reviewsecurity reviewer
Deliver prioritized findings, strengths, remediation, and retest instructions for owners.
Show working prompt
Synthesize the scope and findings register into a decision-ready report. Start with an executive risk posture and the strongest controls already working. For each confirmed finding, include severity, confidence, evidence path, causal control gap, realistic attack path, impact, prioritized remediation, owner, verification, and residual risk. Group systemic themes, distinguish quick containment from durable fixes, and state areas not verified. Do not include exploit payloads or sensitive values unless the user explicitly needs a safe proof and policy permits it. Observable handoff: write the completed result to `security/security-architecture-review.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
- Evaluate the deliverableindependent security reviewer
Independently grade the observable deliverable and route it to finish, repair, or user escalation.
Show working prompt
Review `security/security-architecture-review.md`, `security/review-scope.md`, `security/findings-register.md` against every criterion below. Inspect the underlying evidence files named by the workflow; do not grade from the author's summary alone. 1. Scope, assets, trust boundaries, actors, data flows, and review limits are explicit. 2. Coverage includes identity, authorization, secrets, dependencies, inputs, storage, network, logging, updates, and operational failure paths where applicable. 3. Every confirmed finding has inspectable evidence, realistic preconditions, impact, severity, and confidence; pattern-only suspicions are not promoted. 4. No secret value or unsafe exploit detail is exposed in the deliverables. 5. Remediation is prioritized, owned, verifiable, and distinguishes containment from durable control repair. 6. Positive controls, rejected hypotheses, residual risk, and unverified areas are reported honestly. Open `security/security-architecture-review.md`, `security/review-scope.md`, `security/findings-register.md` with `read_artifact`. Write the evidence-backed review to `reviews/security-architecture-review-evaluation.md` in the artifacts drawer with `write_artifact`. Give each criterion a PASS or FAIL with a concrete path, excerpt, measurement, or observed behavior. End with exactly `Verdict: PASS` or `Verdict: REVISE`. Then use `advance_task_step` for the active task: PASS routes to `finish`; REVISE routes to `repair` for review rounds 1 through 2, and the 3th REVISE routes to `needs-user`. Never route to finish while a criterion is unmet.
- Repair the deliverableapplication security engineer
Fix only the concrete gaps from the latest independent review.
Show working prompt
Read `reviews/security-architecture-review-evaluation.md` with `read_artifact` and repair every failed criterion in `security/security-architecture-review.md`, `security/review-scope.md`, `security/findings-register.md`. Make changes on each file's declared surface (`write_artifact` for artifact inputs, `write_file` for workspace inputs), not in task notes or a reply. Preserve evidence that already passed. Re-run or re-check anything the reviewer found unproven. Ensure `security/security-architecture-review.md` is genuinely updated this turn so the repair is observable, then hand it back for independent evaluation.
- Finishproject lead
All deterministic and reviewer criteria passed.
Show working prompt
The independent review passed. Read `reviews/security-architecture-review-evaluation.md` with `read_artifact`, then use `write_task_note` to record a concise DONE summary with the final deliverable paths (`security/security-architecture-review.md`, `security/review-scope.md`, `security/findings-register.md`) and the evidence that each acceptance criterion passed. Report DONE without starting new work.
- Escalate unresolved concernsproject lead
The bounded repair loop ended without a defensible pass.
Show working prompt
The deliverable did not pass after 3 review rounds. Do not claim success. Read `reviews/security-architecture-review-evaluation.md` with `read_artifact`, then use `write_task_note` to record DONE_WITH_CONCERNS: the unmet criteria, what was attempted, the affected paths, and the smallest user decision or missing input needed to continue.
Triggers
Phrases that suggest this craftbook to a crew.
- security audit
- check for vulnerabilities
- owasp review
Source
View this craftbook on GitHub · MIT license