Secure supply chain and delivery metrics
Your pipeline now ships the order service many times a week. That makes it a target: whoever controls the pipeline controls what runs in production. This lesson closes the main doors an attacker uses, proves which image is safe to run, and then measures whether delivery is really getting better, with the five DORA metrics.
By the end you can
- Trace where a supply-chain attack enters the order service pipeline and which control stops it
- Generate an SBOM, scan the image against a clear blocking policy, and keep exceptions time-boxed
- Sign the image by digest with keyless cosign, add provenance, and verify both before every deploy
- Compute the five DORA metrics from deployment, commit and incident data
- Use the metrics as a team, without turning them into targets for individuals
The everyday picture
Think about how a Mangrove distribution centre receives a pallet of baby formula. The receiving team does not trust a pallet because it arrived on a truck. They check that the seal on the cartons is unbroken and carries the supplier's stamp. They read the label that lists every ingredient and batch number. They check the recall list. They keep the delivery note that says which factory packed it and when. If any of these checks fails, the pallet does not reach a shelf.
Your container image is that pallet. The seal is a signature. The ingredient label is a software bill of materials. The recall list is the vulnerability database. The delivery note is provenance: which workflow built the image, from which commit. And the receiving team is your deploy step, which refuses anything that fails a check.
The DC manager also watches a few numbers every week: how often deliveries arrive, how long an order takes to reach the shelf, how many deliveries get rejected, and how fast a bad one is replaced. Delivery metrics for software work the same way.
Where attacks get in
A supply-chain attack gets into something you build with, such as a package or a CI step, and your own pipeline carries it to production for you. For the order service there are four common ways in.
- A compromised dependency. An attacker takes over an npm package (a stolen maintainer token is the usual way) and publishes a new version with a script that runs during install and sends the runner's secrets away. Every project that installs the new version runs it.
- A compromised action. A workflow step like
uses: some-org/tool@v1follows a tag, and tags can be moved. In March 2026, attackers rewrote most of the version tags of the official GitHub Action for the Trivy scanner for about half a day. Pipelines that referenced a tag ran code that stole their secrets. Pipelines pinned to a full commit SHA kept running the old, reviewed code. - A leaked token. A cloud key stored as a repository secret, printed in a log or pasted into code works for anyone who finds it, often for years.
- A swapped image. Someone with write access to the registry points the tag
1.8.0at a different image. The cluster pulls the tag and runs it.
Deploying and securing with GitHub Actions already covers the first-line controls in detail: permissions: {} with per-job grants for the GITHUB_TOKEN, pinning third-party actions to a full commit SHA, OIDC instead of stored cloud keys, secret scanning with push protection, and Dependabot. Here we build on them. The figure maps each way in to the control that stops it.
Two details matter more than they look. First, a pin only protects what you pinned. If you pin a composite action by SHA, but its own action.yml calls another action by tag, that inner tag is still resolved at run time. Read what a third-party action calls before you trust it. Second, the lockfile is your dependency pin. npm ci installs exactly the versions in package-lock.json and checks each package against the integrity hash stored there, so a new malicious version reaches CI only when someone changes the lockfile. A cooldown on dependency updates delays that change by a few days, and most malicious versions are found and pulled within that time. npm audit signatures adds a check that the packages you installed carry valid registry signatures.
If a secret does leak, revoke or rotate it first, then clean up. Deleting the commit or rewriting history does not help: forks, clones and caches may already have it.
Quick check
A package the order service depends on publishes a new patch version with a script that steals secrets. The repo commits package-lock.json, CI runs npm ci, and Dependabot has a 5-day cooldown. When does the bad code first run in CI?
npm ci installs exactly what the lockfile says and fails if package.json and the lockfile disagree, so a new version needs a lockfile change. The cooldown gives the community a few days to spot and pull the bad version. The registry does not guarantee that packages are safe.