Component Inventory

Summary

Component inventory provides visibility and traceability and enables fast response by maintaining an accurate, machine-readable record of what is actually shipped in each artifact.

Description

Component inventory is the practice of identifying and cataloguing all third-party components (libraries, packages, modules) that are included in a software artifact — i.e. what is actually shipped. This includes direct and transitive dependencies. The output is typically a Software Bill of Materials (SBOM) in a standard format such as SPDX or CycloneDX.

The inventory provides visibility and traceability and enables fast response: you know what you ship (visibility), you can trace components to artifacts (traceability), and when a vulnerability is disclosed, a license concern arises, or another issue surfaces, you can query the inventory to see which artifacts are affected and respond quickly. Additional analysis (e.g. vulnerability scanning, license compliance) adds further value by enabling prevention before issues reach production. Extraction from the actual artifact (container image, binary, filesystem) rather than from declarations alone enables detection of discrepancies between what is declared and what is present.

Requirements

1. The output MUST be a structured, machine-readable SBOM (e.g. SPDX or CycloneDX).
2. The inventory MUST include direct and transitive dependencies with version and provenance information where available.
3. The SBOM MUST be produced for each releasable artifact.

Examples & Commentary

• No releasable artifact should be deployed without a corresponding component inventory (SBOM); this complements Software Artifact Provenance (mi-3), which establishes build-level provenance, by providing component-level visibility and traceability.
• Automated extraction from the artifact plus a machine-readable manifest (SBOM) together provide full coverage. Extraction (e.g. automated binary scan) can be compared to declared dependencies to identify discrepancies; the manifest records what is in each artifact so you can query it when issues arise (e.g. which artifacts contain a given component).
• When a new CVE is published (e.g. Log4Shell), query the inventory across all artifacts to identify which contain the affected component and version; without an inventory, manual inspection or waiting for a scan would be required — with SBOMs, remediation can be prioritised and executed within hours.
• Use the inventory for license compliance: an SBOM listing components with their licenses allows automated checks before deployment; any artifact containing a prohibited license can be flagged or blocked.
• Implement deployment gates that verify an artifact has a valid SBOM before allowing promotion to production; the SBOM can be stored alongside provenance records (mi-3) or in a dedicated SBOM store.
• Tools exist to extract components from container images or filesystems, or to generate SBOMs from the build; the SBOM is the input for vulnerability scanning and license compliance checks.
• The SBOM MAY include recommended elements (e.g. component name, version, PURL, CPE, license info, file hashes) to support faster response and downstream analysis.

Links

• NTIA Minimum Elements for an SBOM
• OWASP SCVS V2: SBOM Requirements
• CycloneDX Specification
• SPDX Specification
• CISA SBOM Guide
• CRA Regulation (EU) 2024/2847 (Annex I, vulnerability handling)
• NIST SSDF SP 800-218 (PS.3.2, RV.1.2)

Key Risks