Coordinated disclosure
Vendor first. Public second.
How Maple Labs handles a vulnerability it finds in someone else’s software, and how to tell us about one in ours.
Deadlines
Ninety days, then we publish.
The clock starts when the vendor receives our report. Deadlines give vendors a fair chance and users an answer either way.
- 90 daysTo fix, from our report. If a fix ships sooner, the advisory follows 30 days after the fix, so people can update first.
- 7 daysWhen we have evidence the vulnerability is being exploited in the wild, because users need to know now.
- +14 daysOnce, if the vendor shows us a fix scheduled to ship within that grace period.
The policy
How it works, step by step.
1. We report privately
We find the vendor’s security contact (its security.txt, its product security team, or its CVE Numbering Authority) and send the details, the evidence, and the date the deadline falls. If no one answers within 14 days, we ask CERT/CC to help reach them.
2. We coordinate
We help the vendor reproduce the issue and check their fix when they ask. Nothing about it is published or shared while they work, apart from what a CVE request needs.
3. A CVE is assigned
Through the vendor’s CNA when it has one, or MITRE’s CNA of last resort when it does not. Maple Labs is not a CNA and never assigns a CVE number itself.
4. We publish
An advisory in our database and in advisories.json: what is affected, its CVSS score and vector, the fixed version, and the timeline. Proof-of-concept code is published only once a fix is available.
5. Exceptions
A vendor and Maple Labs may agree a different date in writing when the fix is genuinely hard, for example in hardware or firmware. We say so in the advisory’s timeline.
Found one in our software?
Email the lab with what you found and how to reproduce it. That covers Mirrored Maple’s products and services too. Please give us the same chance to fix it that we give others.