Skip to content

Software Bill of Materials with Lineage

Inventory artifact — instantiates Substrate Lineage Risk Audit

A component inventory that annotates every part with where it came from and what it was inherited through, turning invisible substrate into audited line-items.

A Software Bill of Materials with Lineage is the manifest of everything a system is actually made of — but with the origin of each part written next to it. A plain parts list tells you what is present; the lineage variant additionally records, for every component, its supplier, its upstream project, its version, and the inherited-through relationship that pulled it in. Its defining move is completeness across the transitive closure: it does not stop at the dependencies your team declared but walks down through the dependencies of those dependencies, so the 80% of a system that is inherited background becomes an itemized, queryable list. Where a provenance record traces one substrate's custody trail, the SBOM enumerates all of them at once — it is the inventory the rest of the audit works against.

Example

A medical-device team ships firmware for an infusion pump. They wrote perhaps a sixth of the code; the rest is a commercial real-time OS, a TLS library, and a vendor board-support package — each of which drags in components of its own. Regulators now expect a bill of materials for exactly this reason.[1] Generating an SBOM with lineage, the team produces a manifest where every entry carries a supplier, an upstream source, a version, and a license — including the sub-dependencies buried three layers inside the board-support package that no one had ever listed.

The output is not a judgment, just an inventory — but it is transformative, because the "trusted background" the local review had skipped is suddenly a concrete list of a few hundred named parts. Now the vulnerability scan has something to check against, the release gate has something to require, and the auditors can ask "who supplies this, and what version?" of a component that was, the day before, effectively invisible.

How it works

  • Draw the scope boundary. Decide what counts as part of the audited substrate — runtime dependencies only, or build-time and packaging inputs too — because the boundary determines what the inventory can even see.
  • Walk the full transitive closure. Resolve not just declared dependencies but everything they in turn depend on, recursively, until the graph bottoms out.
  • Record provenance per node. For each component, capture supplier, upstream project, version, hash, and license — the lineage annotations that distinguish this from a bare dependency list.
  • Publish as a shared, machine-readable manifest. Emit in a standard format so the SBOM becomes the common inventory every downstream mechanism queries, rather than one team's spreadsheet.

Tuning parameters

  • Closure depth — how far down the transitive graph to resolve. Full depth catches deeply-buried inherited parts; capped depth is faster but leaves a blind spot exactly where risk hides.
  • Metadata richness — how much to record per component (name and version only, versus supplier, hash, license, and build origin). Richer entries power more of the audit but cost more to collect and keep accurate.
  • Scope boundary — runtime artifacts alone, or build-time toolchain and packaging inputs as well. Widening it surfaces supply-chain substrate but enlarges the inventory sharply.
  • Generation source — built automatically from the actual build, or assembled by hand. Build-derived inventories are the only ones that stay honest.
  • Refresh cadence — regenerated per build, per release, or on demand. A stale SBOM silently misrepresents what is deployed.

When it helps, and when it misleads

Its strength is that it converts an invisible inherited mass into an itemized, queryable foundation — the artifact everything else in the audit measures against. Nothing downstream can check a component the inventory never listed, which is why breadth and freshness matter more here than analysis.

Its failure mode is incompleteness masquerading as completeness. An SBOM is only as good as its generation: dynamically loaded plugins, vendored copies pasted into the tree, and statically-linked code frequently go unlisted, so a confident-looking manifest can still omit the very component that matters. It also describes what is present, not whether any of it is vulnerable or trustworthy — reading a clean-looking inventory as a clean system is the classic misuse. And a snapshot taken once and never refreshed drifts out of truth with the next build. The discipline is to generate from the build rather than by hand, measure the inventory by its completeness, and treat it as the input to analysis, never the analysis itself.

How it implements the components

This artifact fills the inventory-and-scope side of the archetype's machinery — the components that make the inherited substrate visible and bounded:

  • substrate_scope_boundary — its inclusion rules define what counts as part of the audited substrate, drawing the line between local and inherited.
  • transitive_dependency_trace — it resolves the full transitive closure, so inherited parts several hops down appear as first-class entries.
  • audit_boundary_extension — by itemizing inherited components as line-items, it pulls the trusted-background substrate inside the audit perimeter — the archetype's core move made concrete.

It does NOT test those components for known vulnerabilities — that's Transitive Vulnerability Scan — nor vouch for any one part's origin trail — that's Provenance Chain-of-Custody Record. The SBOM says what is present; its siblings judge it.

Notes

An SBOM is a snapshot, and its whole value depends on matching what is actually deployed. Regenerate it from the build on every release; a bill of materials describing last quarter's dependency graph is worse than none, because it is trusted while being wrong. The list is the starting line of the audit, not the finish.

References

[1] A Software Bill of Materials is a formal, machine-readable inventory of the components in a piece of software and their supply-chain relationships; standard formats such as SPDX and CycloneDX exist to express it. Referenced here as an established practice, not as a specific regulatory citation — the point is the artifact's structure, an itemized manifest with provenance per entry. ↩