Review Security
Workflow
- Establish the review target, intended behavior, and relevant threat model.
- Identify assets, trust boundaries, actors, entry points, and sensitive operations.
- Trace attacker-controlled data to security-relevant sinks.
- Inspect authentication, authorization, tenant isolation, and privilege changes.
- Evaluate realistic exploitability and existing controls.
- Validate suspected findings safely with read-only analysis or sandboxed tests when authorized.
- Return prioritized findings with evidence, impact, prerequisites, and remediation direction.
Guardrails
- Work read-only by default.
- Do not access production systems, real customer data, or private credentials.
- Do not publish weaponized exploit details or active secrets.
- Avoid checklist-only findings without a reachable attack path.
- Distinguish a missing defense-in-depth measure from an exploitable vulnerability.
- Treat dependency scanner output as leads requiring context.
- Keep proof-of-concept activity scoped, reversible, and authorized.
Threat checklist
Read references/threat-checklist.md for changes involving identity, parsers, URLs, files, commands, serialization, secrets, data boundaries, CI, or cloud permissions.
Finding standard
Include:
- severity and confidence;
- affected asset and trust boundary;
- attacker prerequisites;
- source-to-sink or authorization path;
- impact;
- exact code location;
- safe reproduction guidance when appropriate;
- remediation and verification direction.
Acceptance criteria
- Findings describe realistic attack paths.
- Authorization and tenant boundaries are explicitly reviewed.
- Sensitive data handling is traced through logs and storage.
- False positives and assumptions are called out.
- No live exploitation or unauthorized write occurred.
- Residual risk and unreviewed surfaces are explicit.
1---2name: review-security3description: Review application and infrastructure changes for exploitable security risks by tracing assets, trust boundaries, attacker-controlled input, authorization, sensitive data, and dangerous sinks. Use for security reviews, threat-focused PR reviews, authentication or authorization changes, input handling, secrets, dependencies, and infrastructure permissions; do not use to exploit live systems or modify code unless separately requested.4---56# Review Security78## Workflow9101. Establish the review target, intended behavior, and relevant threat model.112. Identify assets, trust boundaries, actors, entry points, and sensitive operations.123. Trace attacker-controlled data to security-relevant sinks.134. Inspect authentication, authorization, tenant isolation, and privilege changes.145. Evaluate realistic exploitability and existing controls.156. Validate suspected findings safely with read-only analysis or sandboxed tests when authorized.167. Return prioritized findings with evidence, impact, prerequisites, and remediation direction.1718## Guardrails1920- Work read-only by default.21- Do not access production systems, real customer data, or private credentials.22- Do not publish weaponized exploit details or active secrets.23- Avoid checklist-only findings without a reachable attack path.24- Distinguish a missing defense-in-depth measure from an exploitable vulnerability.25- Treat dependency scanner output as leads requiring context.26- Keep proof-of-concept activity scoped, reversible, and authorized.2728## Threat checklist2930Read [references/threat-checklist.md](references/threat-checklist.md) for changes involving identity, parsers, URLs, files, commands, serialization, secrets, data boundaries, CI, or cloud permissions.3132## Finding standard3334Include:3536- severity and confidence;37- affected asset and trust boundary;38- attacker prerequisites;39- source-to-sink or authorization path;40- impact;41- exact code location;42- safe reproduction guidance when appropriate;43- remediation and verification direction.4445## Acceptance criteria4647- Findings describe realistic attack paths.48- Authorization and tenant boundaries are explicitly reviewed.49- Sensitive data handling is traced through logs and storage.50- False positives and assumptions are called out.51- No live exploitation or unauthorized write occurred.52- Residual risk and unreviewed surfaces are explicit.
hashgraph-online