Third-party library response needs both upstream and product-level action. The manufacturer owns the security outcome for the finished product even when the vulnerable code originated elsewhere.
Confirm Whether the Product Actually Contains the Vulnerable Version
Use release-linked SBOM and component records to confirm whether the affected library and version are present in supported product releases. Avoid assuming exposure from a repository dependency file that may not match the shipped build.
Assess Product-Specific Impact
Determine whether the vulnerable functionality is reachable, what privileges and data are involved, what attack conditions apply and how the vulnerability changes the product's cybersecurity risk. This supports prioritisation and the choice between immediate mitigation and full remediation.
Notify the Upstream Maintainer
Where the manufacturer identifies the vulnerability in the integrated component, Article 13 requires notification to the component manufacturer or maintainer. Follow coordinated reporting channels where available and avoid unnecessary public disclosure before the issue can be handled safely.
Choose the Remediation Path
Options can include upgrading to a fixed release, backporting a patch, disabling vulnerable functionality, replacing the dependency or maintaining an internal fix. The selected action should reduce the product risk while preserving intended functionality and compatibility.
Share Relevant Fixes Upstream Where Appropriate
If the manufacturer develops a modification to address the component vulnerability, Article 13 requires relevant code or documentation to be shared with the component manufacturer or maintainer where appropriate. This can reduce divergence and help the broader component ecosystem.
Test the Fix in Product Context
A library update can change APIs, behaviour, cryptography or resource use. Security remediation should therefore include regression and security testing against the actual product rather than treating successful package installation as sufficient evidence.
Release the Security Update and Track Adoption
Where a security update is needed, release it through the product's supported update mechanism and maintain evidence of the affected versions and corrective release. User communication should be proportionate to the risk and support secure installation.
Record Why No Fix Was Required
If analysis concludes that the product is not affected or that a mitigation is sufficient, preserve the reasoning and evidence. A closed vulnerability should show why the decision was made, not simply a status label.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.