Reporting third-party open-source vulnerabilities under the CRA

When must a third-party open-source vulnerability be reported under the CRA?

Article 14 notification applies to a third-party or open-source vulnerability only when it is actively exploited in your own product. A scanner or advisory flagging a flaw in a library your product ships does not, by itself, trigger the 24-hour early warning. The guidance supplied with the regulation says other findings follow the upstream, voluntary and due diligence routes described below, and the first job is to establish which of those applies. Four facts change the answer. The first is reachability: can the vulnerable code path be called from your product, with the inputs an attacker could supply? A flaw in an unused function of a shipped library is a different case from one in a parser that handles untrusted network data. The second is exploitation evidence: is there credible indication that someone is exploiting the flaw against your product, not merely against the library in general? The third is your role: if you are the manufacturer placing the product on the EU market, the duties apply to you, while a maintainer publishing the library as free and open-source software without commercial activity is in a different position. The fourth is integration: how the component was pinned, patched, wrapped or configured in your build determines whether the flaw is exposed at all.

Whatever the outcome, the organization owns the decision and the notification. Record the assessment, the reasoning and the date you became aware, because those records are what an assessor or market surveillance authority will ask to see. Where a vulnerability is in a component you integrate, Article 13(6) also requires you to report it to the maintainer and share any fix you develop, even when no Article 14 notice is due. For findings that are reachable but not exploited, the Article 15 voluntary route is available. Confirm with your legal or product security lead how these routes are documented in your own process. DeployOpen can prepare the inputs this decision depends on: a software bill of materials covering at least top-level dependencies in a machine-readable format, as Annex I Part II requires, along with the vulnerability matching and integration evidence behind each finding. DeployOpen does not decide whether a notification is due, submit one on your behalf, or issue any report or certificate. Those decisions and filings remain with your organization, and any attestation of conformity comes from an independent assessor or certification body.

Four routes for a component vulnerability and what each requires

A vulnerability in a component you integrate can lead to four different outcomes under the CRA. Which route applies depends on whether the flaw is exploited in your product, whether your product reaches the vulnerable code, and whether your team found the flaw. Each route carries its own requirement, so the decision itself needs a record.

Article 14 notification for exploited flaws

Article 14 applies when a vulnerability in a component is actively exploited in your own product. Exploitation is the trigger, so the presence of a known flaw in a library alone does not start the notification duty. The reporting clock starts when you become aware of the exploitation, which means monitoring and escalation must reach the people who can judge it. Check whether your exposed functions reach the vulnerable code and whether exploitation appears in your logs.

Reporting to the maintainer

Article 13(6) applies when your team finds a vulnerability in an integrated component, including open source. You must report it to the person or entity maintaining that component and share any fix you develop. This duty runs alongside any Article 14 decision, so one finding can trigger both. Keep a record of the upstream report, the maintainer's response and the component version you ship.

Voluntary notification for unexploited findings

Article 15 allows any person to notify vulnerabilities, cyber threats, incidents and near misses voluntarily, to a CSIRT designated as coordinator or to ENISA. It suits findings that are unreachable or unexploited in your product. ENISA's FAQ says voluntary reporting through its platform is planned for a future phase, so confirm with the designated CSIRT which channel accepts voluntary reports today. Record that choice with the finding.

Documenting the decision not to notify

When a component finding does not meet the Article 14 trigger and you choose not to report it, the decision still needs a documented trail. Annex I Part II point (1) requires you to identify and document vulnerabilities and components, supported by a machine-readable SBOM covering at least top-level dependencies. Record the component and version, the reachability analysis, the exploitation check, the approver and the review date. A written decision lets an assessor test your reasoning.

How due diligence makes third-party vulnerability handling manageable

Due diligence under Article 13(5) is the step that makes third-party vulnerability handling workable, because it applies to components you integrate from third parties, including free and open-source components not supplied in the course of a commercial activity. The duty is to make sure those components do not compromise the product's cybersecurity. The organization owns that decision. Someone accountable for the product must decide which components are in scope, what checks each class of component receives, who approves an exception, and where the outcome is recorded. Tooling can gather the facts, but it cannot decide whether a component is acceptable for your product.

