Episode 47 · Module 10 · Infrastructure

Supply Chain Security — Dependencies, SBOM and Build Provenance

19 May 2026 · 8:47 · Security for Legal SaaS

8:47 8:47

A modern legal SaaS platform — a contract review tool, a case management system, a document automation service — is built on hundreds or thousands of open-source packages. The Express web framework. React for the frontend. A PDF parsing library. An encryption library. An ORM for database access. Each of those packages depends on other packages, which depend on others still. A typical Node.js application has between 500 and 1,500 transitive dependencies — packages your code never imports directly but which are pulled in by packages you do use.

Today’s Lesson

Security for Legal SaaS — Episode 47: Supply Chain Security — Dependencies, SBOM and Build Provenance

You Didn't Write 95% of Your Application's Code

You didn't audit those dependencies. You probably haven't read their source code. And yet they run with the same privileges as your own code, processing the same client data, accessing the same databases.

Software supply chain attacks more than doubled globally in 2025 ¹, with over 70% of organisations reporting at least one incident linked to third-party software. Global costs reached $60 billion and are projected to hit $138 billion by 2031. The attacks are not hypothetical. They have names.

The Attacks That Changed Everything

SolarWinds (2020)

Attackers compromised the build system for SolarWinds' Orion network monitoring platform. They injected a backdoor — called SUNBURST — into legitimate software updates. Over 18,000 organisations, including US government agencies, installed the compromised update through their normal patch management process. The attack was not in the source code repository. It was injected during the build process itself, making it invisible to code review.

Log4Shell (2021)

Log4Shell (CVE-2021-44228) ² was a critical remote code execution vulnerability in Log4j — a ubiquitous Java logging library. The vulnerability existed for years in a library that was a transitive dependency of thousands of applications. When disclosed, many organisations could not even determine whether they were affected, because they didn't know Log4j was buried in their dependency tree.

xz-utils (2024)

A threat actor spent years building trust as a maintainer of the xz compression library — a critical component in virtually every Linux distribution. After gaining commit access through sustained social engineering, they injected a sophisticated backdoor into the library. The attack targeted OpenSSH authentication and was discovered by accident when a developer noticed unusual performance characteristics. The code had already been included in several Linux distribution pre-release builds.

The pattern: SolarWinds attacked the build process. Log4Shell exploited a hidden transitive dependency. xz-utils compromised a trusted maintainer. Three different vectors, one lesson: your software supply chain is an attack surface, and you cannot secure it by trusting people or processes you don't verify.

Software Bill of Materials (SBOM)

An SBOM is a comprehensive inventory of every software component in your application — direct dependencies, transitive dependencies, their versions, licences, and origins. It answers the question Log4Shell made urgent: what's actually in our software?

The US Executive Order 14028 on Improving Cybersecurity ³ requires SBOMs for federal software procurement. CISA's 2025 minimum elements ⁴ for an SBOM include: author, supplier, component name, version, dependencies, unique identifier, and timestamp.

Two standard formats dominate:

Format	Origin	Best For
SPDX	Linux Foundation	Licence compliance + security
CycloneDX	OWASP	Security-focused, includes vulnerability data

Generating an SBOM is now a single command in most ecosystems:

bash

# Node.js
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Python
cyclonedx-py requirements --format json -o sbom.json

For legal SaaS platforms, the SBOM serves multiple purposes. Security teams use it to track which components have known vulnerabilities. Legal teams use it to verify licence compliance — an open-source library with an AGPL licence in your proprietary SaaS product is a legal risk, not just a technical one. And when a new vulnerability is disclosed, the SBOM lets you answer "are we affected?" in minutes instead of days.

Dependency Scanning — Automated Vigilance

An SBOM tells you what you have. Dependency scanning tells you what's wrong with it. Tools like Dependabot ⁵, Snyk ⁶, and OSV (Open Source Vulnerabilities) ⁷ continuously monitor your dependencies against vulnerability databases and alert you — or automatically create pull requests — when a vulnerability is found.

The Practical DevSecOps guide to SBOM vs SLSA ⁸ emphasises that dependency scanning must be continuous, not one-time: "An SBOM generated at build time captures a snapshot. Continuous scanning catches vulnerabilities discovered after deployment."

A practical dependency scanning policy:

Automated PR updates — tools like Dependabot create pull requests for dependency updates. Review and merge them promptly.
Vulnerability thresholds — block deployments with critical or high CVEs. Set deadlines for medium CVEs.
Licence scanning — flag dependencies with incompatible licences before they reach production.
Transitive dependency auditing — don't just scan your direct dependencies. Scan the full tree. Log4Shell was a transitive dependency in most affected applications.

Lock Files and Reproducible Builds

