Reading a VAPT report

A penetration test report arrives with findings sorted by severity, and the natural response is to work down the list. That is rarely the right order, because the severity rating in the report is a generic score that knows nothing about your environment.

A critical finding on a system with no sensitive data and no network reach may matter less than a medium finding on the server that holds your customer database. Re-ranking the report against your own context is the first job, and it takes an afternoon.

Why the severity column is not the priority order

Most reports use a scoring system that combines how easily something can be exploited with how bad the result would be, assessed generically. It deliberately excludes context, because the tester often does not have it.

What it does not know:

• Whether the affected system is reachable from where an attacker would realistically start.
• Whether the data on it matters.
• Whether a compensating control already limits the impact.
• Whether the system is being decommissioned next month.

You know all four. Adding them changes the order significantly.

A practical re-ranking

Take each finding and ask three questions.

Where does an attacker have to be to use this? Internet-facing with no authentication is the top of the list. Requiring an authenticated user account is lower. Requiring existing administrative access on the same host is lower still, because an attacker who has that already has what the vulnerability would give them.

What does it actually get them? Access to data that matters, or the ability to move to a system that holds data that matters. A finding that yields a limited foothold on an isolated host is real but not urgent.

Is anything already limiting it? Network segmentation, a web application firewall, monitoring that would catch the exploitation attempt. Compensating controls do not make a finding disappear, but they change how much time you have.

Sort by the combination. You will usually find that a handful of findings deserve immediate attention, a larger group deserves scheduled work, and a long tail can be batched or accepted.

The four buckets

This week. Anything remotely exploitable without authentication that leads to data or to a foothold. Anything involving exposed credentials, because those are already out.

This month. Findings that require some access but lead to significant escalation. Authorisation flaws in applications where one user can reach another's data. Missing patches on internal systems that matter.

This quarter. Configuration hardening, weak but not broken cryptography, information disclosure that helps an attacker without directly enabling anything, defence-in-depth improvements.

Accept and record. Findings where the fix costs more than the risk warrants, or where the affected system is being retired. These need a written decision with a named owner and a review date. An accepted risk is a legitimate position. An ignored finding is not, and the difference is entirely in whether it was written down.

Fix the cause, not the instance

Reports list instances. Twenty findings of the same misconfiguration on twenty servers are one problem, and fixing them individually guarantees a twenty-first.

Look for the pattern behind clusters of findings:

• The same missing header across every application usually means a shared framework or gateway configuration.
• Missing patches across many hosts usually means a gap in patch management coverage, not twenty separate oversights.
• The same authorisation flaw in several application functions usually means a shared component that checks authentication but not authorisation.

Fixing the cause takes longer and is the only version that holds.

Things that are commonly over- and under-weighted

Over-weighted: informational findings about software version disclosure, missing security headers on pages that hold nothing, weak ciphers that no modern client would negotiate anyway. These are worth fixing, cheaply, in a batch. They are not worth a change window.

Under-weighted: anything involving credentials found during testing. Default passwords still in place, credentials in configuration files or source control, service accounts with excessive rights. These are frequently rated medium and are frequently the fastest route to a serious compromise.

Also under-weighted: findings in the report's appendix about what the tester could see but did not exploit because it was out of scope. Read the scope limitations section carefully; it often contains the most interesting sentence in the document.

The retest

Fixing a finding and confirming it is fixed are different things. Where possible, have the tester retest rather than relying on your own verification, particularly for anything you will need to evidence to a customer, auditor or insurer.

If a retest is not in the contract, at minimum record how each fix was verified and by whom. "Marked as resolved by the system owner" is weaker evidence than you will want later.

What to do with the report afterwards

Three things, none of which take long:

Extract the actions into your normal work tracking. A report is not a plan. Findings that stay in a PDF do not get fixed, because nothing in your process is looking at a PDF.

Record the accepted risks properly, with owner and review date, in whatever register you use for that.

Note what the test did not cover. The scope exclusions are a map of what you still do not know. That is useful input into next year's scope, and it stops the report being read as a clean bill of health for things it never examined.