I've seen some high-profile examples of software supply chain attacks, like the SolarWinds compromise in 2020 and the Log4Shell vulnerability in 2021, which show that the supply chain is a significant attack surface

What makes supply chain attacks so effective is that they compromise software or infrastructure used to build or distribute other software, allowing attackers to breach organisations indirectly by targeting dependencies

The SolarWinds attack is a prime example, where the build system was compromised and a malicious update was distributed as a legitimate signed software update, highlighting the need for better supply chain security

One lesson I learned the hard way is that a signed update is only as trustworthy as the key protecting it. In early 2021 the Codecov Bash uploader token was leaked from a CI environment, and attackers used it to inject a malicious payload into the upload step of thousands of projects. The incident forced us to move the signing keys into a hardware security module and enforce short‑lived signing certificates. In production we now rotate keys every 30 days and audit every signing event; the extra operational overhead paid off when a later attempt to replace a container image was caught because the signature no longer matched the current key.

A Software Bill of Materials, or SBOM, is a crucial component in securing the supply chain, as it provides a structured list of all components in a piece of software, including direct and transitive dependencies, versions, and licences

Generating an SBOM for a large monorepo is not free. Using Syft to produce a CycloneDX document for a codebase of about 1.2 million lines and roughly 45 k components took close to seven minutes on a standard CI runner and added a 12 MB JSON file to the artifact store. We built a diff step that compares the new SBOM against the previous build; the diff usually surfaces a few hundred new components, which we then feed into our risk model. The storage cost is modest, but the CPU time can become a bottleneck if you run it on every pull request.

With an SBOM, you can identify vulnerable components in your software, which is why the US executive order on cybersecurity in May 2021 required SBOMs for software sold to the federal government, driving adoption and improvement in supply chain security

Dependency scanning in CI/CD pipelines is another key defence mechanism, with tools like GitHub Dependabot, Snyk, and OSV Scanner scanning dependencies against vulnerability databases and opening pull requests for updates

However, the challenge lies in filtering out noise from genuine risk, as a typical Node.js project has thousands of transitive dependencies, requiring either automated vulnerability severity thresholds or manual triage by a security team

Scanning every dependency on every commit quickly turns into a signal‑to‑noise problem. In a typical Node.js service we see around 6 k transitive packages and the scanner flags about 120 CVE entries per run. Only a handful—usually those with a CVSS score above 7.0 and an exploit in the wild—require immediate action. We tuned Snyk’s policy engine to auto‑fix low‑severity issues and raise a ticket for the rest, which cut the manual triage time from a few hours to under thirty minutes per day.

To establish trust in the supply chain, software signing with tools like Sigstore provides cryptographic proof that a build output was produced by a specific build system at a specific time from specific source code, while cosign provides signing and verification for container images and npm and PyPI added provenance support in 2023