Reporting

01 The report is the deliverable

Here is the uncomfortable truth that closes this whole phase. Nobody hires a penetration tester to break into their systems. They hire one to make their systems harder to break into, and that improvement only ever happens through a report somebody can read and act on.

Everything you practised across Phase 02, the reconnaissance, the scanning, the exploitation, the privilege escalation from lesson 02.9, is the means. The report is the product. A client never watches you work. They were not in the room when you found the flaw. The only thing that reaches them is the document, and they will judge the entire engagement by it, because it is all they can see.

This reverses the instinct most beginners have. They treat the write-up as paperwork to rush through after the interesting part is over. In reality it is the opposite: the hacking is the input, and the writing is the job you are actually paid for.

So the standard to hold in your head for the rest of this lesson is blunt. A brilliant exploit, badly written up, helps no one. It does not get fixed, the risk stays exactly where it was, and the client paid for nothing. A modest finding, clearly explained with exact steps and a concrete fix, gets closed the same week and genuinely reduces risk. The second engineer did the more valuable work, even though the first one had the better exploit.

If you take one thing from this page, take this: an unfixed vulnerability and an undiscovered one are equally dangerous to the client. Your job is not finished when you find the flaw. It is finished when someone who can fix it understands it well enough to do so.

02 One report, several very different readers

The hard part of a report is not the technical content. It is that a single document has to satisfy readers who want completely different things and have completely different backgrounds. Write for one of them and you fail the others.

Three audiences read almost every professional report, and they read different parts of it.

Notice these are not just different levels of detail. They are different kinds of information. The executive does not want a simplified version of the engineer's steps. They want a sentence about money and reputation that the engineer's section never mentions at all.

This is the whole reason a report has the structure it does. It carries an executive summary at the front, written for the people at the top, and deep technical findings in the body, written for the people at the base. It is not padding or repetition. It is one document deliberately speaking to three audiences, each in their own section, so each can read only the part meant for them and still get what they came for.

03 Anatomy of a single finding

The body of the report is a list of findings. A finding is one vulnerability, written up on its own. This is the unit an engineer works from, so getting its shape right is most of the craft.

Every professional report uses roughly the same fields for each finding. The order and names vary between firms, but the content is a near-constant. Learn this template and you can write a finding for any bug you ever discover.

Two fields carry more weight than beginners expect. Steps to reproduce is the field engineers respect most, because a bug they can reproduce is a bug they can fix and verify, while one they cannot reproduce gets marked "could not replicate" and quietly closed. And impact is the field that gets the fix funded, because it is the only one written in the language of consequences rather than mechanics.

04 Rating severity so it means the same to everyone

Every finding needs a severity, because managers order the whole report by it. The problem is that "high" means different things to different people. The industry solved this with a shared scoring system so that "how bad is it" gets a number instead of an adjective.

That system is CVSS, the Common Vulnerability Scoring System. You met it in the glossary alongside CVE: a CVE is the public identifier for one specific known vulnerability, and CVSS is the score that says how severe a vulnerability is, on a scale from 0 to 10. The higher the number, the worse the flaw.

The score is built from factors like whether the attack works over the network or needs local access, how complex it is, whether the attacker needs to be logged in first, and how much damage a successful attack does to confidentiality, integrity and availability. You do not need to compute it by hand yet; free online calculators turn those factors into the number. What matters now is understanding why the system exists: it lets a finding you wrote and a finding someone across the world wrote be compared on the same scale.

The number is a starting point, not the verdict

Here is the part that separates a report writer from a calculator. CVSS scores the vulnerability in the abstract. It does not know your client's business. The real-world risk can sit above or below the raw score, and a good report says so.

Recall the equation from lesson 01.6: risk equals likelihood times impact. CVSS is mostly a measure of impact and ease. Business context supplies the rest.

Same flaw, same 9.8, two different real risks. A mature report keeps the CVSS score for comparability and then adds a sentence of business context that adjusts the priority. Reporting the raw number and stopping is lazy; the client's own situation is exactly the value they are paying you to bring.

Score these four findings and watch how the metrics move the number.

05 Remediation that actually gets done

The remediation line is the reason the finding exists. It is also the field beginners write worst, because it is tempting to end on something that sounds responsible and says nothing.

A good remediation is specific, actionable and prioritised. Specific means it names the exact change, not a virtue. Actionable means an engineer could start on it today without a research project first. Prioritised means it is clear how urgent it is relative to everything else in the report.

The test is simple. Read the remediation and ask: could an engineer open a file and start typing? If the answer is no, you have written advice, not a fix.

Read the strong version again and notice what it gives the engineer: the exact location, the exact technique with its proper name so they can look it up, the scope of the change (this query and three others), and the urgency. There is nothing left to interpret. That is a remediation that becomes a closed ticket by Friday.

"Be more secure" is the anti-pattern to watch for in your own writing. Every time you catch yourself writing a remediation that would be equally true for a completely different bug, you have written nothing. Delete it and name the actual change.

06 The executive summary

The first page of the report is the executive summary, and it is a strange thing to write because it is simultaneously the most read and the least technical page in the whole document. The people who decide whether the findings get funded often read this and nothing else.

