Sec Risk Security Review

Workflow phase and review mode

• Workflow phase: architecture, planning, release
• Review mode: human review for policy/legal decisions

Operating pattern

• Threat modeling: Use OWASP 4-question framework (What are we building? What can go wrong? What do we do about it? Did we do enough?) and STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
• Data classification: Classify all data (Public / Internal / Confidential / Restricted) and apply handling rules per level.
• ASVS baseline: Use OWASP ASVS 4.0 verification levels (L1/L2/L3) to select appropriate controls based on risk profile and regulatory requirements.
• Trust boundaries: Identify authentication and encryption requirements between system components and external entities.
• Control inventory: List implemented controls and gaps; prioritize gaps by risk score (likelihood × impact).
• Escalation: Use project guidelines first; escalate policy, legal, compliance, or procurement decisions to human review. For every Red/unacceptable risk (score 16+) that requires formal sign-off, create a HUS-* story in execution-plan/backlog/ with the threat ID, risk score, proposed mitigation or justification, and a clear approve / reject / defer decision. Record the decision using gov-review-gate-management. Do not proceed past the risk until the story is approved.
• Coordination: Work with sec-static-code-analysis (SAST hotspots needing architecture review), sec-security-vulnerability-analysis (dependency/secret scanning), and pipeline/release packages (risk-controlled gates).

Guideline lookup

• Follow docs/guidelines/shared-operating-policy.md#guideline-lookup.

Story and artifact maintenance

• Follow docs/guidelines/shared-operating-policy.md#story-maintenance for backlog, evidence, and follow-up updates tied to this skill.

Quality bars

• Threat model completeness: DFD must show trust boundaries, data flows, external entities, and sensitive data labels. STRIDE analysis must cover all six categories for high-risk components.
• Data classification: All data must be labeled L1-L4; handling rules must be documented and feasible (e.g., do not claim "encrypted at rest" without implementation plan).
• Control evidence: Controls must be concrete and testable: "HTTPS" not "secure transport"; "bcrypt + 12-char password" not "strong authentication"; code link or test case required.
• Risk scoring: All threats >6 must have L×I scores; red risks (16+) must have documented mitigation or formal approval; no unscored risks.
• Human escalation: Mandatory for policy interpretation, legal/compliance decisions, regulatory questions, and external-access approvals.
• Secrets & permissions: Explicit (names, rotation frequency, access list required); never implied (e.g., "API key exists somewhere" is not acceptable).

Failure modes to avoid

• Missing threat model: No DFD, no STRIDE analysis, no risk scores. Result: unidentified threats block release.
• Vague risk language: "Possible injection attack" without component/input/mitigation. Replace with: "Unauthenticated user ID in GET /order/{id} could expose others' orders; mitigate with RBAC + RLS."
• Unscored risks: "There's a threat" without L×I scoring prevents prioritization. All threats >6 must be scored; red risks must be resolved before release.
• Assuming compliance approval: Do not claim "GDPR compliant" without legal review. Escalate regulatory interpretation; never guess.
• Incorrect data classification: Mislabeling L3 data (PII) as L1 removes encryption. Over-classify when unsure.
• Ignoring pipeline exposure: Threat model at design time only is incomplete. Re-assess at deployment; verify CI/CD gates enforce risk controls.
• No mitigation owners: "We should rotate secrets" without owner and deadline becomes 0% likely. Always assign owner + date.
• Control without evidence: "We do input validation" without test case is not evidence. Link actual tests, pull requests, or threat model update.

Completion checklist

• Use docs/guidelines/shared-operating-policy.md#completion-checklist as the default completion gate for this skill.
• Threat model complete: DFD with trust boundaries, STRIDE analysis, threat list with L×I scores.
• Data classifications assigned: All data labeled L1-L4; handling rules documented.
• ASVS level selected: L1/L2/L3 chosen based on risk profile and regulatory requirements.
• Red risks resolved: All threats scoring 16+ have documented mitigation or a HUS-* story approved by security lead, product owner, and (if required) legal/compliance.
• Controls verified: Existing controls linked to test cases or code; gaps have remediation stories with owners.
• Approvals recorded: All Red/unacceptable risks have an approved HUS-* story in execution-plan/backlog/ with reviewer name and date; security lead, product owner, and (if required) legal/compliance recorded as reviewers.

Detailed workflow

