Bind an inventory to its actual artifact and scope

SPDX 2.3 and CycloneDX 1.6 provide versioned ways to express software inventory and related information. Their schemas and vocabularies differ, and later versions may add concepts. Record the actual format and version rather than treating the word SBOM as one interchangeable schema. Component identities, versions, hashes, dependencies, authorship metadata, and relationships can help join an inventory to other evidence. However, a well-formed document can still omit a copied binary or misidentify a component. Schema validation checks the document's structure; collection coverage and factual accuracy require different evidence.

State whether the inventory concerns source dependencies, build tools, or the final runtime artifact. An AI image may include operating-system libraries, native extension wheels, generated kernels, and model conversion utilities absent from one application manifest. A build-time generator may influence output while not being present in the deployed filesystem. Keep those scopes distinguishable instead of mixing their counts without labels. Relationships can preserve how components were assembled, but the existence of a dependency edge does not alone establish that a vulnerable function executes in the deployed path.

Bind the inventory to a concrete artifact digest and target so a similarly named image cannot silently inherit its report. Record the generating tool, relevant configuration, collection time, and declared scope. Names alone can conflate different versions or architectures; inconsistent identity normalization can also create duplicates. Distinguish unresolved identity from confirmed absence. A scanner's inability to recognize a statically linked library is evidence about the method's limit, not proof that the library is absent. An inventory regenerated from changed bytes should receive a new artifact binding even if the release label stays the same.

Freshness has several dimensions. An old inventory can accurately describe unchanged immutable bytes, while a document generated one minute ago can describe the wrong image. Newly published vulnerability information may require reassessment of the same inventory without changing its component facts. Version the relationship between artifact, inventory, and analysis result rather than overwriting all three as one status. Preserve enough history to answer which evidence and advisory set supported a past deployment decision. Collection timestamps help order work, but cannot substitute for digest binding or complete scope.

A component list can support incident search, update planning, and evidence gathering. It does not alone prove that an artifact is free of vulnerabilities, that a particular advisory is exploitable, or that every license obligation is satisfied. Those questions require additional context and policy. Resolve reported matches to actual component identities and paths, examine execution and privilege context, and retain uncertainty where the collection method cannot answer. Completeness declarations should reflect evidence rather than the expectation that a standard document is automatically exhaustive. Consumers should be able to see whether runtime, build, and unknown components were treated separately.

The probability lab illustrates one explicit collection assumption, not an inventory scanner. For each separate view, Reset, set both per-component capture probability p=0.9 and count n=10, predict the all-ten bar, then inspect. If ten capture events were independent with equal probability, the chance of capturing all ten would be 0.9¹⁰≈0.3487. Real tools can systematically miss an entire class of native libraries, violating independence. The calculation explains why a high marginal capture rate is not itself a completeness claim; actual coverage needs a defined reference and collection evidence.