Annex I Part II point (1) asks manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. An SBOM generator or software composition analysis tool can produce that inventory from your build and lock files. What it cannot do is confirm that the inventory is complete. Ask your engineering team to confirm which build pipelines, vendored code and container base images are covered, and record that scope with the SBOM so an assessor can see its boundaries.

Commission FAQ 4.4.2 lists two checks that turn the inventory into findings: checking the European vulnerability database or other public databases for vulnerabilities in integrated components, and running software composition analysis. Schedule both, and keep dated records of each run, the database or tool version used, and the triage decision for every match. A finding that is unreachable or not exploited in your product is a judgment you must document, because it determines whether the Article 14 notification duty applies or whether a voluntary report under Article 15 is the better route.

What to do when a vulnerability lands in a component you integrate

Use this path when a vulnerability is published in a component you ship, but nothing shows it is exploited in your product. Article 14 notification is not triggered in this case, because that duty covers actively exploited vulnerabilities and severe incidents. Your task is to show that the finding was assessed, that a decision was made, and that the decision is on file. The Commission's guidance says unreachable or unexploited component vulnerabilities may be reported voluntarily under Article 15.

Confirm the component is in the shipped product: Match the advisory against the SBOM entry for the version you actually ship, not the version on a development branch. Owner: product security lead.
Assess reachability: Determine whether the vulnerable code path can be reached through your product's functions and configuration. Owner: security engineer with the component owner.
Decide on the fix: Schedule the upgrade or a mitigation through your normal release process and record the target release. Owner: engineering manager.
Consider a voluntary report: Article 15 allows voluntary notification to a designated CSIRT or ENISA. Confirm the current channel before relying on it. Owner: PSIRT lead, with legal review.
Keep the triage record: Save the advisory reference, the SBOM entry, the reachability reasoning, the decision and its date. Owner: product security lead.

Check that the triage record would still explain the decision to an assessor reviewing it later, including the reasoning for any component you chose not to upgrade immediately.

Who owns each step: your team, an implementation partner and the regulator

This table compares who owns each step when a vulnerability sits in a third-party or open-source component you integrate: your team, an implementation partner and the CSIRT or ENISA. Read each row as a split of decisions and records, not of tasks alone. The main takeaway is that the organization remains solely accountable for whether a notification is made and what it says.

Step	Your team (owns and decides)	Implementation partner (prepares, does not decide or submit)	CSIRT and ENISA (receive notifications)
Triage	Decides whether a component vulnerability is reachable and actively exploited in your product	Prepares triage workflow, scanning inputs and reproducible test evidence for your reviewers	Not involved
SBOM maintenance	Owns the SBOM, its accuracy and the decision on which dependencies are top-level	Sets up SBOM generation and machine-readable export tooling in your build pipeline	Not involved
Notification decision	Decides whether Article 14 applies or whether a voluntary report under Article 15 is made	Provides analysis and records that support the decision; does not make it	Not involved
Article 14 submission	Submits and is accountable for the early warning, intermediate and final reports	May prepare draft report content and test the internal submission workflow; does not submit	Receive notifications through the Single Reporting Platform; CSIRT designated as coordinator receives them
Upstream report	Reports the vulnerability to the component maintainer under Article 13(6)	Prepares the reproduction, patch analysis and disclosure package for your reviewers	Not involved
Fix sharing	Decides and shares any fix developed for the component	Builds and tests the patch in your release branch	Not involved
Evidence retention	Owns the retained records of triage, decisions, reports and upstream correspondence	Configures retention of scan results, SBOM versions and ticket history	Not involved

How to set up a third-party vulnerability workflow before the first finding

This sequence builds the inventory, matching, decision and upstream reporting steps a manufacturer needs in place before a vulnerability in an integrated component arrives, so that each finding can be triaged and recorded without improvising. Each step ends with a named output that an assessor or a CSIRT could ask to see.

