ArtifactRepository

Package/artifact registry (CodeArtifact/Artifacts/Artifact Registry).

class: Storage

Realizing resources

aws aws

resourcescopeenumeraterequired permissions
aws:codeartifact:repository regional codeartifact:ListRepositories codeartifact:ListRepositories
aws:codecommit:repository regional codecommit:ListRepositories codecommit:ListRepositories

Rules that touch ArtifactRepository 45

Copying a package version into a CodeArtifact repository via CopyPackageVersions injects code into every consumer of that repository - supply-chain CanModifyCode.
Deleting the CodeArtifact domain resource policy removes all access controls and opens the publish surface to all principals with domain access - CanModifyPolicy via deletion.
Deleting a CodeArtifact repository resource policy removes all access controls and opens the publish surface for that repository - CanModifyPolicy via deletion.
A CodeArtifact domain resource policy that names a principal in another account creates a CrossAccountTrust that, combined with that principal's identity-policy grants, enables cross-account package publishing into this domain.
CodeArtifact GetAuthorizationToken returns a short-lived bearer credential (up to 12 hours) for authenticated repository access - a credential-access primitive often exfiltrated from CI/CD environments.
Adding an external connection to a CodeArtifact repository can enable dependency confusion by allowing public-registry packages to be resolved by downstream consumers.
UpdateRepository can add a malicious upstream repository to a victim repository's upstream chain, enabling packages from the attacker's repository to be resolved by the victim's consumers.
Rewriting the CodeArtifact domain resource policy can grant arbitrary principals publish access to all repositories in the domain - CanModifyPolicy over the domain policy node.
Rewriting a CodeArtifact repository resource policy can grant arbitrary principals publish access to that repository - CanModifyPolicy over the repository policy node.
Publishing a package version to a CodeArtifact repository injects code into every consumer that installs the package - supply-chain CanModifyCode.
A CodeArtifact repository resource policy that names a principal in another account creates a CrossAccountTrust enabling cross-account package reads or writes to that repository.
Publishing to an upstream repository propagates CanModifyCode to every downstream repository in the upstream chain whose consumers resolve packages through it.
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.
Overwrite a template spec version to inject a deploymentScript into all deployments that reference it.
Data-plane: an admin client cert/Entra admin can provision an app type and create an application, running attacker code.
Attach a privileged user-assigned MI to a new/controlled SF app and deploy attacker code -> execute as the MI.
Admin client cert -> provision app + the app runs as an MI => execute as that MI.
Deploy/upgrade an SF app with attacker code + the app runs as an MI => execute as that MI via the localhost token service.
An Artifact Registry repo IAM allow policy that grants roles/artifactregistry.writer (or uploadArtifacts) to a service account from a different GCP project establishes cross-project trust - that SA can push to this project's registry.
A principal that can set a repo's IAM policy can self-grant roles/artifactregistry.writer and then push, reaching CanModifyCode on the repo via policy manipulation.
An Artifact Registry repo IAM binding for a Workload Identity Federation principalSet/principal with uploadArtifacts grants an external OIDC identity (e.g. GitHub Actions) direct push access - supply-chain from external CI into GCP workloads.
roles/source.admin grants full control over a CSR repository, including push, IAM policy mutation, and deletion - implies CanModifyCode, CanModifyPolicy, CanRead, and CanModifyConfiguration.
A CSR repo IAM binding that grants source.repos.update to a service account from a different GCP project establishes cross-project trust - that SA can push to this project's repository and arm Cloud Build triggers.
A principal that can set the repo IAM policy can self-grant roles/source.writer and then push commits - policy manipulation yields the same CanModifyCode as a direct writer binding.
A principal with source.repos.update can push commits to the CSR repository, including a modified cloudbuild.yaml - the code-supply-chain write primitive that arms any Cloud Build push trigger watching the target branch.
source.repos.get (clone/read) grants read access to the full repository content, including any secrets committed to history and build-spec files that reveal SA references and deployment targets.
source.repos.updateRepoConfig can relax branch-protection rules or change push configurations, potentially upgrading a CONDITIONAL CanModifyCode (gated by branch protection) to ACTIVE.
A CSR repo IAM binding for a WIF principalSet/principal with source.repos.update grants an external OIDC identity (e.g. GitHub Actions) direct push access without any long-lived GCP key - supply-chain injection from external CI.
Pushing/overwriting an image in a registry poisons every workload that pulls it - code control propagates from the registry to each consuming Compute/KubernetesWorkload.
move · open · esc close