Why Your Vulnerability Scanner Is Missing the Vulnerabilities That Matter

Vulnerability scanners have been around for 25 years. They have gotten better at finding known CVEs in known software. They have not gotten better at finding the vulnerabilities that actually lead to breaches, which are misconfigurations, exposed credentials, over privileged identities, exposed secrets, third party supply chain risk, and the long tail of custom code that does not have a CVE because it has not been studied. The scanner is a compliance tool that produces a 200 page report that nobody reads. The actual security work is somewhere else.

The vulnerability scanner is, in most enterprises, run on a schedule, against a list of assets, producing a list of findings. The list is long. The list is, in many cases, over 1,000 findings for a mid sized enterprise, over 10,000 for a large one. The findings are triaged by severity. Critical findings are remediated, usually. High findings are triaged, sometimes remediated. Medium and low findings are filed in a system nobody checks. The scanner is run again next month. The new report has 1,000 findings. Some of the findings are the same. Some are new. The cycle continues.

The cycle is not security. The cycle is compliance. The cycle produces a report that satisfies the auditor, satisfies the regulator, satisfies the vendor risk questionnaire. The cycle does not, in most cases, prevent breaches. The breaches happen in the gaps the scanner does not look at. The breaches happen in the misconfigurations, the over privileged identities, the exposed secrets, the supply chain. The scanner is, in 2026, looking in the wrong place.

What scanners are good at

Scanners are good at finding known CVEs in known software. The scanner maintains a database of CVEs, checks the assets against the database, reports the matches. The database is large, in the hundreds of thousands of entries. The matching is fast, the coverage is wide, the result is comprehensive. A scanner will find every instance of every known vulnerability in the assets it was pointed at, in a few hours.

This is useful. The known CVEs are real. The scanner finds them. The remediation is straightforward, in most cases, because the CVE has a known fix, a known patch, a known workaround. The scanner is a useful tool for the known vulnerability problem, which is real but, in most enterprises, not the dominant risk.

Scanners are also good at providing a paper trail. The scanner report is a documented inventory of the vulnerabilities the enterprise knows about. The report is auditable, it is reproducible, it is a record. For compliance purposes, the report counts as the evidence that the enterprise is doing the work. For the auditor, the regulator, the customer, the report counts as the proof.

What scanners are bad at

Scanners are bad at finding misconfigurations. The S3 bucket that is public. The IAM role that is over privileged. The security group that allows SSH from the world. The storage account that has no access logging. The Kubernetes cluster that runs as root. These are the configurations that lead to breaches, and the scanner, in most cases, does not check for them, or checks for them in a per asset way that misses the architectural patterns.

Scanners are bad at finding exposed credentials. The API key in the GitHub repository. The access token in the .env file in the developer laptop. The long lived IAM credential that has not been rotated. The service account password in the configuration management system. These are credentials that grant the attacker the access they need to breach the environment, and the scanner, in most cases, does not look for them at all.

Scanners are bad at finding over privileged identities. The IAM role that was created for a project 3 years ago, with permissions the project no longer needs, granted to a service account that no one remembers. The user account with administrative privileges that was set up for an emergency and never revoked. The third party integration with read access to all customer data, granted for a one time migration and never removed. The scanner does not, in most cases, have a way to detect these.

Scanners are bad at finding the long tail of custom code vulnerabilities. The business logic flaw in the payment flow. The access control bug in the customer portal. The race condition in the inventory update. The SQL injection in the custom built reporting tool. These are the vulnerabilities that lead to breaches, and the scanner, in most cases, cannot find them, because the vulnerabilities are specific to the code, the code is not in any CVE database, and the scanner does not have a model of the code’s intended behaviour.

The compliance report nobody reads

The 200 page scanner report is, in most enterprises, a compliance artefact. The report is generated. The report is filed. The report is shown to the auditor, who checks that the report exists and is recent. The report is not, in most cases, read by anyone. The findings are, in many cases, not actioned. The critical findings are, in many cases, exceptions. The exceptions are, in many cases, renewed. The cycle continues.

The cycle is rational from the perspective of the people in it. The auditor wants to see that the scanner is being run. The compliance team wants to see that the report is being generated. The security team wants to see that the critical findings are being addressed. The exception amounts to the escape valve. The exception allows the critical finding to remain open, with a justification, often “compensating controls”, often for a year or more. The audit is satisfied. The finding is open. The vulnerability is exploitable.

The cycle is also rational from the perspective of the engineering team. The engineering team has its own priorities, its own roadmap, its own backlog. The scanner findings are additional work, with no clear deadline, often with no clear owner. The findings are deprioritised in favour of the work the engineering team was already doing. The findings accumulate. The cycle continues.

Where the real attack surface is

