There are usually five different types of findings a pentest team will find during an assessment: informational, low, medium, high, and critical. These could range from SQL injections and broken access control, to XSS and IDOR, but the point is that every finding is assessed according to its potential impact and likelihood of exploitation.
There should never be a wholly clean pentest report – on the contrary, a team might find dozens of ‘informational’ to ‘high’ findings, but ‘critical’ findings are often rare in a well-scoped professional test. They occur when a vulnerability presents an immediate and severe risk to the client, and is considered highly likely to be exploited or capable of causing significant impact if left unresolved.
The reason that they’re relatively rare is because most environments don’t expose vulnerabilities that meet such a high threshold risk, but not just that: the findings that are considered ‘critical’ often age poorly over time, to the point where they almost become overclassified.
Static Criticals
So why is this the case? When it comes to being overclassified, we should note that we use that term carefully, because there’s always a good reason why a finding is deemed ‘critical’ in the moment. The problem, in this case, comes in the process of classification itself.
Let’s say a pentest team is assessing a client’s external infrastructure and identifies five ‘critical’ findings. Perhaps one is an internet-facing SQL injection vulnerability, another is an exposed administrative interface, a third is an authentication bypass, while the remaining two involve excessive privileges and outdated software that can be exploited remotely. At the time of testing, each genuinely represents a ‘critical’ risk and is prioritised accordingly, but over the following weeks, the client begins remediating those issues.
The SQL injection is completely fixed, and access to the administrative interface is restricted behind a VPN. Not only this, the authentication bypass is mitigated by introducing 2FA, which reduces its overall impact and ensures an attacker can’t exploit it as easily. The only thing that hasn’t been patched is the outdated software.
This doesn’t seem too problematic, right? Except every one of those findings still appears in internal records as ‘critical’, since the pentest team has no reliable way of updating and tracking the changing severity of individual findings over time. As a result, the remediation team ends up treating all five as equally urgent, even though only one still represents an immediate threat – meaning time is spent revisiting issues that have already been substantially mitigated, while the vulnerability that has become the greatest risk struggles to stand out.
Some of the findings might still be issues – as we just mentioned, the authentication bypass is mitigated, but not necessarily resolved – but that doesn’t change the fact its classification should be lower. The problem here isn’t necessarily that the pentest team have certified these issues as ‘critical’ in the first place, but that without a centralized pentest reporting solution, those classifications can easily remain static while the client’s environment continues to evolve.
Moving Landscapes
It’s also important to look at the cybersecurity landscape as a whole. This is a constantly moving thing, with new vulnerabilities being discovered every day, and because of this, the level of risk associated with a vulnerability is moving too.
A finding that genuinely warranted a ‘critical’ classification during the initial assessment might have been critical then, but fast-forward a few weeks and it’s become far less severe – perhaps because a security patch has been released or new mitigating controls have been introduced.
On the reverse side, another vulnerability that initially appeared less significant could become far more dangerous, say, for instance, following the release of a public exploit or the discovery of a new attack chain. With this in mind, severity ratings are more of a snapshot of risk at a specific moment, not a permanent reflection of the cybersecurity scene. As the client’s environment evolves and the wider threat landscape changes, those ratings need to evolve alongside them, otherwise teams are going to be prioritizing yesterday’s highest risks instead of focusing on what’s needed now.
Again, a structured reporting process is the answer to this, not necessarily that the use of the ‘critical’ classification needs to be avoided entirely. By bringing findings, remediation updates, retest results, and severity changes into one place, pentest teams are essentially giving themselves the visibility to reassess risk when circumstances change, ensuring the reporting remains accurate and the prioritization of vulnerabilities is always based on the latest available information.
Even if nothing changes and every finding rightfully retains its original severity, in order to maintain consistency and – perhaps even more important in this context – confidence in the process, centralized report management is the only thing that will keep findings aligned and allow teams to make the most informed remediation decisions.
In other words, while ‘critical’ findings might age poorly over time, that’s only if they’re ageing outside of the view of the team itself.
