CRA Supply Chain Security: Managing Third-Party Components

The EU Cyber Resilience Act makes one thing clear: you are responsible for the security of every component in your product, including the ones you did not write. Third-party libraries, open source dependencies, and vendor-supplied modules are all within scope. If a vulnerability in a transitive dependency is actively exploited, it is your obligation to report it to ENISA within 24 hours.

This guide covers how to manage supply chain security under the CRA, from dependency due diligence to vendor assessment and ongoing monitoring.

Why the CRA Focuses on Supply Chain

Modern software products are assembled, not written from scratch. A typical commercial application contains 80% or more third-party code by volume. The CRA acknowledges this reality in Regulation 2024/2847, Annex I, Section 2, which requires manufacturers to identify and document vulnerabilities in components, including third-party and open source components.

High-profile supply chain attacks — SolarWinds, Log4Shell, the xz utils backdoor — demonstrate that attackers increasingly target the supply chain rather than the end product. The CRA is designed to force manufacturers to take supply chain security seriously.

Step 1: Know Your Dependencies

You cannot secure what you cannot see. The first step is generating a comprehensive Software Bill of Materials (SBOM) that includes not just your direct dependencies but also transitive dependencies — the dependencies of your dependencies.

A product that lists 50 direct dependencies might have 500 or more transitive dependencies. Each one is a potential attack surface and a potential source of vulnerabilities.

Tools for deep dependency analysis:

• Syft: generates SBOMs from source, container images, and file systems with deep transitive resolution
• Trivy: scans containers, file systems, and Git repositories for dependencies and vulnerabilities simultaneously
• Language-specific lock files: package-lock.json (npm), Cargo.lock (Rust), poetry.lock (Python), go.sum (Go) — these contain the full resolved dependency tree

Generate your SBOM from the lock file or final build artifact, not from the manifest alone. Manifests (package.json, requirements.txt without pinning) do not capture the exact resolved versions.

Step 2: Assess Open Source Risk

Not all open source dependencies carry the same risk. Evaluate each dependency based on:

Maintenance health: Is the project actively maintained? When was the last commit? Are issues being addressed? A dependency that has not been updated in two years is a risk — vulnerabilities may go unpatched.

Security practices: Does the project have a SECURITY.md? A vulnerability disclosure policy? Automated dependency updates? These signal maturity. Run cra-scanner against key open source dependencies to assess their CRA readiness.

Scope of access: What does the dependency do? A logging library with no network access is lower risk than an authentication library that handles credentials. Prioritize security scrutiny based on the dependency's role in your product.

Transitive dependency depth: A dependency that itself pulls in 200 transitive dependencies expands your attack surface significantly. Prefer dependencies with minimal transitive footprints.

License compliance: While not a security issue, license conflicts can create legal problems. Track licenses in your SBOM using SPDX license identifiers.

Step 3: Vendor Assessment for Commercial Components

If your product includes commercial third-party components — SDKs, libraries, or services from vendors — assess their CRA readiness as part of your procurement process:

• Do they provide an SBOM? If a vendor cannot provide an SBOM for their component, you have limited visibility into what you are shipping.
• Do they have a vulnerability disclosure policy? How will you learn about vulnerabilities in their component?
• What are their patching timelines? If a critical vulnerability is found, how quickly do they release a fix?
• Will they support ENISA reporting? If a vulnerability in their component is actively exploited, you need information fast to meet the 24-hour reporting window.
• What is their support lifecycle? Ensure the vendor's support period aligns with your product's support period. A vendor that drops support before your CRA obligations end creates a compliance gap.

Include CRA-relevant clauses in your vendor agreements: SBOM provision, vulnerability notification timelines, and cooperation on incident response.

Step 4: Continuous Monitoring

Supply chain security is not a one-time assessment. You need continuous vulnerability monitoring across your entire dependency tree. Set up automated monitoring against:

• OSV.dev — aggregated vulnerability data with version-aware matching per ecosystem
• GitHub Security Advisories — curated advisories linked to specific package versions
• CISA KEV — actively exploited vulnerabilities that trigger ENISA reporting obligations

Configure alerts to distinguish between routine vulnerabilities (which need timely patching) and actively exploited vulnerabilities (which trigger the 24-hour ENISA reporting clock).

Step 5: Dependency Update Strategy

Having monitoring without a remediation strategy is insufficient. Establish a dependency update process:

• Automated PRs: use Dependabot or Renovate to automatically create pull requests for dependency updates
• Patch prioritization: critical and high severity vulnerabilities in dependencies should be patched within days, not weeks
• Breaking change management: major version updates may introduce breaking changes. Have a process for evaluating and testing these updates.
• Fork and patch: if an upstream project is abandoned and a vulnerability is discovered, be prepared to fork the dependency and apply the patch yourself

Step 6: Supply Chain Documentation

Document your supply chain security practices as part of your CRA technical documentation:

• Your SBOM and how it is generated and maintained
• Your vendor assessment process and criteria
• Your dependency monitoring setup and alerting thresholds
• Your patch and update policy
• Your risk acceptance criteria for third-party components

This documentation demonstrates to market surveillance authorities — and to your customers — that you take supply chain security seriously.

The Open Source Steward Connection

If your product depends heavily on open source projects governed by foundations, understand the open source steward role. Stewards have lighter CRA obligations, but they are expected to facilitate vulnerability handling. Engage with steward organizations for your critical dependencies — report vulnerabilities through their processes and contribute to their security efforts.

Remember: even though stewards have their own obligations, the manufacturer (you) remains fully responsible for the security of the final product.

For a complete CRA preparation plan, see our CRA compliance checklist.

Complaro provides SBOM management with full transitive dependency tracking, continuous vulnerability monitoring, and automated ENISA report generation when supply chain vulnerabilities are actively exploited. Get started free.