Simulating a Supply Chain Attack: Red Team TTPs for Build Pipeline Compromise

Cybersecurity

SolarWinds, XZ Utils, and 3CX all started in the build pipeline. A structured simulation methodology for red teams to test whether their client's supply chain can be compromised — and whether defenders would notice.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 8, 2025 · 11 min read

Supply chain attacks are attractive to adversaries because a single compromised build tool can propagate malicious code to thousands of downstream consumers before anyone notices. Red teams rarely simulate this threat class because the blast radius feels unacceptably large. It does not have to be — with careful scoping and a simulated payload that does nothing harmful, you can test every detection control without touching production.

Scoping the Simulation

Define the injection point before engaging. Options include: a compromised open-source dependency (typosquatting simulation), a backdoored internal package in a private registry, a tampered build script in CI configuration, a poisoned Docker base image, and a compromised developer workstation that injects during local build. Each requires different detection controls and different simulation mechanics.

Simulating a Dependency Confusion Attack

Create an internal package name that matches a common naming pattern (e.g., @companyname/utils). Publish a public package on npm or PyPI with the same name at a higher version number. The package payload should only log a beacon to a controlled server — no destructive code. Observe whether the build system installs the public version over the internal one. Verify whether Dependabot, Snyk, or internal scanning catches the substitution.

CI/CD Pipeline Injection

Most CI/CD systems pull untrusted code and execute it with secrets in environment variables. Fork the target repository and add a malicious step to the GitHub Actions workflow. If the pipeline runs on pull requests from forks, it may execute your code with access to repository secrets. Test by submitting a PR with a workflow step that prints the masked secret — if the output shows asterisks, secrets are present but masked; if it shows the value, the secret is fully exposed.

Build Artifact Tampering Simulation

After a legitimate build completes, attempt to push a modified artifact to the artifact registry using stored CI credentials. In AWS, test whether the CI role can push to S3, ECR, or CodeArtifact without any approval gate. In GitHub, test whether a developer with write access can directly push a signed release tag without triggering a required review. SLSA Level 2 and above prevents this by requiring the build provenance attestation to be generated by the pipeline itself, not a human.

Detection Engineering Test Cases

• Alert on new public package with same name as internal package — package registry webhook or Snyk supply chain monitor.
• Alert on CI job accessing secrets outside declared environment — GitHub Advanced Security secret scanning in logs.
• Alert on artifact push from human identity rather than CI service account.
• Alert on unsigned container image being pulled into staging.
• Alert on dependency version pinning being removed in a PR.

Reporting Findings

Supply chain simulation findings should be mapped to SLSA levels and MITRE ATT&CK T1195 (Supply Chain Compromise) sub-techniques. For each gap, specify the minimum control required: artifact signing (Sigstore/Cosign), dependency pinning with integrity hashes, build provenance attestation, and registry admission policies that reject unsigned images.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.