Back to Details

attack-path-analysis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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
.
Standard scans and Deep Scan workers assess attack paths within their ordinary Standard scan workflow; neither invokes this separate phase skill.
本技能中提及的路径为该阶段的默认位置。若用户明确提供了所需输入或输出的其他路径，则使用用户提供的路径替代本技能中对应的默认路径。若所需输入仍缺失，请停止操作并向用户索要后再继续。使用
../../references/scan-artifacts.md
中共享的扫描工件路径约定。
标准扫描和深度扫描工作器会在其常规的标准扫描工作流内评估攻击路径；二者均不会调用此独立阶段技能。

Compact Workbench-Backed Diff Mode

基于工作台的紧凑差异模式

When a workbench-backed 
$security-diff-scan
has a 
scanId
, load the per-scan threat model and read the validated candidates with 
list_codex_security_candidates({ scanId, cursor?, limit? })
. Analyze every 
reportable
or 
deferred
candidate, preserve every discovery and validation field and the original candidate order, and submit all decisions together with one 
record_candidate_attack_paths({ scanId, attackPaths: [{ candidateId, attackPath }] })
call. Submit 
attackPaths: []
when no candidate enters this phase. The existing tool atomically updates the stored candidates; do not create per-finding reports, receipts, or manual candidate ledgers in this compact diff mode. Keep attack-path facts, counterevidence, severity calibration, and policy adjustment as separate reasoning steps. Other scan and standalone workflows retain their existing artifact behavior.
当基于工作台的
$security-diff-scan
拥有
scanId
时，加载该扫描对应的威胁模型，并通过
list_codex_security_candidates({ scanId, cursor?, limit? })
读取已验证的候选漏洞。分析每个标记为
reportable
（可报告）或
deferred
（延迟处理）的候选漏洞，保留所有发现和验证字段以及原始候选漏洞顺序，并通过一次
record_candidate_attack_paths({ scanId, attackPaths: [{ candidateId, attackPath }] })
调用提交所有决策。当没有候选漏洞进入此阶段时，提交
attackPaths: []
。现有工具会以原子方式更新存储的候选漏洞；在此紧凑差异模式下，请勿创建每个漏洞的报告、回执或手动候选漏洞台账。将攻击路径事实、反证、严重程度校准和策略调整作为独立的推理步骤。其他扫描和独立工作流保留其现有的工件行为。

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 product surface or 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. Record final policy decision 
    ignore
    explicitly; in compact diff mode, retain its candidate record for coverage, and otherwise drop it from the surviving finding set.
  8. For a durable diff scan, submit the nested decision for every eligible candidate in the single compact tool call. Otherwise, save that finding's visible attack-path report and append one attack-path receipt per candidate id at the default paths 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.
  1. 从
    ../../references/scan-artifacts.md
    加载扫描专属威胁模型路径，作为仓库特定威胁模型的真实来源。结合潜在漏洞从此处开始分析。这两个输入均为此工作流的必填项。
    • 对于仓库范围和限定路径的扫描，需包含标记为
      reportable
      或
      survives: yes
      的验证闭环记录，即使这些记录在发现阶段未被分配规范的候选漏洞编号。
  2. 判断受影响代码是否在仓库威胁模型的范围内，以及是否属于产品表面或生产工作流。
  3. 仅使用仓库证据构建真实的攻击路径：
    • 服务映射
    • 暴露面和入口点
    • 身份、权限和信任边界
    • 密钥处理和敏感数据流
    • 可达性
    • 现有控制措施和缓解方案
  4. 在确定范围或可报告性相关事实之前，找出针对关键范围字段的最强仓库反证，并解释其是否具有决定性。
  5. 根据仓库证据校准影响程度和发生概率。
  6. 基于上述事实和校准后的严重程度，单独执行一次最终策略调整步骤。
  7. 明确记录最终策略决策
    ignore
    （忽略）；在紧凑差异模式下，保留其候选漏洞记录以确保覆盖范围，否则将其从留存的漏洞集中移除。
  8. 对于持久化差异扫描，在单次紧凑工具调用中提交每个符合条件的候选漏洞的嵌套决策。否则，保存该漏洞的可见攻击路径报告，并在
    ../../references/scan-artifacts.md
    的默认路径下为每个候选漏洞ID追加一份攻击路径回执。回执必须记录候选漏洞ID、攻击路径可报告性决策、攻击路径事实或确切的证据缺口，以及该候选漏洞对应的攻击路径工件/报告引用。

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 product surface or 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.
  • Establish identities, privileges, and trust boundaries that matter for the path.
  • Establish whether sensitive data, secrets references, or privileged control paths are involved.
  • Determine whether a realistic attacker can actually reach and use the issue from an in-scope attack surface.
  • Identify the strongest repository counterevidence against the scoping and reportability-driving fields before finalizing them.
  • Lower confidence or keep fields unknown when repository evidence is incomplete; do not automatically suppress a finding solely because deployment evidence is missing.