1. System scoping: Define system boundaries, key assets (data, services, infrastructure), stakeholders, and business context.
2. Data classification: Classify all data handled (using data-classification-framework.md); apply handling rules (encryption, access, retention, deletion).
3. Threat identification: Build data flow diagram (DFD); apply STRIDE to each component and boundary; record threat scenarios (attack vector, actor, impact).
4. Threat prioritization: Score each threat using likelihood × impact matrix; identify high-priority (red) threats requiring immediate mitigation.
5. Control review: List existing controls per ASVS verification level (L1/L2/L3); identify gaps; prioritize by risk score.
6. Mitigation design: For each high-priority threat/gap, design concrete control (prevent/detect/respond) with owner and target completion date.
7. Risk acceptance: Document business justification and approval for unmitigated risks; set re-assessment date.
8. Re-check after remediation: Validate mitigations implemented; link evidence (tests, code review, threat model update); close loop.

Best-practice notes

• Threat modeling: Use OWASP 4-question framework and STRIDE categories (threat-modeling-guide.md). Data flow diagrams with trust boundaries identify attack surfaces; DFD is essential for architectural reviews.
• ASVS controls: Map architectural decisions to ASVS verification levels (asvs-checklist-guide.md). L1 baseline for most systems; L2 for sensitive data/compliance; L3 for mission-critical/high-assurance.
• Data sensitivity: Classify data accurately (data-classification-framework.md); classification drives encryption, access control, and retention requirements. Misclassification removes critical protections.
• Authentication & secrets: Use appropriate patterns (auth-secrets-architecture-guide.md): OAuth2/OIDC for users, mTLS for service-to-service, API key+HMAC for third-parties. Rotate secrets quarterly; never log secret values.
• Risk scoring: Use likelihood × impact matrix consistently. Document risk acceptance with owner, justification, expiration, and approval. Red risks (scores 16+) block release until mitigated or formally accepted.
• Evidence over assumptions: Prefer concrete tests, code examples, and architecture decisions over generic statements. "Security considered" without evidence is insufficient.
• Scanner coordination: When SAST or dependency scanning identifies hotspots (e.g., "user-supplied ID in query"), assess exploitability and auth/permission controls here; do not guess in code review.
• Escalation boundaries: Escalate policy interpretation, legal meaning, compliance certification, and procurement decisions to human experts. Do not invent compliance answers.

Examples

Example 1: E-commerce Service with Payments

Key threats: Session hijacking (HTTPS mitigation), API key exposure (vault + rotation), transaction tampering (webhook signature verification), privilege escalation (RBAC). Mitigations: HTTPS+HSTS, 15-min timeouts, encrypted API key storage, ASVS L2 controls. See risk-review.template.md for full structure.

Example 2: Microservices with Shared Database

Key threats: Service tampering shared data (mitigate: service-specific DB credentials + RLS), privilege escalation via superuser account (mitigate: remove superuser, grant minimal role), Kafka payload in plaintext (mitigate: TLS + encryption). ASVS L2 mapping: V4 (access control), V6 (encryption in flight).

Example 3: SAST Finding Routed Here

Finding: CodeQL flags SELECT * FROM users WHERE id = ${input} as SQL injection. Assessment: Parameterized query (false positive); auth check validates user_id ↔ request.user_id (RLS blocks exploitation). Decision: Suppress with rationale; update tool rule when available.

Integration with other skills

• sec-static-code-analysis → here: Route SAST hotspots (e.g., "user input in SQL") for exploitability + permission assessment with auth evidence.
• here → sec-security-vulnerability-analysis: Route dependency/secret scanning findings; confirm compliance with secrets rotation policy.
• here → qa-verification-planner: Create test scenarios validating mitigations (e.g., permission check prevents unauthorized access).
• here → pipeline-connector: Embed risk-controlled release gates; block deployments if unresolved red-priority threats remain.

Local assets

• risk-review.template.md — Structured output template with threat summary, control inventory, risk scoring, and multi-signer approval.
• threat-modeling-guide.md — OWASP 4-question framework, STRIDE methodology, DFD template, and practical scenarios.
• asvs-checklist-guide.md — OWASP ASVS 4.0 quick reference with verification levels, control mappings, and level selection.
• data-classification-framework.md — Data sensitivity levels (L1-L4), handling rules, and classification scenarios.
• auth-secrets-architecture-guide.md — Authentication patterns, secrets lifecycle, and trust architecture design.