SAMMY works best on screens 1024px wide or larger.
CRA Framework
Browse CRA Framework
TPD: Third-Party Dependencies
TPD: Do you have solid knowledge of the dependencies you rely on and manage third-party dependency risk through a formal process?
  • You maintain a current Bill of Materials (BOM) for every product
  • You keep a list of approved dependencies that meet predefined security and usage criteria
  • You automatically evaluate dependencies for newly disclosed vulnerabilities (e.g., CVEs) and alert responsible staff
  • A documented process exists for reporting vulnerabilities discovered in integrated components to the relevant upstream maintainer
  • Where one or more dependencies cannot be secured to the required level, compensating controls are implemented and documented in the risk assessment
Not applicable - The activity is not relevant to the product type or architecture.
Not implemented - No structured or repeatable approach exists.
Partially implemented - The activity exists but is incomplete, inconsistently applied, or does not meet all quality criteria.
Fully implemented - A defined and repeatable approach exists and meets the stated quality criteria.
Description

The Cyber Resilience Act (Article 13(5)) requires manufacturers to exercise due diligence when integrating components from third parties, and to identify and document all components and their dependencies, including by drawing up a software bill of materials (SBOM). Third party components inherit trust from the product they are embedded in; a vulnerability in a single library or remote service can undermine the security posture of the entire product and expose users to risks the manufacturer is ultimately accountable for.

Maintain a current Bill of Materials for every product, covering all third party components, libraries, and remote data processing solutions integrated into the product. Establish and enforce a list of approved dependencies that meet predefined security and usage criteria, and automatically evaluate dependencies against newly disclosed vulnerabilities (e.g., CVEs), alerting responsible staff when a dependency falls below the required security threshold.

Implement a documented process for approving dependencies before they are introduced into the product, ideally maintaining a "known good" list and disallowing the addition of any dependency that has not been formally approved. Complement this with a process for replacing or mitigating dependencies that no longer meet your security criteria, whether due to newly disclosed vulnerabilities, lack of maintainer support, or changed licensing conditions. All dependencies should be scanned continuously for new vulnerabilities, not just at integration time. Ensure the SBOM is kept up to date as dependencies evolve and is available as part of the product's technical documentation (Annex VII). Dependency management should be treated as a continuous activity throughout the product's support period, not a one time exercise at release.