Why External Vulnerability Scans Miss the Most Important Issues

External vulnerability scans are the standard protocol in most UK SME security programmes. They are easy to run, they are automated, and they are often required by cyber insurers as a condition of cover. When used on their own, they are catastrophically incomplete. A typical external scan catches around a third of the exposures on a modern website; this article explains what a scan checks, what it can’t check, and why the difference matters for regulated firms and any business handling personal or payment data.

What does a vulnerability scanner check for?

An external vulnerability scanner (Nessus, Qualys, Rapid7, OpenVAS and their cloud-based equivalents) works by reading a site from the outside. It sends specific requests, watches the responses, and compares them against a database of known vulnerability signatures. The categories a scanner does well at tend to include:

• Identifying outdated software with publicly known CVEs (Common Vulnerabilities and Exposures), including the WordPress core version, common plugin versions and exposed server software.
• Detecting basic misconfigurations, like missing security headers, weak TLS and open ports that should be closed.
• Finding default credentials on standard services, such as unchanged admin passwords on well-known admin panels.
• Enumerating exposed endpoints, including xmlrpc.php, admin areas and database consoles.

For general internet hygiene, all of this is genuinely quite useful; a monthly external scan will typically catch and let you safeguard areas that mass-scanning attackers use to identify soft targets.

What does a vulnerability scanner miss?

An external scanner is limited by three things: it can only see what is externally visible, it can only test what it has access to, and it cannot follow business logic. That means the following categories of exposure are largely invisible to a scan:

• Custom code with bespoke vulnerabilities. If a developer wrote an insecure endpoint six months ago, no scanner has a signature for it.
• Business logic flaws, such as the ability to change another user’s account details by editing a form parameter. A scanner cannot know what the business rules are supposed to be, so it cannot know when they are being broken.
• Authenticated exposures. Most scanners run unauthenticated by default, so anything that requires a login to see is effectively invisible to them.
• Chained vulnerabilities, where two small issues combine into one large exposure that either one on its own would look harmless.
• Configuration inside applications. A scanner cannot tell whether a WordPress site has a user role misconfigured to give editors unintended access.
• Data leakage through legitimate features, such as an API endpoint that returns more data than the front-end displays.

These are precisely the categories of exposure that mature attackers target, because they know that automated scans have already missed them. You can learn more about this in our article ‘the most common WordPress vulnerabilities in UK SME audits‘. This covers the specific findings we see most often in the more general SME segment.

Real examples of code-level issues scanners miss

Three anonymised examples from our own recent audit work illustrate the pattern. In the first case, a UK ecommerce site had a monthly Nessus scan returning clean for six months, but a code-level review found an unauthenticated API endpoint that returned complete customer records if the request included the right parameter. The scanner had no signature for the endpoint because it was custom-built, and the exposed personal data of roughly 4,000 UK customers was invisible to the automated scan for as long as nobody looked at the code directly.

In the second case, a UK financial services firm passed its annual external scan without findings, but a subsequent code review of the client portal turned up a missing role-check on one administrative function, which allowed any logged-in user to invoke it and elevate their permissions. The exposure was invisible to the scan simply because it required authentication to reach.

In the third case, a UK regulated broker’s scan reported “no critical issues”, but a code-level compliance audit found four separate exposures in the underlying application code, one of which allowed extraction of sensitive client documents through a chained vulnerability. Each individual issue was low severity on its own, but combined they were critical. The full detail is written up in the application and compliance audit case study.

 

When you need a code-level audit

You need something beyond external scanning if any of the following apply: you handle personal, financial or health data at any scale; you are FCA-regulated, ICO-registered with sensitive data, or subject to sector-specific compliance under the SRA, ICAEW or a medical body; your site includes custom-built application code, especially anything with authenticated user sessions; you have client contracts specifying security testing beyond automated scanning; or you have had a compromise before and want to be confident you have found all the paths in rather than only the obvious one.

For sites that are brochure WordPress with no user accounts or payments, external scanning combined with a good baseline hardening exercise (see our WordPress security checklist) will get you most of the value that a full audit would provide. For anything more complex, the honest answer is that scanning is a useful starting point rather than a conclusion. Our related guide to IT compliance for UK regulated firms explores the wider picture for firms whose regulator expects more than a scan.

What to ask a security partner

If you are evaluating security partners, the questions that separate honest ones from ones selling scans dressed up as audits are:

1. What exactly is included in your standard audit, and does it include manual code review?
2. Do you run authenticated as well as unauthenticated tests?
3. Will you deliver a plain-English report or a raw scan output?
4. Do you help remediate the findings, or hand over the list and leave the fix to us?
5. Are your auditors formally qualified (OSCP, CREST, or equivalent)?
6. Can you produce evidence that satisfies my regulator, such as an FCA reviewer, an ICO investigator or a Cyber Essentials Plus assessor?

Vague answers on more than one of the above tend to signal a partner who is selling automated scans rather than doing a genuine assessment.