Supply Chain Security Assessment Framework

You don't ship your code — you ship everyone's

Look at what actually runs in production and your own code is a thin layer on top of a mountain of other people's work. Direct dependencies pull in transitive ones you never chose. Your build pipeline runs compilers, package managers, and CI runners you didn't write. The appliance in the rack ships firmware you can't read. Every one of those is a way in that has nothing to do with the quality of the code your team writes.

A supply chain assessment starts from that reality. The question is not "is our code secure" — it's "what are we inheriting, and can we prove it's what we think it is?"

The threat model you're actually facing

Before you can assess anything, you need a clear picture of how a supply chain gets compromised. The recurring patterns are:

• A compromised package. A legitimate library gets a malicious update pushed under a real maintainer's name, or a squatted name lands in your lockfile by typo.
• A hijacked or malicious maintainer. Account takeover, a handoff to a bad actor, or a burnt-out maintainer who accepts a poisoned contribution.
• Build tampering. The source is clean, but the artifact that ships isn't — the compromise lives in the CI runner or the release step, not the repo.
• A vulnerable transitive dependency. A flaw three levels deep in a package you never chose to install, that you can't patch directly.
• A backdoored or negligent appliance. A vendor product with an undocumented account, a hardcoded key, or unpatched components you have no visibility into.

Step 1 — Inventory & SBOM

You cannot secure what you cannot list. The foundation of every assessment is a complete Software Bill of Materials — the full, resolved set of components that actually end up in the build, not just the dependencies you declared. Transitive packages, pinned versions, and vendored code all belong on the list.

We generate the SBOM directly from the built artifact, then scan it against known-vulnerability databases so the inventory doubles as a risk snapshot:

# generate an SBOM from a built image, then scan it
syft packages myimage:latest -o spdx-json > sbom.json
grype sbom:sbom.json --fail-on high

An SBOM you generate once and never revisit is a snapshot of the day it was made. To stay useful it has to be regenerated on every build and stored as an artifact you can query later.

Step 2 — Provenance & build integrity

Knowing what's in the build is only half of it. You also need to know that the artifact you're running is the one that came from the source you reviewed. That's provenance:

• SLSA levels. Work up the ladder — from "there is a build process" to "the build is scripted, tamper-resistant, and produces signed provenance you can verify."
• Signed artifacts. Releases carry a signature tied to an identity, so a swapped binary fails verification instead of running silently.
• Reproducible builds. Two independent builds of the same source produce byte-identical output, which is the strongest evidence that the artifact matches the code.

Step 3 — Dependency & license review

Automated scanners catch known CVEs. They do not catch the malicious update that hasn't been reported yet, the abandoned package quietly rotting, or the license that makes the whole thing unusable. For the components that matter most, someone has to read the code that everyone else assumes is safe — the parts that handle input, run at build time, or execute with elevated privileges. This is where a real assessment separates itself from a scan.

Step 4 — Third-party & appliance testing

When the "dependency" is a whole product — an appliance, a vendor agent, a black box you're about to trust with production traffic — you test it before you trust it. Black-box testing probes it the way an attacker would, with no inside knowledge. White-box testing, where the vendor cooperates and shares detail, goes deeper and faster. Either way, the goal is the same: understand what it exposes, what it phones home, and what it does when you feed it something it didn't expect — before it's in the critical path, not after.

Step 5 — Ongoing monitoring

The supply chain doesn't hold still. A package that was clean at assessment time gets a CVE next month; a vendor ships firmware with a fresh flaw. Because you already have an SBOM, new advisories can be matched against your exact component list automatically — you learn that a newly disclosed flaw affects you because the vulnerable version is in your inventory, not because it made the news.

Reproducible evidence, upstream-ready fixes

Everything we hand back is reproducible. A finding comes with the exact command, input, and version that produced it, so your team can confirm it independently rather than taking our word for it. And where the fix belongs upstream — a patch to an open-source dependency, a report to a vendor — we write it in a form that's ready to submit, so the fix lands at the root instead of being papered over in your own tree. That's the difference between a report you file and a risk you actually retire.