Third-party component discovery is broader than scanning a package manager. CRA-ready inventories should include software libraries, embedded firmware, operating-system packages, container dependencies, SDKs, drivers, commercial modules and relevant hardware or remote-processing components where they affect product cybersecurity.
Begin With the Product Architecture
Use the product architecture to identify where third-party code, firmware, services and modules enter the product. This prevents dependency discovery from being limited to one programming language or package manager while missing embedded or supplier-provided elements.
Use Build Inputs as a Primary Source
Package manifests, lockfiles, container definitions, firmware build scripts and CI configuration often provide the most reliable view of what is assembled into a release. Inventory processes should reconcile those sources with manually supplied or binary-only components.
Do Not Ignore Firmware and Binary Components
Third-party code can arrive as precompiled libraries, device firmware, drivers, SDKs or vendor binaries. These components may not appear in a source-code dependency scanner but can still create vulnerabilities in the finished product and need lifecycle tracking.
Capture Open Source and Commercial Dependencies
Article 13 due diligence reaches third-party components including free and open-source software. Commercial components may have contracts and security advisories, while open-source components may rely on maintainer and repository evidence. Both belong in the product's security inventory.
Distinguish Direct and Transitive Dependencies
Direct dependencies are selected by the product team, while transitive dependencies are brought in by other components. The CRA SBOM minimum focuses on at least top-level dependencies, but transitive dependencies still matter where they create exploitable product risk.
Assign Stable Component Identity
Record a component name, version and source consistently enough that the same dependency can be recognised across builds, vulnerability tools and technical documentation. Ambiguous labels such as vendor library or utility package make later vulnerability impact analysis unnecessarily difficult.
Connect Components to Suppliers and Maintainers
For each third-party component, record the supplier, maintainer or upstream project where known. This supports Article 13 vulnerability communication and helps teams understand where security updates and end-of-life information are likely to originate.
Tie the Inventory to Product Releases
The inventory should show which product releases contain each component version. This creates the evidence needed to identify affected customers quickly when a component vulnerability or supplier advisory appears.
Review the Inventory When the Product Changes
Update component records when dependencies, suppliers, firmware, build images or architecture change. A component inventory that remains static while the product evolves will quickly stop supporting CRA vulnerability handling.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.