在确定攻击路径事实或策略决策之前，请使用此检查清单：
  • 判断该漏洞是否为真实的安全漏洞，而非正确性错误或误报。
  • 判断受影响代码是否属于产品表面或生产工作流。
  • 根据仓库证据映射相关服务、组件或工作流上下文。
  • 根据仓库证据（如监听器、入口、负载均衡器、服务端口、清单、路由或网络策略）确定暴露面和入口点。
  • 确定与该路径相关的身份、权限和信任边界。
  • 确定是否涉及敏感数据、密钥引用或特权控制路径。
  • 判断现实中的攻击者是否真的可以从范围内的攻击面触及并利用该问题。
  • 在确定范围和可报告性相关字段之前，找出针对这些字段的最强仓库反证。
  • 当仓库证据不完整时，降低置信度或保留字段为未知状态；请勿仅因部署证据缺失就自动压制漏洞。

Counterevidence Checklist

反证检查清单

For the most interpretive fields, explicitly ask what repository evidence suggests the opposite and why it does or does not defeat the finding:
  • In-Scope Status According to the Threat Model
  • Vector
  • Auth Scope
  • Exposure
  • Cross-Boundary Behavior
  • Preconditions
  • Impact Surface
Look specifically for repository evidence that the path is:
  • out of scope
  • internal-only
  • admin-only
  • not cross-boundary
  • not attacker-reachable
  • not meaningfully reportable
对于最具解释性的字段，明确询问仓库证据是否表明相反情况，以及为何能或不能否定该漏洞：
  • 根据威胁模型确定的范围内状态
  • 攻击向量
  • 授权范围
  • 暴露程度
  • 跨边界行为
  • 前置条件
  • 影响面
需特别查找表明该路径属于以下情况的仓库证据：
  • 超出范围
  • 仅内部可用
  • 仅管理员可用
  • 不跨边界
  • 攻击者无法触及
  • 不具备实际可报告性

Severity and Policy Checklist

严重程度与策略检查清单

Apply severity and policy calibration using 
references/severity-policy.md
.
使用
references/severity-policy.md
进行严重程度和策略校准。

Output Contract

输出约定

In compact diff mode, every candidate with validation disposition 
reportable
or 
deferred
must receive exactly one nested attack-path decision. The recorded decisions are the complete phase output; do not also create narrative reports or receipts. Otherwise, use the following report contract.
For each surviving finding include:
  • title
  • candidate id, instance key, and ledger row id when provided
  • affected lines from validation, preserving labeled entrypoint/wrapper, root_control, sink, and concrete_implementation locations
  • attack path steps
  • rendered attack-path facts
  • counterevidence summary and challenges
  • severity calibration
  • final policy decision
  • enough reasoning that a later reader can understand why the finding survived or was suppressed
