What it means
Think of an SBOM as an ingredient list tied to a specific software build. It identifies components and their relationships, including libraries pulled in indirectly by other libraries. Useful inventories identify versions and record how and when they were produced. Finding a component in an SBOM is the beginning of an exposure investigation. It does not prove a reported vulnerability affects that exact build, that the affected feature is used, or that an attacker can reach it. An incomplete or outdated inventory can also miss relevant components.
The idea at a glance / Software
An inventory belongs to one artifact.
Read one build’s component identities, versions and dependency relationships. Its inventory does not describe every deployment or prove that a fix is installed.
Synthetic ShopCart inventory SB42: build B42, artifact digest reference D42. These are selected teaching records, not a complete machine-readable SBOM.
READ THE PICTURE
Read the inventory and its limits
SB42 ties cart-core 2.3.0 and nested parse-lite 1.4.0 to B42/D42. Deployment binding, advisory conditions and remediation need separate evidence.
Keep in mindD42 labels an artifact digest; it is not hash bytes or a live verification. P44 and P45 are document-local references, not globally resolvable package identifiers. A different running artifact needs matching inventory. Missing exploit evidence is not safety, and a plan is not remediation.
Read the complete example
- Read the inventory and its limits. SB42 ties cart-core 2.3.0 and nested parse-lite 1.4.0 to B42/D42. Deployment binding, advisory conditions and remediation need separate evidence. ShopCart build job J77 assembled the fictional inventory SB42 on 2026-09-30 at 09:00 UTC for artifact B42/D42. Its selected records identify supplier CartWorks, component cart-core, version 2.3.0, reference P44; and supplier ParseWorks, component parse-lite, version 1.4.0, reference P45. B42 includes P44 directly; P44 includes P45, making parse-lite a transitive dependency of B42. The supplier/component/version, identifying references, dependency relationship, author and assembly time illustrate the data fields in NTIA’s 2021 baseline. P44 and P45 are scoped to SB42; real matching also needs supplier and suitable unique identifiers. D42 stands for an already-recorded artifact digest, not bytes computed here. These selected records are not a complete or validated SBOM format, an attestation, or proof that discovery found every dependency. To apply an advisory, match its component identity and affected versions, identify the actual running artifact, and investigate configuration and reachability. An inventory for B42 cannot establish components in running B41/D41. An advisory version match alone does not prove that the required vulnerable code path executes. Operational ownership and business impact come from separate records and judgment. Unknown exploitation or an absent KEV entry does not establish safety. An owner decision to test a fix has not acquired, installed or verified that fix. Keep the inventory current when the artifact changes. The paired SBOM lesson works through both matching and different-build outcomes.
D42 labels an artifact digest; it is not hash bytes or a live verification. P44 and P45 are document-local references, not globally resolvable package identifiers. A different running artifact needs matching inventory. Missing exploit evidence is not safety, and a plan is not remediation.
Diagram references: NTIA: Minimum Elements for an SBOM (2021 baseline) · NIST SP 800-218: SSDF 1.1, PS.3.2 and RV.2 · NIST SP 800-40 Rev. 4: identify, prioritize, install and verify patches
AN ILLUSTRATIVE SCENARIO
The inventory and production identify different builds
Chronos Hub’s SB42 inventory lists parse-lite 1.4.0 for B42/D42, but the deployment record says telemetry ingestion runs B41/D41. A supplier advisory matches the B42 component and version; that does not establish B41’s components or conditions. Vera requests a matching inventory and evidence for B41 and records a review deadline. The risk remains unresolved. A request, a planned patch or the SBOM file itself has not changed the running software.
Put it to work
- Generate or request an inventory for the actual release artifact, including indirect dependencies. Retain its version, generation context, and relationship to the deployed build.
- Match supplier, component identity and affected versions with current advisory information. Bind the inventory to the running artifact and investigate required configuration and reachability. Retain unknown exploit evidence as unknown; it does not automatically permit waiting.
- Associate the inventory with application owners and deployments. Regenerate it when software changes so the next advisory can be traced to real systems and a responsible maintainer.
How to check your work
Select a dependency from the actual running artifact and confirm its identity, version and direct or transitive relationship in the matching inventory. Trace an advisory through deployment binding, condition evidence, owner and dated decision. If a fix is claimed, verify the installed artifact and updated inventory separately.
Connect the ideas
- SCA
Inspection of dependencies and libraries for known vulnerabilities and license issues.
- CVE
A public identifier for a specific disclosed vulnerability record.
- Exposure
Whether and how a vulnerability or service can actually be reached in this environment.