This page explains how ut researchers will deal with vulnerabilities found in third party systems during their research.
Summary
We immediately contact the appropriate responsible party/vendor and inform them of the security vulnerabilities we found. We expect the affected party to respond within 21 days and let us know how the flaws will be mitigated to protect users. If we don’t hear back within 21 days after reporting, we explain our publication timeline and give another opportunity to get in touch to discuss this timeline.
If no reasonable fix or update is available after 90 days from the reporting date, we consider disclosing the vulnerabilities publicly. Nonetheless, we are willing to negotiate the publication date, in cases where 90 days are not sufficient to release proper patches.
Reporting
- We make a reasonable effort to find the right contact for reporting a vulnerability, such as an open-source project maintainer, taking steps to find the right way to securely get in touch with them. We will use contact methods including but not limited to emailing security reporting emails (security@ or secure@), filing bugs without confidential details in bug trackers, or filing support tickets.
- We expect contacts to acknowledge our reports as soon as possible and to confirm whether we provided sufficient information.
- We also might contact software distributors in case we receive no reply from vendors. For instance, in case of vulnerabilities found in an Android app present in the Google Play Store, we will contact Google.
- Where necessary we will request assistance from the NCSC, who can handle “large”, complex disclosure processes (e.g., involving many vendors).
Mitigation & Timeline
- When possible, we discuss and work with the affected party to design and test potential mitigation and fixes for the discovered vulnerabilities.
- If no fix is available at the end of the agreed publication date (e.g., after 90 days), we notify the contact of our intent to disclose the reported issue.
- If there are no mitigating circumstances, we disclose the issue as soon as we are reasonably able to do so.
Disclosure
- Depending on the nature of the problem, there may be a few disclosure paths: 1) we disclose the vulnerability publicly, 2) we disclose it directly to the people using the project, or 3) we issue a limited disclosure first followed by a full public disclosure. We work with the contact to determine which approach is most appropriate in each case.
- Our intent is to disclose vulnerabilities in a way that is most helpful to the community. For example, we may include guidance on workarounds, methods for validating patches are in place, and other material that helps people contain or remediate the issue.
- We include a timeline to document communication and remediation actions taken by both parties. Where reasonable, our disclosure includes suggested steps for mitigating actions.
Additional Considerations
- When negotiating publication dates, we evaluate each issue on a case-by-case basis based on our interpretation of the risk to people.