菜单
Use when constructing SCOPE attack candidate chains from audit artifacts and rejecting facts that do not form attacker progressions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when formatting SCOPE controls detection candidates into detections.md, detections.json, dashboard-readable SPL sections, or controls-schema detection records.
Use when attaching schema-valid SCOPE evidence handles to attack candidates, hops, observations, assumptions, and caveats.
Use when scope-exploit has operator-approved attack paths and needs to generate the narrative red team playbook, execution steps, persistence, post-exploitation, and IAM policy JSON without detection or SOC guidance.
Use when scope-investigate completes an investigation and needs a facts-only analyst summary, evidence timeline, query appendix, investigation gaps, and optional saved investigation artifact.
Use when a SCOPE top-level agent starts a run and needs bounded environment knowledge, durable observations, reasoning notes, coverage gaps, and Splunk patterns before planning.
Use after SCOPE evidence review, final disposition, or operator-approved save to update durable environment knowledge, observations, coverage gaps, or proposed reasoning-note improvements.
| name | scope-attack-path-analysis |
| description | Use when constructing SCOPE attack candidate chains from audit artifacts and rejecting facts that do not form attacker progressions. |
Use this skill inside scope-attack-analyze to build candidate_attack_paths[]. This skill does not validate or promote final paths. Do not write final attack_paths[]; scope-attack-validate owns promotion after validation.
A candidate path must satisfy this bar:
entry point -> new execution context -> new permission set -> impact
Each hop must change position, principal context, capability, reachable resource, permission set, execution context, or impact. A hop can represent role chaining, lateral movement between principals/resources, a policy-controlled transition, or a resource access transition, but it must move the attacker forward.
When public_entrypoints[] exists, treat it as the source of public-start candidates. Only records with attack_path_seed: true can start starting_position.type: "public_endpoint" candidates. Set starting_position.id to the exact public_entrypoints[].id. Keep attack_path_seed: false records as exposure context unless another collected graph, IAM, or resource-policy fact creates a separate attacker-controlled transition.
public_entrypoints[] seed reaches compute or a service integration, and collected AWS evidence proves a resource-policy grant, event source, identity issuance path, or concrete data transition. Do not treat backend role permissions alone as public caller access.executes_as role from the public entrypoint and the role can reach a concrete impact. Keep backend application behavior as a runtime assumption when the run does not prove the application calls the impact action.SourceArn, SourceAccount, or SourceOwner context.Principal: "*" grants the service, external, or account principal only when action, resource, and conditions match the candidate context.lambda:InvokeFunctionUrl and collected Function URL configuration satisfies lambda:FunctionUrlAuthType or lambda:InvokedViaFunctionUrl conditions.kms:Decrypt, or a matching KMS grant.Prefer chains that connect collected graph edges, IAM policy facts, trust policy facts, and module resources. Role chaining and lateral movement count when the next principal/resource context can reach capabilities the prior context could not.
Reject these from candidate_attack_paths[] and place attack-relevant facts in security_observations[]:
SourceArn, SourceAccount, or SourceOwner.attack_path_seed is false and no separate transition evidence exists.Examples include broad permissions with no reachable principal, public configuration with no action path, a trust policy with no assumable starting context, or data sensitivity claims that omit the resource ARN and AWS action.
hops[] on every candidate_attack_paths[] entry.security_observations[] with reason_not_path.runtime_assumption.coverage_caveat.attack_paths[].Each hop should name transition, from_context, action, target, resulting_context, capability_gained, validation_type, and evidence handles. Use concrete ARNs, graph IDs, module source paths, and policy document handles from the run directory.