Inventory every component through an SBOM
Generate a software bill of materials for each product version you place on the market, in a commonly used, machine-readable format, and cover at least the top-level dependencies. Engineering owns the generation step, and product security reviews the output for gaps such as vendored code, container base images and components pulled in at build time. The step is done when each product release has a stored SBOM tied to its version number, and you can name the owner of every listed component.
Define how advisories are matched to products
Decide which sources you check for vulnerabilities in integrated components, such as the European vulnerability database, other public databases and the advisory feeds of your key maintainers, and how often each source is reviewed. Set up software composition analysis against the SBOM so that a new advisory is matched to the exact component versions and products it affects. The output is a written matching procedure and a sample run that shows an advisory traced to a specific product release.
Assign triage and notification decision roles
Name who triages a matched finding, who confirms reachability in your product, and who decides whether the Article 14 duty applies. Triage is usually a product security or engineering role, while the notification decision should sit with a named person who has authority to act, with a deputy. Record the separation in a responsibilities table so that the decision is not made informally in a chat thread. The output is that table, signed off by the accountable manager.
Set the test for active exploitation in your product
Write the criteria that separate a vulnerability that is actively exploited in your own product from one that is unreachable or unexploited there. The Commission's guidance says only the first kind must be notified under Article 14, while the second may be reported voluntarily under Article 15. Your criteria should cover how you confirm that the vulnerable code path is reachable, how you check for exploitation signals in your telemetry and support records, and what evidence you keep. The output is a short decision standard that triage staff apply consistently.
Prepare upstream reporting and fix sharing
Under Article 13(6), when you find a vulnerability in an integrated component, including open source, you must report it to the entity maintaining that component and share any fix you develop. Identify the maintainer and the preferred private channel for each high-use component, and agree how patches will be returned upstream under the project's license and contribution rules. Keep a template for the upstream report. The output is a maintainer contact register and a reference field in your tracker that records the upstream report identifier.
Record every triage and decision
Log each matched advisory in a triage log that shows the component, product versions, reachability finding, exploitation finding, the decision taken, the person who took it and the date. Where you decide the Article 14 duty applies, link the decision record to the reporting workflow used for that notification. Where you decide not to notify, record the reasoning so that a later assessor or market surveillance authority can follow it. The output is a complete log in which each matched advisory has a decision and an upstream reference or a stated reason for none.
Test the workflow with a dry run
Before the first real finding, run the sequence on a historical advisory or an illustrative test vulnerability in a non-production component. Check that the SBOM lookup returns the right products, that the decision roles respond, that the upstream template reaches a maintainer channel and that the triage log captures every field. Confirm each gap with the people who run the process, then fix it and repeat the dry run until the record is complete. The output is a dry-run report that lists the gaps found and how they were closed.

Where third-party vulnerability handling usually breaks down

Most CRA problems with third-party code are not exotic. They come from missing inventories, unclear triage and undocumented decisions. The cards below cover six failures we see most often and the step that prevents each one.

No SBOM, so nobody knows the component ships

If the product has no software bill of materials, the team cannot say which open-source libraries it contains, so a published advisory never reaches the people who must act on it. Annex I Part II point (1) expects manufacturers to identify and document components, including at the very least the top-level dependencies, in a commonly used, machine-readable format. Generate the SBOM from each release build, not from a manual spreadsheet, and check that it lists the components actually shipped.

Treating every CVE as notifiable

Teams often forward every advisory in a dependency to ENISA as a precaution. The guidance says a third-party vulnerability must be notified under Article 14 only when it is actively exploited in the manufacturer's own product. Unreachable or unexploited findings may be reported voluntarily under Article 15. Write a triage step that asks whether the vulnerable code path is reachable in your product and whether exploitation has been observed there, before deciding the reporting route.

No record of why a finding was not notified

