Supply Chain Security Checklist for Small Teams After xz

Intro — what this post promises

This supply chain security checklist for solo and small teams turns the 2024 XZ Utils backdoor (CVE-2024-3094) into four stages: pin dependencies by content, diff each release tarball against its git tag, generate an SBOM on every release candidate, and sign with Cosign, then verify at deploy. In the lab, the zlib v1.3.1 tarball diff took about two minutes and found no files missing from git, and a deliberate wrong-key Cosign verify failed as it should.

Related links:

• 01cisa.govCISA’s alert

ShopperCove already covered the story of that backdoor: xz-utils backdoor technical deep dive. This post is deliberately not another narrative retelling. It is the practical checklist you run on your deps and your releases when you do not have a dedicated AppSec team.

Related links:

• 01shoppercove.comxz-utils backdoor technical deep dive

You will get:

1. What xz actually taught practitioners (threat classes, not gossip).
2. A staged checklist: consume deps → build → release → deploy.
3. Concrete commands for tarball diffs, SBOM, Cosign, and SLSA-oriented provenance — run on a real dependency in lab.
4. Honest limits for a solo or three-person team.

Lab honesty: Numbers below are from a ShopperCove lab on 29 Sep 2026 (IST): zlib v1.3.1 (git 51b7f2ab…) release tarball vs git archive; Syft 1.18.1 SBOMs; Cosign v2.4.1 local key sign+verify with a deliberate wrong-key failure. Keyless Cosign hit Sigstore device-flow OIDC and could not complete on this box (no browser identity / no CI id-token). This was one careful afternoon on a shared Linux host — not a full GHCR + admission rollout (that belongs in a dedicated CI workflow lab).

What xz taught that checklists must capture

The artifact is not the git tree

The xz implant was not “just a bad commit someone forgot to review.” Attackers invested in build-time obfuscation and distribution of compromised release artifacts. If your CI only checks out git and never compares what users download from a release page, you miss a whole class of attacks.

Social trust is not a control

Maintainer takeover / multi-year social engineering is outside the reach of npm audit. Your checklist should assume identity of the human can be wrong, and compensate with reproducible process, signed provenance, and artifact comparison.

Detection still matters

Andres Freund’s discovery path (anomalous SSH/CPU behavior during unrelated work) is a reminder: runtime anomaly signals and fuzz/vetting (see our Lily / fuzz-based defense post) complement static gates. Checklist ≠ silver bullet.

Related links:

• 01shoppercove.comLily / fuzz-based defense post

Threat map — map controls to failure modes

Lab row (zlib v1.3.1): Release tarball had 0 files that were not in git. Four files existed only in git (.github workflows + .gitignore). All 253 shared files were byte-identical (cmp). Empty extras is a valid result — document it and keep the playbook.

Checklist stage 1 — consuming dependencies

Pin by content, not by floating tag

• Lockfiles committed (go.sum, package-lock.json, Cargo.lock, poetry.lock, …).
• Prefer digest pins for container base images (image@sha256:…) over mutable tags.
• Record upstream release URL + checksum for critical native libs.

Diff the tarball (non-optional after xz)

Pattern we ran on zlib v1.3.1:

git clone --depth 1 --branch v1.3.1 https://github.com/madler/zlib.git
cd zlib
git archive --format=tar HEAD | tar -tf - | sed 's|^\./||' | sort > /tmp/from-git.txt

curl -fsSL -L -o zlib-1.3.1.tar.gz \
  https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz
# SHA-256 we measured:
# 9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b72df23
tar -tzf zlib-1.3.1.tar.gz | sed 's|^zlib-1.3.1/||' | sed 's|/$||' | grep -v '^$' | sort > /tmp/from-tarball.txt

comm -13 /tmp/from-git.txt /tmp/from-tarball.txt   # only in tarball (extras)
comm -23 /tmp/from-git.txt /tmp/from-tarball.txt   # only in git
# Deeper: extract both trees; cmp each common file; diff -ruN

What we found:

Allowlist lesson: zlib’s maintainer release is a subset of the tagged tree (CI metadata stripped). That is the opposite of the xz-class failure (hidden extras in the dist). Still run the diff — an empty extras list is publishable evidence, not a skipped control.

Trap: GitHub’s auto-generated source archive (archive/refs/tags/v1.3.1.tar.gz) is a different blob (SHA-256 17e88863… in our lab) and still contains the CI files. Diff against the release asset distributors actually fetch, not the auto-archive.

Wall time once tools were present: about two minutes for clone + download + diff on this dependency.

Generate an SBOM on every release candidate

We used Syft 1.18.1. Inventory is the goal — not theater.

# Pinned in lab: syft 1.18.1
syft scan dir:./artifacts/from-tarball -o spdx-json > zlib-tree.spdx.json
# Bare zlib C sources: Syft reported no packaged components (expected).

syft scan dir:./mini-svc -o spdx-json \
  --source-name lab04-minisvc --source-version 0.0.1 > sbom.spdx.json
