CRA and open source: who is responsible?

Is open-source software exempt?

Article 2(3) of the CRA excludes free and open-source software developed or supplied outside the course of a commercial activity. That is a conditional exclusion, not a rule that every open-source release is outside the regulation. Record what is supplied, by whom and in what activity.

Recitals 18-20 explain important limits. Development funding, regular releases, corporate contributions and repository hosting do not by themselves establish commercial supply. The text distinguishes development from supply and discusses monetisation by the manufacturer. Do not automatically classify a volunteer project as commercial because a company uses it, or assume that an open-core business is excluded because its source is visible.

Separate three roles before assigning duties

An independent contributor who submits code to a project outside their responsibility is different from the manufacturer that supplies a product under its name. Identify who owns the product decisions and release process; do not assign manufacturer obligations to every person whose commit appears in the history.

An open-source software steward is a defined role for a legal person providing sustained support for development of specified open-source products intended for commercial activities and helping ensure their viability, other than a manufacturer. Article 24 establishes a tailored regime including a documented cybersecurity policy, cooperation with authorities and specified reporting obligations. A foundation name alone does not settle whether the definition applies.

A manufacturer integrating a library into its commercial product has its own obligations. Article 13(5) expressly includes due diligence for open-source components supplied outside commercial activity. The upstream exclusion does not make the downstream product exempt. One organisation can also play different roles for different products, so maintain the analysis at that level.

What should dependency due diligence contain?

The CRA does not prescribe the following database columns. They are a suggested way to make component selection, maintenance and vulnerability handling reviewable. Adapt the depth to the component's role and the product's cybersecurity risks.

• Identity: package coordinate, exact shipped version, origin, licence and product releases containing it.
• Purpose: product functions using the component, privileges, inputs and exposure to untrusted data.
• Maintenance: upstream security contact, supported branches, update history and replacement plan.
• Security review: known-vulnerability evidence, lookup date and health, product affectedness and unresolved uncertainty.
• Change handling: fix owner, upgrade or backport decision, tests and customer update path.
• Provenance: retained upstream reference, local modifications, build evidence and reviewer rationale.

A worked example: a parser in a desktop product

Suppose a document editor bundles an open-source parser. The project accepts donations and has volunteer maintainers. Those facts alone do not settle commercial activity. The editor manufacturer should analyse its own supplied product and record the parser as part of its release inventory, rather than waiting for the maintainers to provide a CRA certificate.

A new parser advisory then appears. The team verifies the exact shipped version and whether the vulnerable format is accepted, records its investigation, and tests an upgrade or mitigation. If it discovers a vulnerability in the integrated component, Article 13(6) requires reporting it to the person or entity manufacturing or maintaining the component, addressing and remediating it, and providing relevant documentation where applicable. A private upstream report and the product's customer fix are separate pieces of evidence.

If there is evidence of active exploitation, assess the separate Article 14 question promptly. An upstream issue marked fixed does not show that your released editor is fixed, and an advisory score does not establish the reporting outcome. The vulnerability-handling guide explains that distinction.

What if upstream stops maintaining the component?

An abandoned project is a product risk to manage, not a reason to shorten a manufacturer commitment automatically. Consider replacing it, maintaining a reviewed fork, reducing exposure or arranging support. Record the rationale and tests for the selected response, including the cost and feasibility of migrating customers.

Tie that plan to the support-period record. A library can be a small part of the codebase and still control a critical function such as authentication or update verification. Review importance through its function and exposure, not download counts or the number of files it contributes.

Use SBOMs without overclaiming

An SBOM establishes an inventory claim for a particular release. Check that it matches the artifact and includes components your build actually bundles. An upstream SBOM may describe a different build; a valid format does not establish completeness, maintenance quality or secure integration.

ConformOps can hold supplied SBOM evidence and connect component findings to release-specific review records. It does not certify an upstream project or transfer responsibility from the manufacturer. Keep the licence review, security review, product affectedness and legal role analysis as separate records even when they concern the same component.