Security Attack Path Analysis

Security Attack Path Analysis

Objective

Turn validated or still-plausible findings into explicit attacker stories, structured attack-path analysis facts, severity calibration, and a final reportability decision grounded in the threat model.

Artifact Resolution

The path references in this skill are the default locations for this phase. If the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill. If a required input is still missing, stop and ask the user for it before continuing. Use the shared scan artifact path conventions in ../../references/scan-artifacts.md.

Workflow

1. Load the per-scan threat model path from ../../references/scan-artifacts.md as the repo-specific threat-model source of truth. Start from this along with the potential findings. Both inputs are required for this workflow.
   • For repository-wide and scoped-path scans, include validation closure rows marked reportable or survives: yes even if they were not assigned polished candidate numbers during discovery.
2. Determine whether the affected code is in scope for the repository threat model and whether it belongs to a real product surface or real production workflow.
3. Build a factual attack path using repository evidence only:
   • service mapping
   • exposure and entry points
   • identity, privilege, and trust boundaries
   • secrets handling and sensitive-data flow
   • reachability
   • existing controls and mitigations
4. Before finalizing scope or reportability-driving facts, identify the strongest repository counterevidence against the key scoping fields and explain why it is or is not dispositive.
5. Calibrate impact and likelihood from the repository evidence.
6. Apply a separate final policy-adjustment pass mechanically using those facts and the calibrated severity.
7. Drop any candidate whose final policy decision is ignore.
8. Save that finding's visible attack-path report to its per-finding attack-path analysis report path from ../../references/scan-artifacts.md.
9. Append one attack-path receipt per candidate id to that finding's candidate ledger path from ../../references/scan-artifacts.md. The receipt must record the candidate id, attack-path reportability decision, attack-path facts or exact proof gap, and attack-path artifact/report reference for that candidate finding.

Scope and Attack Path Checklist

Use this checklist before finalizing the attack-path facts or policy decision:

• Determine whether the finding is actually a real security vulnerability rather than a correctness bug or false positive.
• Determine whether the affected code belongs to a real product surface or meaningful production workflow.
• Map the relevant service, component, or workflow context from repository evidence.
• Establish exposure and entry points from repository evidence such as listeners, ingress, load balancers, service ports, manifests, routing, or network policy.