Wiz Details CI/CD Misconfigurations That Can Enable Cloud Supply-Chain Attacks
Summary
Wiz describes how overprivileged container registries, forgotten build secrets, and links between production and CI/CD environments can expose software supply chains, and recommends least privilege, secret scanning, and network isolation.
Key points
- Compromised containerized instances or pods may expose registry credentials, allowing attackers to access private images or overwrite production images if credentials permit writes.
- Secrets left in build artifacts, image layers, bash history, or logs can enable lateral movement and tampering with artifacts.
- The article describes the Hell’s Keychain attack as an example of inadequate network controls exposing an internal CI/CD repository.
- Restrict registry permissions and scope pull and push access to the repositories and pipeline stages that require it.
- Limit pod service-account privileges and access to container-registry secrets.
- Regularly scan production artifacts, image layers, and metadata for forgotten secrets.
- Isolate CI/CD assets with network policies, restrict credentials and storage buckets to the CI/CD network, and avoid storing service credentials in internet-facing applications.
Article Details
- Defense Focus
- Reduce CI/CD supply-chain attack risk by limiting access to container registries and secrets, scanning build artifacts, and isolating production environments from internal build systems.
- Detection Methods
- Regularly scan environments and production artifacts for forgotten secrets during the final phase of each artifact build.
- Scan all container image layers and metadata files, including historical build commands and filesystems that may be hidden after squashing.
- Monitor cloud access keys in internet-facing environments and verify they do not grant access to CI/CD environments.
- Data Sources
- Container image layers and metadata
- Linux bash history files, including ~/.bash_history and /root/.bash_history
- AWS SSM logs at /var/log/amazon/ssm/*
- Linux journal files at /var/log/journal/*
- Cloud access keys, service credentials, and access tokens
- Container registry permissions and image-pull secrets
- Cloud identities, storage bucket policies, and network access controls
- Platforms
- CI/CD environments
- Container registries
- Kubernetes
- Cloud environments
- SaaS CI/CD solutions
- Defensive Actions
- Apply least privilege to container registry roles; scope pull and push permissions to required repositories and images.
- Limit registry push privileges to roles involved in the final CI/CD pipeline phase, and avoid granting unnecessary resource-listing permissions.
- Restrict pod service-account privileges and access to container registry secrets.
- Scan secrets in artifacts, image layers, and metadata; remove exposed credentials and prevent them from being retained in production artifacts.
- Use strong network policies and cloud segmentation to isolate critical assets and restrict storage buckets and cloud identities to the CI/CD virtual network.
- Do not store service credentials or access tokens in internet-facing applications when network access to a SaaS CI/CD service cannot be restricted.
- Use two-factor authentication and role-based access controls for SaaS CI/CD solutions.
MITRE ATT&CK
T1078 · Valid AccountsStolen cloud or registry credentials are used to access private images, storage buckets, or CI/CD resources.T1195.002 · Compromise Software Supply ChainThe article describes modifying build artifacts or container images to spread malicious code through software builds and downstream services.T1213 · Data from Information RepositoriesWith registry credentials, an attacker can retrieve and inspect private container images for proprietary code and secrets.T1528 · Steal Application Access TokenA Kubernetes service account token is used to retrieve a container registry secret from the cluster.T1552.001 · Credentials In FilesThe described attack obtains cloud and CI/CD credentials from files such as .bash_history and container image layers.T1552.007 · Container APIThe described attack retrieves a Kubernetes service account token from a compromised pod's filesystem.T1570 · Lateral Tool TransferThe described scenarios use compromised credentials to move from an internet-facing system or pod to registry, storage, or CI/CD resources.T1613 · Container and Resource DiscoveryThe case study describes compromising a pod in an internet-facing application as a step toward accessing registry secrets.
Products
CircleCIThe code is automatically built and tested using continuous integration (CI) tools, like Jenkins and CircleCI.GitHubIn cases of SaaS CI/CD solutions like GitHub where network access is impossible to curb, it is critical that no service credential or access token be stored in internet-facing applications. If an attacker managed toIBM Cloudallowed researchers to access an internal CI/CD repository. This misconfiguration is not unique to IBM Cloud, as it has been observed across multiple cloud providers and their customers. In our view, this issue isJenkinsThe code is automatically built and tested using continuous integration (CI) tools, like Jenkins and CircleCI.KubernetesIn order to pull private images, a Kubernetes node must have access to the container registry in which they are stored. The credentials to this container registry are found in a secret resource. The secret’s name is