Write it for a smart, busy, non-technical leader. They are not going to read the word "payload". They want three things, in plain language and in business terms.

Two disciplines make an executive summary good. First, ruthless selection: leadership cannot act on 23 things, so tell them the three that matter and let the body hold the rest. A summary that lists everything has summarised nothing. Second, translation: every sentence should be about risk, money, customers or reputation, not about mechanics. If a term needs a security background to understand, it does not belong on this page.

This connects straight back to section 02. The executive summary is the top of the pyramid made real. It is you deliberately writing for the reader with the most authority and the least time, so that the fixes the engineers need actually get approved and scheduled.

07 Professional conduct around the report

The report is not just a document. It is a detailed, verified map of how to break into the client's systems, written by an expert, all in one file. That changes how you handle it, and it comes with duties that outlast the engagement.

Retesting. A finding is not truly closed until someone confirms the fix works. A professional engagement usually includes a retest: after the client reports a fix, you follow your own reproduction steps again and check the bug is gone. This is another reason those steps have to be exact. It is also common to find that a fix was incomplete, or introduced a new problem, and catching that is part of the value.

Secure handling. Because the report is a map to break in, it must be protected like one. Deliver it over an encrypted channel, not a plain email attachment. Store it encrypted. Share it only with the people who need it. Delete the client's data and your working copies when the engagement and any retest are done and the retention period agreed with the client has passed. A report leaking is its own breach, and it is one you caused.

Honest reporting. This is the principle you have carried through this entire phase: report faithfully. Write what you found, exactly as you found it. Do not exaggerate a Medium into a Critical to look impressive. Do not quietly drop a finding because it is awkward or because fixing it will annoy someone. Do not claim you tested something you ran out of time for. The client is making real decisions with real money on your word, and the whole profession runs on the assumption that your word is good.

The honesty rule has a side most people miss: what to do when you found very little. New testers panic at a clean result and feel pressure to inflate minor issues to justify the fee. Do not. A quiet result, honestly reported, is a legitimate and valuable outcome. State plainly what you tested, what you did not have time to reach, and what you found, even when the answer is "the important paths held up". An honest "we found little, and here is exactly what we checked" builds more trust than a padded report ever could, and padding is the fastest way to lose a client who knows their own systems.

08 Do it on your real machine

There is no new tool for this one. The exercise is the actual skill this lesson teaches: taking something you found and writing it up so someone else could fix it. You are going to write one real finding.

Go back to the OWASP Juice Shop you attacked in lesson 02.4. That is a deliberately vulnerable web app you run locally, which is exactly why it is legal and safe to practise on. Pick one bug you triggered there, the login bypass, an XSS, a broken access control, whatever you got working, and write it up using the finding template from section 03.

Keep it with your other work. In lesson 00.8 you created a notes folder for the course; that is where this goes.

cd ~/Cybersecurity/lab/notes
touch finding-01-juice-shop.md
open -e finding-01-juice-shop.md

Paste this template into the file and fill every field. The open -e command opens the file in TextEdit; nothing here changes any system setting.

# Finding 01: [short title, what and where]

Severity: [Critical / High / Medium / Low]  (CVSS: [score])
Affected asset: [exact URL / endpoint / parameter]

## Description
[What the flaw is, in 2-3 plain sentences.]

## Steps to reproduce
1. [From a fresh browser, first action]
2. [Next action, with the exact input used]
3. [What you observe that proves it worked]

## Impact
[What an attacker gains. Consequences, not mechanics.]

## Remediation
[The specific change. Name the technique. Set a priority.]

A filled example to model yours on

Here is the same template completed for the classic Juice Shop login bypass, so you can see the level of detail each field wants. Yours should read like this.

# Finding 01: SQL injection in login allows authentication bypass

Severity: Critical  (CVSS: 9.8)
Affected asset: POST /rest/user/login  (the "email" field)

## Description
The login endpoint builds its SQL query by joining strings with the
submitted email. Input is treated as query code, so an attacker can
change what the query does and log in without a valid password.

## Steps to reproduce
1. Open the Juice Shop login page in a fresh browser.
2. In the Email field enter:  ' OR 1=1;--
3. Enter any text in the Password field and submit.
4. You are logged in as the first user in the database (the admin),
   with no valid credentials.

## Impact
An unauthenticated attacker on the internet can log in as any user,
including the administrator, and read or change all account data.
No password, no prior access, and low skill required.

## Remediation
Replace the string-built query in the login handler with a
parameterised query using bound parameters, so input is never run
as SQL. Apply the same pattern to all other database queries.
Priority: immediate.

Your checklist

• Can explain why the report, not the exploit, is the thing the client pays for
• Can name the three audiences and what each one wants from the report
• Can list the fields of a finding from memory
• Understand what a CVSS score is and why business context can move the real risk above or below it
• Can tell a weak remediation from a strong one, and know why "be more secure" is worthless
• Wrote one real finding from Juice Shop using the template, with every field filled
• Followed my own reproduction steps from a fresh browser and confirmed they work
• Saved the finding in ~/Cybersecurity/lab/notes

09 Final check

✓ Key takeaways

The things from this lesson worth carrying into the next one. If you remember nothing else, remember these.