A lock file (e.g., `package-lock.json` for npm, `poetry.lock` for Python, `Cargo.lock` for Rust) records the exact version of every dependency — direct and transitive — that was used when the application was last built and tested. Without a lock file, running `npm install` on two different machines might install different dependency versions, because version ranges (`^1.2.3`) allow minor and patch updates.

This is not just a reliability concern. It is a security concern. If an attacker publishes a malicious version of a dependency that falls within your version range, and your build process does not use a lock file, the malicious version can be pulled in silently.

Always commit your lock files to version control. Always use deterministic install commands (`npm ci`, not `npm install`) in your CI/CD pipeline. This ensures that you deploy exactly what you tested — not whatever the latest published version happens to be.

Build Provenance — SLSA and Signed Attestations

SBOMs tell you what is in the software. SLSA (Supply-chain Levels for Software Artifacts) ⁹ tells you how the software was built — and whether you can trust that the build process was not tampered with. SLSA defines four levels of build integrity:

Level	Requirements	What It Proves
SLSA 1	Documentation of the build process	You know how it was built
SLSA 2	Build service generates signed provenance	Tamper-evident build record
SLSA 3	Hardened build platform, non-falsifiable provenance	Build process itself is protected
SLSA 4	Two-person review, hermetic builds	Highest assurance of build integrity

SLSA Level 2 is achievable for most teams in two to four weeks ¹ using hosted build services like GitHub Actions or Google Cloud Build. At Level 2, the build service generates a signed provenance attestation — a cryptographic document recording what source code was built, by which build system, producing which artifacts. This is the build-process equivalent of the AI output provenance chains we discussed in Episode 43.

Sigstore ¹⁰ provides the infrastructure for keyless signing of both build provenance and artifacts. The build system authenticates via its OIDC identity (the same OpenID Connect we covered in Episode 20), receives a short-lived certificate from Fulcio (Sigstore's certificate authority), signs the provenance attestation, and records the signature in Rekor (Sigstore's tamper-evident transparency log). No long-lived keys to manage, rotate, or leak.

The Legal Exposure

When a dependency in your legal SaaS platform has a known vulnerability and you shipped it anyway, the question is no longer just technical — it's legal. Research on supply chain security obligations ¹¹ notes that awareness of a vulnerability coupled with failure to remediate creates a duty-of-care exposure. If a breach exploits a CVE that was publicly disclosed months before your patch, your response to "why wasn't this fixed?" needs a better answer than "we didn't know it was in our dependency tree."

ABA Model Rule 1.6(c) requires reasonable efforts to prevent unauthorised access to client information. Running a legal SaaS platform with known, unpatched vulnerabilities in your dependencies is difficult to characterise as "reasonable efforts." An SBOM and continuous dependency scanning are your evidence that you took the supply chain seriously.

Key takeaway: You own the security of every line of code in your application — including the code you didn't write. SBOMs give you visibility. Dependency scanning gives you alerts. Lock files give you reproducibility. SLSA and Sigstore give you build provenance. Together, they transform your supply chain from a blind spot into a managed risk. Without them, you are shipping software you cannot fully describe, built from components you cannot fully verify.

What's Next

Next episode, we look at environment configuration and secure defaults — how to ensure that the difference between your staging and production environments is credentials and scale, not security controls.

Sources & references

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 47 — supply chain security. Alice, this is a topic that's been in the news a lot. SolarWinds, Log4Shell, xz-utils. But before we get to those, let's set the stage. What does "supply chain" mean in a software context?

Alice: Think about your legal SaaS platform — a contract review tool, a case management system, whatever you're building. You wrote the business logic. But you didn't write the web framework. You didn't write the PDF parser. You didn't write the encryption library or the database driver. A typical application has hundreds, sometimes over a thousand, third-party packages that it depends on. And each of those packages depends on other packages. Those are your supply chain. You didn't write 95% of the code in your application, but it all runs with the same privileges, accessing the same client data.

Dan: Mm. That's a lot of code you're trusting without having read it.

Alice: Exactly. And three major incidents in the last few years showed what happens when that trust is misplaced. SolarWinds in 2020 — attackers compromised the build system for a network monitoring tool. They injected a backdoor into the legitimate software update. Over 18,000 organisations installed it, including US government agencies. The backdoor wasn't in the source code. It was injected during the build process, so code review wouldn't have caught it.

Dan: Right. And Log4Shell?

Alice: December 2021. A critical vulnerability in Log4j — a Java logging library. The scary part wasn't just the vulnerability itself. It was that thousands of organisations couldn't even figure out if they were affected, because Log4j was buried deep in their dependency trees. It wasn't a library they'd imported directly. It was a dependency of a dependency of a dependency. They didn't know it was there.