Render attack-path facts using 
references/attack-path-facts.md
.
在紧凑差异模式下，每个验证状态为
reportable
或
deferred
的候选漏洞必须对应一个嵌套的攻击路径决策。记录的决策即为该阶段的完整输出；请勿同时创建叙述性报告或回执。否则，请遵循以下报告约定。
对于每个留存的漏洞，需包含：
  • 标题
  • 候选漏洞ID、实例密钥和台账行ID（若提供）
  • 验证阶段确定的受影响代码行，保留标记的入口点/包装器、root_control、终点和concrete_implementation位置
  • 攻击路径步骤
  • 呈现的攻击路径事实
  • 反证摘要与质疑点
  • 严重程度校准结果
  • 最终策略决策
  • 足够的推理内容，以便后续读者理解该漏洞为何被留存或压制
使用
references/attack-path-facts.md
呈现攻击路径事实。

Hard Rules

硬性规则

  • Use repository evidence and explicitly supplied context. Access the network only when the user has expressly authorized that access; an offline scan never accesses the network.
  • Do not invent attack chains that the code does not support.
  • Do not leave candidate coverage implicit. In compact diff mode, record a nested attack-path decision for every eligible candidate, even when the final policy decision is 
    ignore
    or 
    deferred
    . Otherwise, every candidate that reaches attack-path analysis must leave an attack-path receipt in its candidate-ledger path from 
    ../../references/scan-artifacts.md
    .
  • Do not drop exact affected locations while converting validated findings into attack paths. Repository-wide seeded/root-control rows that survive validation must keep their root-control file:line even when a wrapper, route, or transport is easier to explain.
  • Do not skip a reportable validation row because a neighboring same-family finding has a cleaner story. Either produce attack-path facts for that exact row or make an explicit final policy decision with repository counterevidence.
  • Missing public-ingress evidence is not by itself dispositive counterevidence.
  • Keep attack-path analysis, severity calibration, and final policy suppression as separate sub-stages.
  • Use the final policy-adjustment matrix mechanically rather than re-arguing severity from scratch after the facts are set.
  • Outside compact diff mode, save a final visible report for each candidate finding using that finding's attack-path analysis report path from 
    ../../references/scan-artifacts.md
    .
-- Considerations for attack path --
  • A bug matters if evidence shows an attacker could exploit it.
  • The attack surface should generally be one that is plausibly exposed to end users / external actors (or another actor explicitly in scope in the threat model).
  • 使用仓库证据和明确提供的上下文。仅当用户明确授权时才可访问网络；离线扫描绝不能访问网络。
  • 不得编造代码不支持的攻击链。
  • 不得隐含候选漏洞覆盖范围。在紧凑差异模式下，需为每个符合条件的候选漏洞记录嵌套的攻击路径决策，即使最终策略决策为
    ignore
    或
    deferred
    。否则，每个进入攻击路径分析阶段的候选漏洞必须在
    ../../references/scan-artifacts.md
    指定的候选漏洞台账路径下留下攻击路径回执。
  • 在将已验证漏洞转换为攻击路径时，不得遗漏确切的受影响位置。通过验证的仓库范围种子/root_control记录必须保留其root_control文件:行号，即使包装器、路由或传输层更容易解释。
  • 不得因相邻同类型漏洞的描述更清晰就跳过可报告的验证记录。要么为该确切记录生成攻击路径事实，要么基于仓库反证做出明确的最终策略决策。
  • 缺少公共入口证据本身并非决定性的反证。
  • 将攻击路径分析、严重程度校准和最终策略压制作为独立的子阶段。
  • 机械性地使用最终策略调整矩阵，而非在事实确定后从头重新论证严重程度。
  • 在紧凑差异模式之外，使用
    ../../references/scan-artifacts.md
    中指定的该漏洞攻击路径分析报告路径，为每个候选漏洞保存最终的可见报告。
-- 攻击路径考量因素 --
  • 若证据表明攻击者可利用某个漏洞，则该漏洞至关重要。
  • 攻击面通常应是可能暴露给终端用户/外部参与者（或威胁模型中明确纳入范围的其他参与者）的区域。