القائمة
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.