Software Supply Chain Security: SBOMs, Dependencies, and SLSA

You ship far more code than you write

Open any modern application and the code your team authored is a thin shell over a mountain of dependencies — open-source libraries, transitive packages those libraries pull in, base container images, build tools, and CI/CD plugins. A typical service can carry hundreds of third-party components, most of them dependencies of dependencies that no one on the team ever consciously chose. Every one of those is code you execute in production and, implicitly, trust.

That trust is the attack surface. Adversaries learned that compromising one widely used component is more efficient than attacking each downstream victim individually, and the last several years have made software supply chain attacks a headline category: poisoned package updates, typosquatted libraries, compromised build pipelines, and malicious maintainer takeovers. Defending your own code is necessary but no longer sufficient. Supply chain security is the discipline of knowing what is in your software, where it came from, and whether the path from source to production can be trusted end to end.

The attack surface is the whole pipeline

"Supply chain" is broader than "our dependencies have vulnerabilities." The threats cluster into distinct categories, and a program that addresses only one leaves the others open.

• Known vulnerable dependencies. The most common exposure: a component with a published CVE that you ship because nobody tracked it. Ordinary hygiene, but only if you actually have an inventory.
• Malicious packages. Deliberately planted code — typosquats mimicking a popular library name, a legitimate package hijacked through a compromised maintainer account, or a dependency-confusion attack that tricks your build into pulling an attacker's package from a public registry instead of your internal one.
• Compromised build systems. The most severe class. If an attacker subverts your CI/CD pipeline, they can inject malicious code after your clean source is committed but before the artifact ships — so the source repository looks pristine while the released binary is backdoored. Several landmark incidents worked exactly this way.
• Upstream and transitive risk. A vulnerability or backdoor several layers deep in your dependency tree, in a package your direct dependencies rely on and you never evaluated.

Each category needs a different control. Vulnerability scanning catches the first, provenance and pinning catch the second, build integrity catches the third, and full-depth inventory is what makes the fourth visible at all.

SBOMs: you cannot secure an unknown inventory

A software bill of materials (SBOM) is a complete, machine-readable list of every component in a piece of software — names, versions, suppliers, and the relationships between them. It is the supply chain equivalent of an ingredients label, and it is the foundation everything else rests on, because you cannot patch, assess, or reason about components you have not enumerated.

The practical value shows up the day a new critical vulnerability drops in a ubiquitous library. Organizations without SBOMs spend days manually hunting through codebases to answer "are we affected, and where?" Organizations with current SBOMs query their inventory and know within minutes exactly which applications include the vulnerable component and which version. That difference is the entire argument for maintaining them.

Getting SBOMs right in practice comes down to a few disciplines:

• Generate them automatically in the build. An SBOM produced by the pipeline reflects what actually shipped, including transitive dependencies. A hand-maintained list is wrong within a week.
• Use a standard format. SPDX and CycloneDX are the widely adopted machine-readable standards, so tooling and partners can consume what you produce.
• Capture full depth. A shallow SBOM listing only direct dependencies misses the transitive layers where much of the real risk hides.
• Keep them current and queryable. An SBOM is a point-in-time snapshot; it is only useful if regenerated on every build and stored where you can search across your whole estate fast.

SBOMs are increasingly a contractual and regulatory expectation as much as a security practice, particularly for anyone selling into government or regulated markets.

Dependency hygiene as routine engineering

An inventory is the input; disciplined dependency management is what reduces the risk it reveals. This is continuous engineering work, not a one-time cleanup, and it folds naturally into a broader vulnerability management program.

• Scan continuously. Software composition analysis compares your dependencies against vulnerability databases on every build and flags newly disclosed issues in components you already shipped.
• Pin and lock versions. Lockfiles that record exact versions and cryptographic hashes ensure the build pulls the component you vetted, not whatever the registry serves today — the direct defense against a malicious update slipping in.
• Prefer internal registries and vet new dependencies. Proxying package installs through a curated internal registry and reviewing new additions blocks typosquats and dependency-confusion attacks before they enter the tree.
• Prioritize by reachability, not just severity. A critical CVE in a code path your application never calls is lower risk than a moderate one in a function that handles untrusted input. Reachability analysis focuses remediation where exploitation is actually possible instead of chasing every red row.
• Prune aggressively. The most secure dependency is the one you removed. Unused and redundant packages expand the attack surface for no benefit.

SLSA: proving the path from source to production

Knowing your ingredients is not the same as trusting how the meal was cooked. SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework focused on build integrity and provenance — proving that an artifact was built from the source you think it was, by a pipeline that was not tampered with. It answers the build-compromise threat that SBOMs and scanning do not.

Its central concept is provenance: verifiable, tamper-evident metadata describing how an artifact was produced — which source commit, which builder, which parameters. If you can cryptographically verify provenance, an attacker cannot silently swap in a backdoored binary, because the substitute will not carry valid provenance tying it to your trusted source and build system. SLSA defines progressive levels of assurance, roughly:

The levels are a maturity ladder, not a pass/fail gate. Practical adoption means moving up deliberately: sign your commits and artifacts, run builds on ephemeral hosted runners rather than long-lived shared machines, generate provenance automatically, and verify that provenance before deployment. Each step raises the cost of tampering with your pipeline.

Where to start

Begin with visibility, because every other control depends on it. Generate SBOMs automatically in your build pipeline and store them where you can query your whole estate in one place. Turn on software composition analysis so new vulnerabilities in shipped components surface on their own. Pin dependencies with lockfiles and route installs through a curated internal registry. Then harden the pipeline itself — signed artifacts, isolated builders, verified provenance — working up the SLSA levels rather than trying to reach the top in one jump.

intSignal folds supply chain security into a broader application security practice: SBOM generation and inventory, continuous dependency scanning tuned to reachability, and build-pipeline hardening measured against SLSA. Talk to our security team and we will help you find out what is really in your software — and whether you can trust how it was built.