# Tiny Go release candidate (Go 1.24.4, github.com/google/uuid v1.6.0):
#   github.com/google/uuid @ v1.6.0
#   shoppercove.local/lab04-minisvc
#   stdlib @ go1.24.4

Store the SBOM next to the artifact you ship. An empty component list on a bare C tree is honest; the Go mini-service shows what a lockfile-backed release candidate looks like under the same tool.

Checklist stage 2 — building with provenance in mind

Prefer a hosted builder you do not personally admin

SLSA v1.0 Build track ladders roughly as:

Related links:

• 01slsa.devSLSA v1.0 Build track

Solo teams rarely “finish” L3 on day one. Aim first for L2-shaped habits: builds on GitHub Actions / GitLab CI / Google Cloud Build (or equivalent), provenance attached, verification in the same pipeline that ships.

Sign with Sigstore Cosign (keyless when possible)

Sigstore’s Cosign overview explains identity-based (“keyless”) signing: Fulcio issues a short-lived certificate binding an ephemeral key to an OIDC identity; Rekor records the signing event in a transparency log. That removes long-lived signing keys from your laptop’s ~/.ssh graveyard.

Related links:

• 01docs.sigstore.devSigstore’s Cosign overview

Lab — keyless limit (honest): cosign sign-blob --yes on the zlib tarball entered Sigstore’s device-flow OIDC (oauth2.sigstore.dev). This lab box has no browser session and no GitHub Actions id-token, so keyless could not complete. In CI, use something in this shape (pin action SHAs in production):

permissions:
  id-token: write   # for keyless OIDC
  contents: read
  packages: write
steps:
  - run: cosign sign --yes ghcr.io/ORG/APP@${{ steps.digest.outputs.digest }}
  # verify later with certificate-identity + certificate-oidc-issuer

Lab — local key sign + verify (completed with Cosign v2.4.1):

cosign generate-key-pair
cosign sign-blob --yes --key cosign.key \
  --output-signature zlib-1.3.1.tar.gz.sig zlib-1.3.1.tar.gz
cosign verify-blob --key cosign.pub \
  --signature zlib-1.3.1.tar.gz.sig zlib-1.3.1.tar.gz
# -> Verified OK (Rekor tlog index 3003501942 for the zlib blob in our run)

# Deliberate failure with a different pubkey:
cosign verify-blob --key wrong.pub \
  --signature zlib-1.3.1.tar.gz.sig zlib-1.3.1.tar.gz
# -> exit 1 (invalid signature)

We also signed the SPDX SBOM and a tiny Go binary the same way — three Verified OK results, one wrong-key exit 1. Verification mindset from Sigstore verify docs: check identity (who) and issuer (which OIDC provider) for keyless; for local keys, treat key distribution as the trust root you are trying to eliminate in production.

Related links:

• 01docs.sigstore.devSigstore verify docs

Checklist stage 3 — release and deploy gates

Minimum gate for anything internet-facing:

• CI built from a protected branch / required reviews
• SBOM artifact uploaded with the release
• Image/binary signed; verify step fails the job on mismatch
• Provenance attestation present for the production digest
• Deploy path rejects unsigned digests (cluster admission policy or CD verify step if you are not on Kubernetes)
• Dependency diff / advisory check for critical native libs this quarter

Measured time on this lab afternoon (not a multi-day CI migration):

Steady-state costs shrink once the playbook is scripted; do not treat the table above as a week-long AppSec hire substitute.

What this checklist does not claim

Related links:

• 01slsa.devSLSA levels

Worked mini-lab (ran 29 Sep 2026 IST)

Scenario: Critical native dep (zlib v1.3.1) consumed via release tarball; tiny Go service as a stand-in release candidate for SBOM + Cosign.

FAQ

Why diff a release tarball against git?

The xz backdoor lived in release tarballs, not the git tree. Comparing git archive output with the tarball users download catches extra build files that never appear in the repo.

Which tarball should I diff?

The release asset distributors actually fetch, not GitHub's auto-generated source archive. For zlib v1.3.1 the auto-archive was a different blob and still contained the CI files.

What SLSA level should a small team aim for?

Start with Build L2-shaped habits: builds on a hosted platform such as GitHub Actions, signed provenance attached, and verification in the same pipeline that ships. L3 rarely happens on day one.

More reading

• 01shoppercove.comxz-utils backdoor technical deep dive
• 02shoppercove.comNot Git Yard / fuzz-based defense
• 03shoppercove.comAbout ShopperCove
• 04cisa.govCISA alert on xz-utils / CVE-2024-3094
• 05slsa.devSLSA Build levels
• 06docs.sigstore.devCosign signing overview
• 07docs.sigstore.devCosign verify
• 08github.comzlib v1.3.1 release
• 09github.comSyft

Stay in touch

• Subscribe via RSS: Open shoppercove.com
• About the author / method: Open shoppercove.com