As a last point on ensuring report quality, it's worth a look at some
specific examples of what can go wrong. First, conciseness. I've seen
60‑page reports with just a few findings in them.
It is difficult to say exactly how long a report should be.
It depends on lots of things.
Typically, a report with only a few findings shouldn't
be more than about 20 pages long.
Conversely, I've also seen things get too concise.
A good example is remediation. It should never say don't do that.
Don't use SMB version 1, for example. There should always be more detail.
A single sentence isn't usually good enough for remediation on a finding.
Once you've got a templated list of historic findings, this all gets easier.
We'll talk about that more in the next module. For accuracy, it's
common to see a lack of QA on reports, either not being done or not
done well. This can manifest in different ways.
For example, findings in the report that are clearly false positives.
I've seen the wrong company name in the report. Copy and paste is very
dangerous. Documenting findings that are out of scope.
Finding severity being seriously overestimated. Stating that an attacker could
use the vulnerability to do something that they can't actually do or that
there's been no effort to prove it in the report.
Having duplicated findings in the report possibly because two
testers have worked on it. Typos and spelling mistakes. It can be
difficult to remove every last one of these,
but it does look bad if your report is filled with them. For clarity,
there are some common mistakes too.
For example,
using screenshots instead of text when the reader might
need to repeat the text. It's much nicer if they can copy
and paste it. Missing details,
such as exactly how you repeat a finding. The executive summary
making no attempt to chain vulnerabilities together. And even a
simple one like missing borders on images.
Let's see an example of that last one. On the left, we can see an
image in the report with a border around it,
on the right, an image without a border.
Using a border makes it much clearer that it's an
image and not some text in the report.
It really helps with clarity. Problems range from just bad
practice all the way up to making your pen test company
look very bad to its customers.
Creating high‑quality reports is a tough job.
It's a lot more than just checking for tables. I've read and
performed QA on a lot of reports. In this module, we've covered
things that can make the difference between good and bad. Writing
reports well can be time consuming,
but ultimately a critical part of the test. A good pen test needs a good report.