A finding that is judged unreachable or unexploited still needs a record. Without one, an authority asking why a known advisory was not reported has no evidence that the decision was made. For each third-party finding, keep the component and version, the advisory reference, the reachability analysis, the exploitation check, the decision, the person who made it and the date. Store the record with the vulnerability tracker so it stays linked to the release it concerns.

No maintainer contact path

Article 13(6) requires a manufacturer that finds a vulnerability in an integrated open-source component to report it to the entity maintaining that component and to share any fix it develops. Many teams only learn the maintainer exists after an incident. Before a component enters the product, record its repository, its security contact or private disclosure channel, and the maintainer's response expectations. Test that the channel works while nothing is on fire.

Forks that drift from upstream

A patched fork of an open-source library is usually created to fix one problem and then left behind. Over time it diverges from upstream, misses later security fixes and becomes a component no one tracks. Each fork should carry a documented upstream reference, a list of local patches, and a scheduled review against upstream releases. Any fix written for the fork should be offered back to the maintainer, as Article 13(6) expects for fixes developed by the manufacturer.

Dependencies pulled in by build tools and containers

Components that never run in the product, such as build plugins, test utilities and base container layers, are often left out of the inventory. Some of them still reach the shipped artifact, and a container image can carry hundreds of OS packages. Scan the final build artifact and container images, not only the application manifest, and confirm with the scanner's documentation which layers and dev dependencies it includes. Record the scope of each SBOM so reviewers know what it does and does not cover.

What must be in place before the first vulnerability arrives

The clock on a third-party vulnerability starts only when your organization is aware of it, so the readiness work has to happen before any advisory lands. The first item is a current software bill of materials that lists at least the top-level dependencies in a commonly used, machine-readable format, as Annex I Part II point (1) expects. Without it, you cannot tell whether a newly published flaw in a library touches your product. Confirm with your engineering leads that the SBOM is generated from the build, not maintained by hand, and that it is refreshed on each release. Also confirm which integrated components you received from outside your commercial relationships, because Article 13(5) due diligence applies to free and open-source components too.

Next, name one owner for triage and a deputy, with written authority to classify a finding as unexploited, reachable or actively exploited in your own product. Pair that with a decision record template that captures the date and time of awareness, the component and version, the exploitation analysis, the reasoning behind any decision not to notify, and any voluntary report under Article 15. Keep a short list of maintainer contacts for your critical components, including the channel each maintainer prefers for security reports, since Article 13(6) requires you to report vulnerabilities you find to the maintainer. Finally, agree a fix-sharing process, covering who reviews a patch you develop, how it is offered upstream, and how the licence terms of the component affect that offer. Your counsel should confirm the licence and contract points, and your own assessors may review the assembled evidence where needed. Whether this readiness evidence satisfies your obligations is ultimately a question for your organization and its legal advisers, not for an implementation partner.

Common questions about third-party vulnerabilities under the CRA

Do we have to notify every CVE in an open-source library under the CRA?

No. A vulnerability in a third-party component must be notified under Article 14 only when it is actively exploited in your own product. The guidance published with Communication C(2026) 5252 draws this line. A CVE that is unreachable in your product, or that no one is exploiting there, does not trigger the 24-hour early warning on its own. You still need to know it exists, assess whether your product is affected, document that assessment, and track the fix. If the vulnerability is exploited in your product, the Article 14 clock applies regardless of where the flaw originated. Confirm the reachability reasoning with your own legal and security team before relying on it, and keep the assessment on file so an authority can see how the decision was made.

Can we report a component vulnerability upstream to the maintainer instead of the CSIRT?

Upstream reporting and CSIRT notification serve different purposes, and for exploited vulnerabilities in your product, upstream reporting does not replace Article 14. Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component, including open source, to report it to the maintainer and to share any fix it develops. That duty sits alongside the Article 14 duty. In practice, many teams report to the maintainer first, coordinate a fix, and notify the CSIRT when exploitation in their own product triggers the obligation. Ask counsel to confirm the sequencing for your case, because the timing of the early warning does not pause while you wait for an upstream response.

