1 August 2026By NexCyber Editorial Semiconductors

Top-level SBOMs answer nothing in silicon supply chains. The vulnerability is four layers down, in a stack the vendor licensed and never inventoried.

---

The short answer

CRA Annex I Part II requires component identification in a machine-readable format, covering at the very least top-level dependencies.

"At the very least" is doing enormous work in that sentence, and in semiconductor supply chains it marks the exact layer where nothing interesting happens.

customer application
  vendor SDK                    <- what a top-level SBOM lists
    RTOS / driver layer
      third-party TCP/IP, TLS, crypto
        upstream open source     <- where the CVE actually is

A bill of materials that says "vendor SDK 4.2" answers no question anyone will ask you.

---

Why this industry specifically

Three properties compound, and few other industries have all three.

The stack is licensed, not written. A module vendor integrates a chip vendor's SDK, which embeds a commercial RTOS, which links a third-party network stack, which vendors an open source TLS library. Nobody in the chain wrote most of what they ship.

The binaries are opaque. Much of what arrives is precompiled — a static library, a blob, a signed binary component. Source-tree analysis cannot see inside it.

The lifetimes are long. A part ships for a decade. The version you must answer questions about may have been built by a toolchain nobody still runs.

---

The technical mistake that invalidates most SBOMs

Generating from the source tree instead of the build artefact.

source tree        the dependencies you DECLARED
build artefact     what is actually LINKED into the shipped firmware

These diverge routinely. Conditional compilation, static linking, dead-code elimination, vendor-supplied precompiled libraries, and modules stripped for flash budget all mean the manifest and the binary disagree.

Authorities and customers ask about the thing you shipped, not the thing in your repository.

Practically: generate during the build, from the linker output and the final image, not from Kconfig, CMakeLists or a lockfile.

---

PURL: the field that does the work

A Package URL — pkg:generic/[email protected], pkg:npm/[email protected] — is the identifier automated vulnerability matching depends on.

Without PURLs, an SBOM is human-readable and machine-useless. And at 24 hours, the thing doing the matching is a machine.

This is where most embedded SBOMs fail quietly. They list component names as free text — "TLS library", "vendor crypto" — which no matcher can resolve. The document exists, satisfies a checkbox, and cannot answer the only question that matters under time pressure.

---

VEX: how you say "present but not exploitable"

A deep SBOM surfaces components with known CVEs that your product does not actually expose — a vulnerable code path that is compiled out, unreachable, or requires an interface you do not enable.

Without a way to state this, depth becomes a liability: every customer scan generates alarm, and you answer each one by hand.

VEX (Vulnerability Exploitability eXchange) states, machine-readably, that a component is present and the vulnerability is not exploitable in your configuration, with a reason.

VEX is what makes depth affordable. Teams that go deep without it drown in triage and quietly retreat to shallow SBOMs — which is how a good instinct produces a worse outcome.

---

SPDX or CycloneDX

Both are accepted machine-readable formats and both are legitimate.

CycloneDX tends to fit embedded and security workflows: compact, strong VEX integration, good tooling for binary analysis.

SPDX carries more licensing depth and is entrenched where legal review drives the process.

The choice matters far less than PURL correctness and build-time generation. A well-formed SBOM in either format beats a poorly-identified one in the other.

Pick one, and be able to emit the other. Customers will ask for both, and conversion is a tooling problem, not a decision.

---

The archive is the actual deliverable

One SBOM per shipped version, retained.

The question you will be asked is not *what is in your product*. It is which of the versions we deployed contain the affected component — and that is a question about history.

with an archive     a query, answered in minutes
without one         reconstruction from build records that
                    no longer match what shipped

Retroactive reconstruction is not merely slow — it is unreliable, and an authority reading a dated-today analysis of a two-year-old release will see exactly what it is.

---

Pushing depth up the chain

You cannot inventory what your supplier will not disclose. Three things work, in ascending order of leverage:

Ask in the contract, not the questionnaire. An SBOM clause in a supply agreement outperforms any number of follow-up emails.

Accept redaction, not refusal. A supplier concerned about disclosing their component list can provide it with VEX and redacted internal naming. Refusal is increasingly read as inability, which is a worse answer commercially.

Binary analysis where disclosure fails. Composition analysis on a delivered binary is imperfect and legally sensitive, but it is not nothing — and it tells you whether the gap is confidentiality or ignorance.

---

Five decisions worth making now

1Move generation into the build, from the artefact.
2Make PURL correctness a build check, not a review step.
3Adopt VEX before you go deep, or depth will be abandoned.
4Archive one SBOM per shipped version, indefinitely — storage is trivial, reconstruction is not.
5Put SBOM obligations in supplier contracts at the next renewal.

---

Check what your product line needs — free, no account

[Free readiness assessment](/assess) — your CRA class and the artefacts that follow
[Compliance responsibility mapper](/resources/responsibility-mapper) — an owner per artefact
[Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover

---

SBOM Depth in Semiconductor Supply Chains — How Far Down