Writing the description of a report

The second part of the report is the description. A description must be precise, clear, and to the point. Program owners want to have direct engagement with any text so they do not have to read much and can pick out the salient points easily. The description should not be something generic; it should be environmental and scenario-specific. This allows report readers to relate to the reports closely rather than thinking of them as generic.

Describing a vulnerability is not an easy task for a reporter. However, a method to describe a flaw in a to-the-point and a clear way is to provide links for issues that can help program owners understand, identify, and resolve the issues in a report. The reference links can be taken from technical resources, such as stack overflow, the Open Web Application Security Project (OWASP), and so on. It is not advised to copy and paste links and descriptions from automated tools and online sites. This gives a very bad impression about the reporter and shows that they did not have time even to write their own general report.

An example of a good description would be similar to the following one:

An example of a bad description would be something like the following: