When you find a flaw in a component you ship, report it privately to the maintainer through their published security contact, with a clear reproduction, the affected versions and your proposed timeline. Protect your customers in parallel, and do not publish details until the maintainer has had a fair chance to fix it.
Why this is part of vendor response
Vendors tend to think of vulnerability response as incoming advisories. But your own testing and customer reports will also find flaws in libraries. The EU Cyber Resilience Act's Annex I Part II asks manufacturers to facilitate the sharing of information about potential vulnerabilities in their product and in third party components in it, including a contact address for reports. So reporting upstream is a normal duty of a careful maker, not a favour.
Find the right channel
- Look for a security policy in the project repository.
- Look for a security.txt file at the project's site. RFC 9116 defines it at /.well-known/security.txt, with Contact and Expires fields.
- Check whether the project is a CNA or uses a private advisory feature on its hosting platform.
- If none exists, contact a maintainer privately and ask how they want reports sent.
- Do not open a public issue for an unfixed security flaw.
What to send
| Item | Detail |
|---|---|
| Summary | One paragraph on what is wrong |
| Affected versions | What you tested, and what you did not |
| Reproduction | Minimal steps or a test case |
| Impact | What an attacker gains |
| Your constraints | Your shipping dates and any need to notify customers |
| Proposed timeline | A date for coordinated disclosure, open to discussion |
| Contact | A person who will answer |
Protect customers meanwhile
- Check whether your product exposes the flaw, using your SBOM index and reachability.
- Prepare a mitigation in your own code if one is possible.
- Draft an advisory, held back until the maintainer's fix or the agreed date.
- If the issue is exploited in the wild, your own reporting duties may apply. For products in scope of the CRA, Article 14 sets 24 hour, 72 hour and 14 day steps, and applies from 11 September 2026.
Etiquette
Be patient and specific. Offer a patch if you wrote one. Credit the maintainer in your advisory. If they do not answer, follow a coordinated disclosure policy, such as a published timeline, and escalate through a coordinator before going public. More on policy design is in the coordinated vulnerability disclosure guide.
After the fix
Update your SBOM, mark the status in your VEX, notify affected customers and thank the maintainer. A short public note about how you worked with them helps others.
Quick check
What if the project has no security contact?
Contact a maintainer privately and ask how to send the report. Avoid a public issue.
Can we fix it ourselves and say nothing?
You can ship a mitigation, but silent forks leave other users exposed. Share the report and the fix with the maintainer.
Safeguard's zero-day discovery and reachability analysis can help vendors investigate flaws in the components they ship. A free scan is available.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Annex I Part II and Article 14
- RFC 9116, security.txt
Last reviewed: 19 October 2026.
