What should a security audit report include?

There's a couple of ways that I've seen this done, each has it's pros and cons.

As noted by @RoryAlsop below a common point for both approaches is that the executive summary should, as much as possible, be written for a business audience (assuming that it's a test you're doing for a 3rd party or the report will be passed to management).

• Reporting by finding. Here you list the findings, usually ranked by severity (e.g. CVSS score or some other scale like severity/likelihood). You then list out the technical details of the finding and potential mitigations if you have that information. This kind of report gets to the point quite quickly and plays well with tool output.
• Reporting by methodology. Assuming here that you're following a defined testing methodology, the report is structured along the lines of the methodology and includes a section for each area of the review. The sections detail what testing was done and the outcome (e.g. either a finding or the fact that there was no finding in this section). The advantage here is that you're showing your workings and that someone reading the report can get a good idea that you've actually tested something and it was ok rather than you just having missed it out. The downside is that it tends to be a longer report and harder to automate. One other gotcha is that you need to make sure that the testers don't just follow the methodology and they actually engage brain to look for other things.

In terms of format for the findings, I usually include the following

• Title (descriptive gets used in the table and linked to the detail)
• Description - technical description of what the issue is and importantly under what circumstances it is likely to cause a security issue (e.g. for Cross-Site Scripting one of the potential issues is use to grab session tokens which could allow an attacker to get unauthorised access to the application)
• Recommendations - How the issue should be resolved, where possible include specific details on vendor guidance to fix it (e.g. things like removing web server versions from headers have specific instructions for Apache/IIS etc)
• References - Any links to additional information that's relevant to the finding (e.g. links to the relevant OWASP page for Web app. issues)
• Severity. As I mentioned above this could be CVSS or something more general like High/Medium/Low based on impact and likelihood.
• Other classification as needed by the client. For instance some client might need things lined up against a standard or policy or something like OWASP Top 10.

One other point to make is that if your do a lot of tests it's well worth having a database of previous findings to avoid having to look up references repeatedly and to make sure that severities are consistent.

Exciting question! Too often I feel that our industry strives for the latest and greatest fad in security. We go after the latest exploits, spend serious cash on the latest tools and blame layer 8 for the gaps. I know that is a gross generalization, but I wanted to underscore the importance of this topic -- Reporting!

I have my opinions as to what should be included in a Vulnerability report. From a structure perspective a thorough report will have the following:

• A title page: this will indicate the report name, the agency or department it is for, the date as to when the report was published.

• A table of contents: Seems obvious, but these documents can get lengthy, include this as courtesy.

• An executive summary: This will be a high level summary of the results, what was found and what the bottom line is.

• An introduction: A simple statement of your qualifications, the purpose of the audit and what was in scope.

• Findings: This section will contain your findings and will list the vulnerabilities or issues that should be re-mediate. This listing should be ordered by critical levels, of which are hopefully defined by internal policies (i.e. if your vulnerability scanner finds a high critical vulnerability, based upon how that vulnerability is implemented in your environment, it may not be a true high critical, so internal policies should assist in defining the critical levels)

• Methodologies: Here you will discuss tools used, how false positives were ruled out, what processes completed this audit. This is to provide consistency and allow your audits to be repeatable in the event a finding is disputed or deemed not worthy of fixing by management.

• Conclusion: Basic conclusion, summarize the information you have already put together.

• Appendixes: This will be any extra attachments needed for reference.

Some of the folks over working on the PTES are laying down some good foundations. While the focus there is penetration testing, I would think that many of the methodologies, especially reporting, could be transposed for an audit. You can check them out at http://www.pentest-standard.org/index.php/Reporting.

After a Penetration Test or Hybrid Application Analysis the resulting report is centered around the findings. There should be a high level overview that discusses the flaws and their collective impact on the system.

A finding is any security violation. This includes any CWE violation, but the most common web application findings fall under the OWASP top 10. Each finding should have steps to reproduce the problem, a severity, the impact of this flaw, recommendations for fixing the issue and links with more information. For example if you find an XSS vulnerability, show a screen cap of an alert box and the URL you used to trigger the issue and link to the OWASP page on XSS. If you can access the cookie with XSS, then the issue can be used to hijack a session, otherwise it could be used to undermine CSRF protection.

What if you can't find anything? Keep looking! The CWE system is massive, and even the most seasoned develops will make mistakes. There are vulnerabilities that affect literately every application I have touched. Clickjacking, lack of brute force protection, and Information disclosure is probably the most common. For example username/email address disclosure via the forgotten password or signup feature. Displaying version numbers (http headers or anywhere else). Verbose error messages, local paths, internal ip addresses.... anything that might be useful to an attacker.