The distribution chain problem is the gap between the source code people review and the artifact people actually install. If an attacker alters a tarball, a container image, an action or an extension after review, the reviewed code no longer describes what runs.
What does the gap look like in practice?
Two cases show it. In March 2024 a developer reported that upstream xz and its release tarballs had been backdoored. His report says one portion of the backdoor lived solely in the distributed tarballs for 5.6.0 and 5.6.1, and was not in the upstream source tree used by the project in git. CISA's alert assigned CVE-2024-3094 and recommended downgrading to an uncompromised version such as 5.4.6.
In April 2026, according to Trend Micro's analysis, the actor behind a campaign poisoned three distribution channels at once for KICS: Docker Hub, the VS Code and OpenVSX extension marketplaces, and GitHub Actions. Reading the same incident, one practitioner write-up of the vendor's bulletin reports a Docker image window of under thirty minutes. The code in the source repository was not the problem. The channel was.
Why is the channel so attractive?
Because it is trusted and unobserved. Few teams diff a release tarball against its git tag. Few pin an Action to a commit. Even fewer record which image digest a pipeline pulled at which time. A short window of poisoning reaches everyone who pulls during it, and the pipeline that pulls often holds the most valuable credentials.
What controls shrink the gap?
SLSA is built for this. Its build track measures how trustworthy provenance is: Build L1 means provenance exists and shows how a package was built, L2 means signed provenance from a hosted build platform, which protects against tampering after the build, and L3 means a hardened build platform that protects against tampering during it. A consumer compares an artifact's actual provenance to what is expected.
Add three habits on the consuming side:
- pin by digest or commit, not by tag or branch;
- verify signatures and provenance where the ecosystem offers them;
- restrict what a build step can reach, so one poisoned download cannot read every secret.
What would this have changed?
Constructed example: a team pulls a scanner image by its latest tag in CI, and the job has a cloud deploy key in its environment. If latest is poisoned for thirty minutes, any run in that window leaks the key. If instead the team pinned a digest recorded last month, runs in the window would still use the old, clean image. If the key were short-lived and scoped, even a leak would be small.
Why do build tools deserve the same scrutiny as dependencies?
Most teams review the libraries in their application and ignore the tools that build it: scanners, linters, Actions, base images, editor extensions. Those tools run with access to source and secrets, and they update often, sometimes automatically.
Treat them as dependencies. Keep a list, pin versions, and review changes. The KICS case is a reminder that a security tool is software from a supply chain like any other. The aim is not distrust of tools. It is to make sure that one bad update has a small blast radius.
What to do
- Pin container images by digest and Actions by full commit hash.
- Record, in each build log, the digests and versions actually pulled.
- Verify provenance for artifacts that offer it, and ask suppliers to publish it.
- Compare release artifacts to source for critical dependencies when feasible.
- Give build steps short-lived, minimal credentials.
- Keep a list of your distribution channels: registries, marketplaces, Actions, extensions.
- Subscribe to advisories for the tools your pipeline itself downloads.
Safeguard's policies and gates and SBOM and dependency scanning can enforce version and source rules in the pipeline. No tool removes the need for pinning and least privilege.
Quick check
Is pinning by tag enough?
No. A tag can be moved to different content. A digest or commit hash identifies exact content.
Does signed provenance prove the code is safe?
No. It shows how and where an artifact was built. A malicious build from a legitimate pipeline still has valid provenance.
Sources
- Andres Freund, backdoor in upstream xz/liblzma (oss-security, 29 March 2024)
- CISA alert, Reported Supply Chain Compromise Affecting XZ Utils, CVE-2024-3094
- Trend Micro, Analyzing TeamPCP's Supply Chain Attacks (13 May 2026)
- Stéphane Robert, Checkmarx KICS compromised
- SLSA specification v1.0: levels and tracks
Last reviewed: 18 October 2026.
