Accuracy. Details in the report must be accurate.
They should be technically correct and evidenced
appropriately. Someone performing QA will be looking for signs
that each finding wasn't a false positive.
If during testing assumptions were made and never proven,
then it's possible to report findings that don't actually
exist. That could waste a lot of time in remediation.
Guidance on risk is important here too.
If a vulnerability like cross‑site scripting exists, then it's definitely a
finding. If there are mitigations that limit its usefulness,
then risk and severity scores should reflect that, not just the worst case.
If you can use it to steal session cookies,
then there should be evidence, like a screenshot. Typos.
Spell checkers don't always pick these up,
but using one is a good start.
Hyperlinks can be challenging because often the URL isn't visible.
You have to hover over it or click it to check. Maybe the web page
was removed or there's a typo in the URL.
If Kim mentions the SMB protocol, she'll mention the version if it's appropriate.
If it's the EternalBlue vulnerability,
then she states SMB version 1 because it only happens in version 1. Clarity.
The report should use language that conveys messages in an unambiguous way.
It should be very clear to the audience what their vulnerabilities are,
how to fix them, and the risks they present.
It's easy to write a report with the assumption that readers
have a similar level of knowledge to you. Vincent at Carved
Rock is a security engineer,
so likely to be well versed in most but not all vulnerabilities in a report.
Many readers won't be that knowledgeable.
How do we help clarity? Did we use an abbreviation?
Every time Kim does, it gets stated as the expanded
version the first time it's used.
So if she writes denial of service, it gets the DoS in brackets.
Just the abbreviation DoS is then used any other time it's needed.
Domain‑specific wording is important to get right.
If Kim mentions password cracking,
she'll add an explanation and maybe even a hyperlink for more information.
There are lots of words like this in security, rainbow tables,
dictionary attacks, buffer overflows.
Try to keep this in mind.
Kim gives step‑by‑step walkthroughs for findings because it
can really help a reader to understand them.
Often, images helped too, although, if they show use of the command line,
Kim will add the command text to the document so it can be
copy and pasted to reproduce findings.
Writing a report in a consistent manner helps too. If two pen testers work on a
report and write up findings in completely different ways,
then this makes it complicated for the reader.
This gets easier when everyone writing a report is using
similar templates and has the same requirements.
Generally, readers want a report to be concise to get to the point quickly.
They'd rather not spend hours reading a report, nor do they want
page after page of text with no interruption.
However,
if we're trying to explain everything accurately and clearly with the
assumption that readers have only a basic understanding,
then that can mean a lot of words.
We need a balance here.
We want to give enough information, but don't want to put someone off because
there's too much text. Looking at Kim's executive summary,
that's half a page long.
It is a summary after all and shouldn't contain huge amounts of detail.
It also uses bullet points that help keep it short.
Kim chooses her wording carefully here and makes
sure she doesn't repeat anything.
Getting information across with minimal wording is a skill
in itself and takes practice. In the findings, Kim gives
information clearly and concisely,
but uses hyperlinks to give depth to help readers who don't
have as much knowledge on the subject.
This really helps to reduce the overall size of the report.