Derivation rules
2,433 declarative match → where → emit rules
(1,787 derived, 646 explicit).
Filter by cloud, emitted edge, node type, or text.
codebuild:UpdateProject modifies env vars, image, VPC, privileged mode, and service role (config side).
codebuild:UpdateWebhook allows a principal to modify an existing webhook's filter groups or event types, potentially broadening the trigger surface.
codebuild:StartBuild without modifying the buildspec triggers execution of the current (stored) definition.
CodeBuild project env vars of type SECRETS_MANAGER or PARAMETER_STORE reference secret material injected into every build's environment.
Principal can create a CodeBuild project bound to a passed identity (create + PassRole).
A cross-account principal that can start or modify a CodeBuild build gains a foothold in the project's account via the service role.
Create a new CodeBuild project bound to a passable privileged role and start a build to execute as that role.
UpdateProject + PassRole swaps the service role of an existing project; the next build runs as the new (attacker-chosen) role.
A CodeBuild project runs every build as its configured IAM service role.
A CodeBuild project environment variable with type PLAINTEXT whose value pattern-matches credential material exposes that credential to build code.
The build container exposes the project service role's short-lived credentials via the ECS task-credential endpoint.
iam:PassRole to codebuild.amazonaws.com lets the principal assign any passable role as the project service role (via CreateProject or UpdateProject).
A CodePipeline BUILD stage action invokes codebuild:StartBuild on the project; the pipeline orchestrates the build trigger.
A project webhook lets qualifying push/PR events trigger a build without any codebuild:StartBuild permission.
GitPush to the branch a downstream CodeBuild project or CodePipeline stage tracks gives the attacker code-injection into that runner's execution.
Overriding PR approval rules and merging an attacker-authored PR branch into the tracked branch bypasses the branch-protection gate and injects code into the pipeline.
PutFile to the branch a downstream runner tracks injects a single-file change (e.g. buildspec.yml) into the pipeline's build.
GitPull or GetFile lets a principal read the full repository content, potentially harvesting secrets committed to source code.
A cross-account GitPush grant in the repository resource policy lets an external principal inject code into pipelines in the repository-owning account.
cloudformation:CreateChangeSet with attacker template + cloudformation:ExecuteChangeSet applies the attacker's template to the stack, running as the service role.
cloudformation:CreateStack + iam:PassRole(serviceRole to cloudformation.amazonaws.com): create a new stack bound to a chosen privileged service role and run arbitrary template code as it.
cloudformation:ExecuteChangeSet alone (approver role, no CreateChangeSet): can apply an attacker-authored pending change set if one already exists - CONDITIONAL on attacker-authored change set being present.
A stack's service role (Identity) triggers the Custom:: resource Lambda during stack lifecycle events via lambda:InvokeFunction; principals who CanExecuteAs the service role inherit this CanTrigger path.
cloudformation:CreateStackInstances / UpdateStackSet in the admin account deploys to target accounts, executing as the StackSet execution role there - a cross-account foothold.
cloudformation:CreateStackSet/UpdateStackSet with SERVICE_MANAGED permission model (Organizations integration) deploys to all Org member accounts - equivalent to organization-wide foothold.
Write access to the S3 object that a stack's TemplateURL references: the next stack update will load and execute the attacker's template as the service role.
cloudformation:UpdateStack lets a caller replace the template a stack executes, making the stack run attacker-chosen resource API calls as its service role.
cloudformation:UpdateStack changing only the stack's service role (--role-arn) to a more-privileged role: swaps the execution identity without modifying the template.
A principal with cloudfront:CreateDistribution can create new distributions pointing at any origin (S3 bucket, ALB, API Gateway, custom endpoint). If an S3 bucket has an overly-broad OAC policy grant (missing aws:SourceArn condition), the attacker can create a distribution to expose its contents publicly.
A Deployed CloudFront distribution is publicly reachable from the internet on its *.cloudfront.net domain (and any custom CNAME aliases).
A principal with cloudfront:UpdateDistribution can change origins, behaviors, WAF association, Lambda@Edge bindings, HTTPS policy, OAC/OAI, and trusted signers - altering the effective network posture and access controls of the distribution.
A principal with cloudfront:UpdateFunction and cloudfront:PublishFunction can modify CloudFront Functions code. While CloudFront Functions cannot call AWS APIs (no IAM escalation), modified code can forge trusted headers to origins, enabling application-layer bypass attacks.
A CloudFront distribution configured with OAC or OAI on an S3 origin can reach a private (non-public) S3 bucket on behalf of viewers. The distribution acts as a controlled gateway to otherwise-private data.
A CloudFront distribution can reach its configured origin (S3 bucket, ALB, API Gateway, or custom HTTP endpoint) over the network. This is a structural routing fact that feeds the network-chains linchpin.
A principal that can copy/share/restore a cluster backup duplicates the encrypted key material out of the source cluster.
A Crypto Officer credential can create a new CU or reset a CU password.
Holding a CloudHSM Crypto User credential (with VPC reach) lets a principal decrypt with the HSM key.
A CU with wrap rights can wrap an EXTRACTABLE key out of the HSM for offline use.