Secure reports should have a table of scan type and types of error found for each scan

Generally, once you find SQL Injection or Cross Site Scripting for a parameter, you don't need to know the hundreds of other exploit strings that also worked. The important information for the developers is that parameter x has Cross Site Scripting vulnerabilities or stack trace errors. So a table with 2 columns (scan type, issue type)  that had a row for every distinct combination of scan type (e.g. SQL injection) and issue type 'sensitive data returned' or 'stack trace' would be very useful. If some requests worked and some failed the developers can always look at the report for the specific strings, but generally if you are not validating or escaping input, the specific strings that caused the issue don't matter.