What does voluntary reporting under Article 15 add for us?

Article 15 lets any person notify vulnerabilities, cyber threats, incidents and near misses to a CSIRT designated as coordinator or to ENISA, on a voluntary basis. For third-party components, it lets you flag a vulnerability that is not exploited in your product, such as an unreachable flaw in a library you ship, so that the wider ecosystem can benefit. It does not create the Article 14 obligation and does not reduce it. ENISA's platform FAQ states that voluntary reporting through the platform is planned for a future phase, so confirm the current channel and CSIRT with the relevant authority before you plan around it. Decide in advance whether voluntary reports fit your disclosure policy.

How much effort do SBOM and due diligence take, and what drives it?

Effort depends mostly on how many components you integrate, how deeply your dependency tree goes, and how much of your build is automated. Annex I Part II point (1) requires you to identify and document vulnerabilities and components, including an SBOM in a commonly used, machine-readable format that covers at least top-level dependencies. Article 13(5) requires due diligence on third-party components, including open source not supplied in a commercial activity. Commission CRA FAQ 4.4.2 lists checking public vulnerability databases and running software composition analysis as examples. The main drivers are the number of components, whether SBOM generation runs in your build pipeline, how often you release, and whether vulnerability matching is automated. Ask any provider to quote the scope by product and release cadence, and to state which parts recur, such as monitoring and SBOM refresh.

Can our own engineering team handle third-party vulnerability reporting?

Yes, many teams can, provided the responsibilities are assigned and the process is written down. The organization owns its controls and the decisions about notification, so a named owner for the exploitation assessment, the reporting clock and upstream coordination is essential. The work usually includes an SBOM generated in the build, a feed of public vulnerability data matched against it, a triage procedure, and a record of each decision. Open-source tooling can produce much of the evidence, and a self-hosted platform can keep the SBOM and triage records inside your own infrastructure. Confirm that your team has the time to run triage around the clock during an active incident, since the early warning deadline does not depend on working hours.

Does bringing in a partner make us CRA compliant?

No. Compliance is the manufacturer's responsibility, and no partner can make a product compliant on your behalf. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms in your own infrastructure, and it can prepare SBOM pipelines, vulnerability workflows and evidence for your team to review. It does not issue conformity declarations, audit reports or certifications. Where a conformity assessment route requires a notified body or other independent body, that body issues the outcome. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, so ask for the scope in writing and confirm with your legal adviser which obligations stay with you.

How DeployOpen prepares SBOM, triage and evidence for CRA component reporting

DeployOpen works with the manufacturer on the component side of the Cyber Resilience Act: the software bill of materials, the triage record for vulnerabilities in integrated open-source components, and the evidence showing due diligence and upstream reporting. The organization keeps ownership of its reporting decisions, and DeployOpen prepares the systems and records that support them.

How we scope

Written scope lists which products, components and repositories the component reporting work covers, agreed before work starts.
Scope names the systems that hold build records, SBOM output and vulnerability tracking data, so evidence sources are known.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work begins.

How we build

We set up SBOM generation in a commonly used, machine-readable format covering at least top-level dependencies, inside your build pipeline.
We connect software composition analysis and public vulnerability database checks to the component inventory, run in your environment.
We build a triage workflow that records whether each component vulnerability is reachable and actively exploited in your product.

How we hand over

Deliverables include the SBOM pipeline configuration, triage procedure, decision log template and upstream reporting records.
Documentation explains how each finding moves from identification to a notification decision, a voluntary report or a documented no-action outcome.
Handover sessions walk your security and engineering staff through running the workflow without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for SBOM tooling and triage workflows as components change.
We can help your team prepare upstream reports and share fixes with component maintainers, while your team decides what is sent.
Our role ends at preparation: independent auditors and certification bodies issue any reports or certificates, and the organization owns its compliance decisions.

Reporting vulnerabilities in third-party and open-source components under the CRA