Page History

...

As a vendor, it is important to not treat reporters with suspicion or hostility. It's likely they have important information about your product, and they want to share it with you.
Furthermore, vendors should take care not to frustrate reporters' attempts to make contact by building too many assumptions into their CVD process.

In the course of our own vulnerability coordination efforts, we have observed all of the following erroneous assumptions built into vendor's CVD process:

...

Reporting a vulnerability requires that the vulnerability is well-documented. This typically means providing the following information:

• the The exact product version(s) affected
• a A description of how the vulnerability was discovered (including what tools were used) or what you were doing when you encountered the vulnerability
• proof Proof of concept (PoC) code or reproduction instructions demonstrating how the vulnerability might be exploited
• ideallyIdeally, a suggested patch or remediation action if the reporter is aware of how to fix the vulnerability

• dDescription of the impact of the vulnerability and attack scenario (Kymberlee Price discusses the importance of providing a clear attack scenario in her article [1]).

• any Any time constraints (for example, give a date of publication or presentation at a conference if you know)

...

Reporters that do not provide enough information to a vendor or coordinator may find their reports delayed or even rejected. Using CWE [2] or CAPEC [3] as a reference might be helpful to describe the type of vulnerability you have found and common ways to fix it the problem.

An example of a template for a vulnerability report, based on the CERT/CC's own Vulnerability Reporting Form (VRF) [4], is provided in Appendix D. Vendors that require additional information to validate reports should clearly document their specific requirements in their vulnerability disclosure policy, reporting form, or process description.

References

1. K. Price, "Writing a bug report - Attack Scenario and Impact are key!" 2 August 2015. [Online]. Available: https://forum.bugcrowd.com/t/writing-a-bug-report-attack-scenario-and-impact-are-key/640. [Accessed 17 May 2017].
2. MITRE, "Common Weakness Enumeration (CWE)," [Online]. Available: https://cwe.mitre.org/. [Accessed 17 May 2017].
3. MITRE, "Common Attack Pattern Enumeration and Classification," [Online]. Available: https://capec.mitre.org/. [Accessed 17 May 2017].
4. CERT/CC, "Vulnerability Reporting Form," [Online]. Available: https://vulcoord.cert.org/VulReport/. [Accessed 17 May 2017].