Dan: Mm-hmm. And xz-utils was different again, right?

Alice: <sigh> That one is the most unsettling. A threat actor — going by "Jia Tan" — spent years building trust as a contributor to xz-utils, a compression library used in virtually every Linux distribution. After gaining maintainer access through sustained social engineering, they injected a sophisticated backdoor targeting SSH authentication. It was discovered by accident when a developer noticed strange performance behaviour. The code had already been included in several Linux distribution pre-release builds. Years of patience for a single supply chain attack.

Dan: Hmm. Three different attack vectors. So how do you defend against this?

Alice: Step one — know what you have. That's where an SBOM comes in. S-B-O-M — Software Bill of Materials. It's a comprehensive inventory of every component in your application. Every direct dependency, every transitive dependency — that's the dependencies of your dependencies — their versions, their licences, their origins. Think of it as a list of ingredients on a food label. You can't manage what you can't see.

Dan: Right. And this is now a requirement for government software, isn't it?

Alice: Yes. US Executive Order 14028 requires SBOMs for federal software procurement. CISA published minimum elements in 2025 — component name, version, supplier, dependencies, unique identifier, and timestamp. Generating one is a single command in most ecosystems. For a Node.js project, you run a CycloneDX tool and get a JSON file listing every package. For legal SaaS, the SBOM serves security teams tracking vulnerabilities, legal teams checking licence compliance — you don't want an AGPL-licensed library in your proprietary product — and incident responders who need to answer "are we affected?" when the next Log4Shell drops.

Dan: Mm. So the SBOM tells you what you have. What tells you what's wrong with it?

Alice: Dependency scanning tools. Dependabot, Snyk, OSV — they continuously monitor your dependencies against vulnerability databases. When a new vulnerability is disclosed that affects one of your packages, they alert you or automatically create a pull request with the fix. The key word is continuously. An SBOM generated at build time is a snapshot. Continuous scanning catches vulnerabilities discovered after you've already deployed.

Dan: Yeah, and I imagine you also need to make sure you're deploying exactly what you tested? Not a different version that got updated between test and deploy?

Alice: That's lock files. When you run your package manager, a lock file records the exact version of every dependency installed — not a range, the exact version. You commit that lock file to your code repository. Then in your CI/CD pipeline, you use a deterministic install command that reads from the lock file and installs exactly those versions. If an attacker publishes a malicious version of a package that falls within your version range, and you don't have a lock file, your build process could silently pull in the malicious version.

Dan: Mm. That's a simple thing that prevents a serious attack. What about the build process itself? SolarWinds showed that even if the source code is clean, the build can be compromised.

Alice: That's where SLSA comes in — S-L-S-A, Supply-chain Levels for Software Artifacts. It's a framework that defines levels of build integrity. The SBOM tells you what's in the software. SLSA tells you how it was built and whether you can trust the build process. At Level 2, your build system generates a signed provenance attestation — a cryptographic document proving what source code was built, by which build system, producing which artifact. It's like a notarised affidavit for your build process.

Dan: Right. And if someone tampers with the build — like the SolarWinds attackers did — that provenance wouldn't match?

Alice: Exactly. The signing uses Sigstore — the same keyless signing we mentioned in Episode 46 for container images. The build system authenticates with its identity, gets a short-lived certificate, signs the provenance, and records the signature in a transparency log. No long-lived keys to steal. And Level 2 is achievable for most teams in two to four weeks using GitHub Actions or Google Cloud Build.

Dan: Mm-hmm. Let me ask the legal angle. If you know a dependency has a vulnerability and you ship it anyway, what's the exposure?

Alice: Real. Awareness of a vulnerability plus failure to remediate creates a duty-of-care issue. If a breach exploits a CVE that was publicly disclosed months before you patched, your answer to "why wasn't this fixed?" needs to be better than "we didn't know." ABA Model Rule 1.6(c) requires reasonable efforts to prevent unauthorised access to client information. Running a legal SaaS platform with known, unpatched vulnerabilities in your dependency tree is hard to characterise as reasonable. The SBOM and continuous scanning are your evidence that you took it seriously.

Dan: Yeah, that's compelling. So to summarise — SBOMs for visibility, dependency scanning for alerts, lock files for reproducibility, SLSA and Sigstore for build provenance.

Alice: Four layers that transform your supply chain from a blind spot into a managed risk. Without them, you're shipping software you cannot fully describe, built from components you cannot fully verify. With them, you can answer — to regulators, to clients, to a court — exactly what's in your software and how it was built.

Dan: Next episode — environment configuration and secure defaults. How to make sure your staging and production environments have the same security controls, not just the same features.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.