scope-attack-path-analysis

SCOPE Attack Path Analysis

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.

Chain Quality Bar

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.

Accept As Candidate Chains

• Public endpoint with AWS-level proof: a 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.
• Public service-connected role path: graph evidence reaches an 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.
• EC2 public ingress role path: graph evidence connects public security group ingress to an attached EC2 instance and instance-profile role with concrete impact. Standalone open ports remain exposure observations.
• DNS/CDN service path: Route 53 or CloudFront can participate in a candidate only when graph evidence correlates DNS/CDN targets to collected AWS resources. Unresolved DNS targets remain exposure observations.
• Assume-role then stronger action: the starting principal can assume another role, and the resulting role has a stronger action that changes the permission set or reachable resource set.
• Pass-role into compute: the principal can pass a role into a compute or execution service, creating a new execution context with that role's permissions.
• Existing CodeBuild project execution: the principal can start a collected CodeBuild project, graph evidence maps the project to a service role, and that role reaches concrete impact.
• Identity issuance: a collected identity provider such as an unauthenticated Cognito identity pool can issue AWS credentials for a role, and the role reaches concrete impact.
• Concrete data impact: a reachable role can read collected Secrets Manager, S3, DynamoDB, or SSM resource ARNs. SecureString SSM, SSE-KMS S3, and CMK-encrypted Secrets Manager reads need KMS evidence when graph edges record a key dependency.
• Resource policy external access to impact: a bucket, queue, key, secret, function, or other resource policy grants external access that leads to a concrete impact action on a target resource.
• Event-source policy access: a resource such as S3 emits an event through a service principal and the target resource policy allows that service principal with matching SourceArn, SourceAccount, or SourceOwner context.
• SNS/SQS event-source path: graph evidence shows a collected SNS subscription or Lambda event source mapping from the source queue/topic to the consumer.
• Wildcard-principal resource policy access: Principal: "*" grants the service, external, or account principal only when action, resource, and conditions match the candidate context.
• Lambda Function URL policy access: a function policy grants lambda:InvokeFunctionUrl and collected Function URL configuration satisfies lambda:FunctionUrlAuthType or lambda:InvokedViaFunctionUrl conditions.
• KMS-protected data access: the path reaches SSE-KMS S3 data or a CMK-encrypted secret, and KMS authorization exists through direct key-policy principal allow, account-root delegation plus identity kms:Decrypt, or a matching KMS grant.