Software supply chain security

What is the software supply chain?

The software supply chain is everything that goes into what you ship: your own code, the open-source packages you install, the packages those packages install (transitive dependencies), the base image in your Dockerfile, the build tools, the CI runners and the reusable actions in your workflows. A small Node.js API with 20 direct dependencies often pulls in several hundred transitive ones. Any of them can carry a vulnerability (a weakness an attacker could use) or, rarely, malicious code.

Real incidents show why this matters. Log4Shell (December 2021) was a critical flaw in the Log4j logging library used inside thousands of Java products. In 2024 a backdoor was found in the xz compression tool before it reached most stable Linux releases. In March 2025 the tags of a popular GitHub Action, tj-actions/changed-files, were moved to a malicious commit that printed CI secrets into build logs.

SCA and lockfiles

SCA (software composition analysis) lists your dependencies and compares them with vulnerability databases, such as CVE records, the GitHub Advisory Database and OSV. A CVE (Common Vulnerabilities and Exposures) ID is a public name for one known vulnerability, like CVE-2021-44228 for Log4Shell. Tools include Dependabot, Snyk, OWASP Dependency-Check, Trivy, npm audit and pip-audit.

A lockfile (package-lock.json, poetry.lock, go.sum) records the exact version and a hash of every dependency, including transitive ones. Commit it, and install from it in CI (npm ci rather than npm install), so every build uses exactly the same, checked packages.

Typosquatting and dependency confusion: the defences

Typosquatting is publishing a harmful package with a name close to a popular one, hoping someone mistypes it. Dependency confusion happens when a company uses a private package name, and a public package with the same name and a higher version gets installed instead because the package manager checks the public registry too.

• Use scoped or namespaced packages for internal code (for example @acme/payments) and point that scope at your private registry.
• Use one internal registry proxy (such as Artifactory, Nexus, GitHub Packages or Azure Artifacts) as the only source for builds.
• Commit lockfiles with integrity hashes, and review every new dependency in the pull request: who maintains it, how popular it is, when it was last updated.

The scanning family

SBOMs: the ingredients list

An SBOM (software bill of materials) is a machine-readable list of every component and version inside your software, like the ingredients list on a food packet. The two main formats are SPDX (from the Linux Foundation, also an ISO standard) and CycloneDX (from OWASP). Governments and large customers increasingly ask for SBOMs: the US government pushed for them after a 2021 executive order, CERT-In published SBOM guidelines in India in 2024, and the EU Cyber Resilience Act requires them from product makers. The practical reason is simple: when the next Log4Shell is announced, an SBOM answers "are we affected?" in minutes instead of days.

syft ghcr.io/acme/canteen-api:3f9c2ab -o spdx-json > sbom.spdx.json      # make an SPDX SBOM
trivy image --format cyclonedx --output sbom.cdx.json ghcr.io/acme/canteen-api:3f9c2ab
grype sbom:./sbom.spdx.json                                               # scan the SBOM for known vulnerabilities

Signing, provenance and SLSA

Signing proves an image came from you and was not changed. cosign, from the Sigstore project, signs container images and stores the signature next to the image in the registry. It also supports keyless signing, where the CI job's OIDC identity is used instead of a long-lived key and the signature is recorded in a public transparency log. Your cluster or deploy job then verifies the signature before running the image.

cosign sign --key cosign.key ghcr.io/acme/canteen-api@sha256:4a1f...e9
cosign verify --key cosign.pub ghcr.io/acme/canteen-api@sha256:4a1f...e9

Provenance is a signed record of how an artefact was built: which source commit, which build system, which steps. SLSA (Supply-chain Levels for Software Artifacts, said "salsa") is a framework whose build levels describe how trustworthy that provenance is, from "provenance exists" up to "built on a hardened, isolated build platform".

Pin by digest, update with bots

A tag like node:22-slim or actions/checkout@v7 can be moved to point at different content. A digest (sha256:...) or a full commit SHA cannot. Pin base images by digest and third-party actions by full commit SHA, with the version in a comment. Then let Dependabot or Renovate open small pull requests to update the pins, so you stay pinned and current.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"