The inventory is the operational system of record behind CRA software supply chain security. It should connect engineering dependency data, procurement supplier data, product releases, vulnerability intelligence and support decisions so teams can answer what is in the product, where it came from, who maintains it and which releases are affected when a problem appears.
Treat the Inventory as a Lifecycle Record
A component inventory should not be a one-time spreadsheet created for conformity work. It should remain connected to product releases, dependency changes, supplier changes, vulnerabilities and end-of-life decisions throughout the support period.
Define What Counts as a Relevant Component
Include software libraries, packages, frameworks, firmware, SDKs, drivers, precompiled binaries, commercial modules and other third-party elements that can affect product cybersecurity. Hardware components should also be represented in the broader supply-chain inventory where they have security relevance, even though the SBOM requirement itself concerns software components.
Record Stable Component Identity
For each component, record enough identity data to distinguish it reliably across builds and vulnerability sources. Typical fields include name, version, package or product identifier, source repository or supplier, maintainer and relevant hashes or release identifiers.
Record Dependency Relationships
Document whether the component is a direct dependency, transitive dependency, bundled runtime, firmware element or supplier module. Relationship data helps explain how a vulnerable component enters the finished product and which higher-level dependency must be changed to remove it.
Map Components to Product Releases
Link each component version to the product releases that contain it. This is one of the most important operational controls because newly disclosed vulnerabilities need to be mapped to supported products and customer populations quickly.
Connect Supplier and Maintainer Information
Record the commercial supplier, open-source project or maintainer responsible for the component where known. This supports supplier assessment, vulnerability notification, security-update tracking and end-of-life planning.
Track Support and End-of-Life Status
Record known support periods, maintenance status and announced end-of-life dates for important dependencies. Components that provide core functions should be reviewed against the product's own support period so that the manufacturer does not rely on a dependency that becomes unmaintained too early.
Track Vulnerability Status Separately From Component Identity
The component record should remain stable while vulnerability findings change over time. Link vulnerabilities, advisories, exploitability assessments, remediation actions and closure evidence to the component and affected releases rather than overwriting the component's identity record.
Use the Inventory to Generate the SBOM
The component inventory should be the source or reconciliation layer for the product SBOM. Automated build data can generate much of the software inventory, while procurement and manual records can fill gaps for supplier binaries, firmware and exceptional components.
Assign Owners for Important Components
Critical dependencies should have a clear internal owner responsible for monitoring support, reviewing updates and coordinating remediation. Without ownership, important supplier or maintainer changes can remain unnoticed until a vulnerability or end-of-life event creates urgency.
Review the Inventory at Release Gates
Use release governance to check that new dependencies have been assessed, removed dependencies are reflected accurately, component versions are correct and the SBOM matches the shipped build. This prevents drift between engineering reality and compliance evidence.
Preserve Historical Inventory Data
Do not keep only the current dependency state. Historical release data is needed to investigate vulnerabilities affecting older supported versions and to demonstrate how component risk was managed over time.
Connect the Inventory to Technical Documentation
Annex VII requires architecture and vulnerability-handling information, including the SBOM. The component inventory should therefore support technical documentation by providing traceable evidence for component selection, integration, support and remediation decisions.
Use Review Triggers
Review the inventory when product releases, suppliers, dependencies, firmware, build systems, support commitments or vulnerability status change. Explicit triggers prevent the inventory from becoming stale between formal compliance reviews.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.