attack-path-analysis
Security Attack Path Analysis
Determine whether each supplied finding has a supported attacker path, what impact it has, and whether it is reportable. Before creating or retaining files, read ../../references/artifact-storage.md.
Establish the attack path
For a scan phase, use its per-scan threat model and candidate set from ../../references/scan-artifacts.md. Preserve supplied input paths. If a required scan artifact is unavailable, report the missing input.
For standalone analysis, use the supplied finding, repository, threat model or security policy, and context. A per-scan artifact is not required. State material assumptions and ask for missing context only when it prevents a meaningful assessment.
- Establish the in-scope attacker, affected product surface, entry point, controlled input, security boundary, and sensitive operation. Trace the path from repository evidence.
- Identify relevant controls and the strongest counterevidence. Explain what they establish, which prerequisites remain, and whether the exact claimed boundary is crossed.
- Assess impact and likelihood from those facts, then apply references/severity-policy.md. Keep facts, severity calibration, and the final policy decision distinguishable in the result.
- Return an explicit decision for every eligible candidate, including ignored or deferred candidates. Do not replace a supported instance with a neighboring finding or lose its root-control location.
Use repository evidence and explicitly supplied context. Access the network only when the user has expressly authorized it; an offline scan never accesses the network. Do not invent unsupported attack chains. Missing deployment or public-ingress evidence can limit confidence without defeating an otherwise supported finding.