Derivation rules

servicecatalog:UpdateConstraint + iam:PassRole(servicecatalog.amazonaws.com) on a LaunchRole constraint: replace the launch role bound to a product with a more privileged role. The next ProvisionProduct executes as the new launch role. can-execute-as execute-as-via-config-identity-swap propagates with CanPassIdentity to derive CanExecuteAs.

ssm:StartChangeRequestExecution triggers an Automation runbook with Change Manager approval gating.

A shared SSM Automation document gives the sharing-account identity code control over any BuildWorker in the target account that executes it.

ssm:StartAutomationExecution triggers an existing Automation BuildWorker runner that executes as its AutomationAssumeRole.

ssm:UpdateDocument rewrites a customer-owned Automation document's steps - the executed definition of the BuildWorker runner.

registries/taskRuns/write queues a manual run of an existing ACR Task - triggers execution of whatever the current task definition specifies as the task's MI.

tasks/write over an ACR Task - modifies build steps (the BuildWorker's code) that run as the task's MI.

Principal holds assign/action on a UAMI and deploymentScripts/write - can bind the UAMI to a new or existing deploymentScript, making it the script's execution identity.

An Automation Account sandbox job exposes its bound MI's token to any code it runs via the IMDS endpoint.

A blueprint definition containing a role-assignment artifact grants RBAC at the deployment scope when the assignment executes - the assigner effectively controls who gets RBAC at that scope.

A Key Vault-linked variable group exposes Azure Key Vault secrets to pipeline runs; the pipeline's service-connection identity must hold Key Vault Secrets User RBAC.

Write access to the CI-trigger branch of the pipeline's source repo lets a principal inject code that the pipeline will execute on the next triggered run.

DevOps 'Manage service endpoints' permission lets a principal bind a different - potentially more privileged - service connection to a pipeline, changing its execution identity.

An ARM service connection (secret-based) injects the backing SP's client secret / certificate into the job environment; pipeline code can read and exfiltrate it.

A pipeline stage that uses DownloadSecureFile@1 (or equivalent) materializes the secure file on the agent disk; pipeline code can read the certificate, SSH key, or credential file.

Write to a shared YAML template repo/branch that a pipeline imports via 'extends: template', injecting code into all downstream pipelines that use it.

A pipeline that references a non-Key Vault variable group has the group's secret variables injected into every job's environment; pipeline code can read and log them.

A policy assignment with a system-assigned managed identity produces an ExecutesAs edge: remediation tasks run as that system MI. Extracted from the assignment's identity.principalId field.

A policy assignment with one or more user-assigned managed identities produces ExecutesAs edges for each. Extracted from the assignment's identity.userAssignedIdentities map (keys are MI resource IDs).

Write a policy assignment with deployIfNotExists or modify effect, specifying a managed identity (system- or user-assigned) that the remediation engine uses to deploy ARM templates or modify resources. This is modeled as CanModifyConfiguration on the remediation task (BuildWorker): writing the assignment modifies the identity binding and ARM template that the remediation task will execute. Downstream, can-execute-as execute-as-via-config-identity-swap combines this with CanPassIdentity(MI) to derive CanExecuteAs(MI).

An Azure Policy remediation task (modeled as BuildWorker - the ARM deployment runner) executes as the managed identity bound in the policy assignment's identity block. Zero-cost structural fact; can-execute-as execute-as-via-code-modify and cicd-chains cicd-modify-buildspec-executes-as consume this to produce CanExecuteAs.

Explicitly trigger a policy remediation task via Microsoft.PolicyInsights/remediations/write; the remediation executes as the assignment's bound MI. This is a direct trigger path that does not require policyAssignments/write if the assignment already has a remediation MI configured.

Repoint SWA's source repository to an attacker-controlled repo, modifying build code.

A holder of the SWA deployment token can modify the build runner's deployment when a runner with a service identity exists.

Modify the buildspec/pipeline/runbook/template a runner executes, then run it, to execute as the runner's service identity.

Triggering a pipeline reaches each downstream stage runner it orchestrates; propagate CanTrigger to those runners.

Trigger/start a runner whose current definition already runs attacker-influenced code, executing as the runner's identity.

A Cloud Build trigger's builds execute as the configured service account (or the legacy SA if none is set).

All Cloud Build steps can mint OAuth tokens for the build SA from the GCE metadata server; code execution in any step yields the build SA's credentials.

A principal with pubsub.topics.publish on a trigger's configured Pub/Sub topic can fire that trigger, potentially executing code as the trigger's SA.

Re-pointing a target's executionConfigs SA (targets.update + actAs) then promoting a rollout yields code execution as the newly attached SA.

clouddeploy.automations.create with a promoteReleaseRule or advanceRolloutRule schedules automatic rollout creation, effectively giving CanTrigger over the deploy Cloud Build worker.

A Cloud Deploy target's execution SA from a different project establishes a cross-project trust enabling CanEnterProject on that SA's home project.

Cloud Deploy job run worker (Cloud Build) executes as the target's configured execution service account.

Write access to the Cloud Deploy pipeline's GCS source bucket allows injecting malicious skaffold.yaml into every render job.

Create a Cloud Deploy release with attacker-controlled Skaffold config + actAs(render SA) → execute arbitrary code as the render SA inside the Cloud Build worker.

clouddeploy.releases.create with actAs on the render SA injects attacker-controlled Skaffold config/hooks into the render Cloud Build worker.

clouddeploy.rollouts.approve unblocks a NEEDS_APPROVAL rollout, triggering the deploy Cloud Build worker (no actAs required).

clouddeploy.rollouts.create (promotion) with actAs on the deploy SA triggers the deploy Cloud Build worker running as the deploy SA.

Promote a Cloud Deploy release (rollouts.create) + actAs(deploy SA) → deploy Cloud Build worker executes as the deploy SA, which has runtime control over the target (GKE/Cloud Run).

clouddeploy.targets.update + actAs(execution SA) re-points all future Cloud Deploy job runs on this target to execute as the chosen SA.