Open Source Component

Open source components are software libraries, frameworks, operating system packages, and firmware modules made available under licences (such as MIT, Apache 2.0, GPL, or BSD) that permit use, modification, and redistribution. Modern products with digital elements typically incorporate significant numbers of open source components — a representative IoT firmware image might contain hundreds of open source packages for networking, cryptography, user interface, and utility functions. The CRA explicitly addresses open source in its recitals and introduces the 'Open Source Steward' category for non-commercial maintainers. However, the CRA makes clear that commercial manufacturers who incorporate open source components into their products bear full responsibility for those components' security — they cannot disclaim liability by citing the open source origin.

Manufacturers face three primary CRA obligations with respect to open source components:

1. Include in SBOM: All open source components must be identified in the Annex VII SBOM, including their version, PURL, and licence information. A product SBOM that omits open source components is incomplete.

1. Monitor for vulnerabilities: Open source components must be monitored for newly disclosed vulnerabilities throughout the product's support period. When a CVE is published for a component in the product's SBOM, the manufacturer must triage it and address it if the vulnerability poses a real risk.

1. Apply security updates: When security patches are available for open source components, manufacturers must integrate them and release product updates within timeframes consistent with the CRA's 'without undue delay' standard. Failing to update a known-vulnerable open source component because 'it's upstream's problem' is not a defensible compliance position.

The CRA's secure development requirements (Annex I) imply that manufacturers should exercise due diligence in selecting open source components, not just monitoring them post-integration. A component selection framework for CRA compliance should consider:

• Maintenance status: Is the component actively maintained? An unmaintained or abandoned component will not receive security patches, creating a growing liability.
• Security track record: Does the component have a history of prompt CVE responses? Projects with active security advisories and rapid patch releases are preferable to those that deny vulnerabilities or release patches slowly.
• Dependency footprint: Does the component bring in a large number of transitive dependencies that expand the attack surface?
• Licence compatibility: Is the licence compatible with the product's distribution model? (GPL-licensed components in proprietary firmware require careful legal analysis.)
• Community health: Active, well-funded projects (e.g., those with OpenSSF Best Practices badges or corporate maintainer backing) are lower-risk than single-maintainer hobby projects.

Open source vulnerability management requires a closed-loop process that spans the entire product lifecycle:

1. Initial inventory: At product launch, generate a complete SBOM covering all open source components with PURLs.
2. Continuous monitoring: Feed the SBOM into a SCA platform (Dependency-Track, Snyk, etc.) and monitor for new CVEs daily.
3. Triage: When a new CVE matches a component in the SBOM, triage it — validate the finding, assess reachability in the product, score it with CVSS/EPSS.
4. Remediate: Update the component to the fixed version, test, and release. For components where the upstream fix has not yet been released, implement compensating controls and document them.
5. Publish VEX: For CVEs assessed as not-affecting the product, publish VEX 'not-affected' assertions to inform users.
6. Advisory publication: For CVEs that do affect the product and have been fixed, publish a CSAF advisory.
7. End-of-life management: When ceasing support for a product, clearly communicate the end-of-life date so users can plan migration.