The breaches of the last 5 years have a common shape. The attacker gains initial access through one of the misconfigurations, exposed credentials, or supply chain risks the scanner does not check. The attacker uses the access to find the over privileged identities, again not checked by the scanner. The attacker uses the over privileged identities to move laterally, to access sensitive data, to deploy the attack. The scanner, in most of these breaches, was not the system that detected the attack. The scanner was not, in many cases, even running against the asset that was breached.

The Capital One breach, in 2019, was a misconfigured web application firewall. The scanner that Capital One was running did not check WAF configurations. The 2022 Uber breach was a social engineering attack against an employee, leading to over privileged access. The scanner did not check employee social engineering risk. The 2023 MGM breach was the Scattered Spider group, using similar social engineering. The scanner did not check social engineering risk. The 2024 Snowflake breaches were stolen credentials, purchased from the stealer malware market. The scanner did not check credential theft.

The pattern is consistent. The scanner is good at the problem the scanner was designed for, which is CVE detection. The scanner is not good at the problem that is actually leading to breaches. The problem that is actually leading to breaches is not the CVE. The problem runs as the configuration, the credential, the identity, the supply chain.

The misconfiguration problem

Misconfigurations are the most common cause of cloud breaches. The misconfiguration is rarely a CVE. The misconfiguration is a default that was not changed, a setting that was not reviewed, a service that was set up with the easiest configuration rather than the most secure. The misconfiguration is, in many cases, a one line mistake in a Terraform file, applied to production, never reviewed.

The fix for misconfigurations is not a scanner. The fix is a configuration review process, with the security team involved before the configuration is applied, not after. The fix is a baseline of secure configurations, applied to every new service, with deviations requiring explicit approval. The fix is continuous monitoring of the configuration, with alerts on changes that weaken security.

The identity problem

Identity becomes the second most common cause of cloud breaches. The identity problem is rarely a CVE. The identity problem is an over privileged role, a long lived credential, a service account that no one remembers, a third party integration that has not been reviewed. The identity problem is, in most cases, a process problem, not a technology problem.

The fix for identity is not a scanner. The fix is an access review process, run quarterly, with every grant reviewed and justified. The fix is short lived credentials, rotated automatically, with no long lived secrets. The fix becomes the principle of least privilege, applied as a default, with the security team enforcing the default in the identity provider configuration.

The secrets problem

Secrets are the third most common cause of breaches. The secret problem is rarely a CVE. The secret is an API key in a GitHub repository, an access token in a developer’s .env file, a database password in a configuration file, a service account key in a CI/CD pipeline. The secret is, in most cases, a process problem, not a technology problem.

The fix for secrets is not a scanner. The fix is a secrets management system, with secrets stored in a vault, never in code. The fix is secrets scanning in the CI/CD pipeline, with the build failing when a secret is detected. The fix is rotation, automated, with the secret manager handling the rotation and the applications handling the change.

The custom code problem

Custom code vulnerabilities are the most serious category, because the custom code runs as the part of the system the attacker is most likely to find a flaw in. The custom code vulnerability is rarely a CVE. The custom code vulnerability is a business logic flaw, an access control bug, a race condition, an injection attack. The custom code vulnerability requires a human reviewer who understands the code, the design, the threat model.

The fix for custom code is not a scanner. The fix is code review, with a security focus, on every change to the custom code. The fix is threat modelling, run at design time, to identify the attack surface before the code is written. The fix is penetration testing, run periodically, to find the flaws the code review missed. The fix is a bug bounty, run continuously, to find the flaws the penetration testing missed.

What the actual security work looks like

The actual security work, in 2026, is configuration review, identity review, secrets management, code review, threat modelling, penetration testing, and bug bounty. The actual security work is not running a scanner once a month and filing the report. The actual security work serves as the work the scanner does not do, done by humans who understand the system and the threat.

The scanner is still useful, for the CVE detection problem. The scanner should still be run. The report should still be produced. The critical findings should still be remediated. The scanner is, however, the smallest part of the security program, not the largest. The largest part of the security program amounts to the work the scanner does not do.

The companies that have figured this out are spending less on the scanner and more on the humans who do the work the scanner does not do. The companies that have not figured this out are still running the scanner, still filing the report, still missing the breaches the scanner does not see. The pattern is consistent. The fix stands as the same. The work is yours.

The bottom line

The vulnerability scanner is a compliance tool, not a security tool. The scanner is good at CVE detection. The scanner is bad at misconfigurations, exposed credentials, over privileged identities, exposed secrets, and custom code vulnerabilities. The scanner misses the breaches. The scanner produces the report. The report satisfies the audit. The breaches happen anyway.

The fix is to spend less on the scanner, more on the work the scanner does not do. The fix is configuration review, identity review, secrets management, code review, threat modelling, penetration testing, and bug bounty. The fix is humans who understand the system. The fix is not a 200 page report nobody reads.