CVE Scanning Tools vs a Managed Vulnerability Service

This page explains what a CVE scanning tool actually produces, what has to happen between an advisory landing in the National Vulnerability Database and a patched production website, and how to decide whether a tool is enough or whether the work belongs with a team on an SLA. Written for IT managers, digital leads and agency owners responsible for websites they cannot afford to have compromised.

What a CVE scanner actually tells you, and what it leaves out

A CVE scanner answers one narrow question: based on the software versions I can observe, which published vulnerability identifiers might apply? That is a useful question. It is not the question your risk register is asking.

The output is a list of CVE identifiers, each with a CVSS base score, a description written by the assigning authority, and a CPE range describing the affected versions. What the scanner does not tell you is whether the vulnerable code path is reachable in your configuration, whether your distribution has already backported the fix, whether a patch exists at all, whether applying it breaks a theme or a custom module, who is going to test it, and when it has to be done by.

Those gaps are where incidents actually happen. A team with a scanner and no process ends up with an inbox of findings nobody owns, a quarterly report that shows the same twelve items every quarter, and a genuine remote code execution bug sitting on page four because the scoring did not distinguish it from eleven low-severity denial of service issues in a library the application never calls.

How scanners build their picture

Dependency manifests and SBOM

The most accurate scanning method reads your lockfiles. composer.lock for PHP, package-lock.json or yarn.lock for Node, Gemfile.lock, poetry.lock, go.sum. These files pin exact versions and transitive dependencies, so matching them against OSV, the GitHub Advisory Database or the NVD gives a high-confidence result. Tools in this category include Trivy, Grype, Dependabot, Renovate and OWASP Dependency-Check.

A software bill of materials in CycloneDX or SPDX format is the same idea generalised, produced at build time and stored as an artefact. If you are asked for an SBOM during a procurement or a security review, this is what is wanted. The limitation is obvious: lockfile scanning only sees what is in the repository. It does not see the plugin somebody installed through the CMS admin, the vendored library committed as raw files years ago, or the operating system packages underneath.

Version fingerprinting and CPE matching

Where a manifest is not available, scanners guess. They read the Server and X-Powered-By headers, the generator meta tag, readme files left in web roots, JavaScript asset paths that encode a version string, and known file hashes. They then map that guess to a CPE string such as cpe:2.3:a:wordpress:wordpress:6.4.1:*:*:*:*:*:*:* and look up matching CVE records.

Fingerprinting is how external scanners and attack surface rating platforms work, because they only have the outside of the building to look at. It is also why their results need the most triage. A hardened server that suppresses version banners looks the same as an unpatched one, and a server that reports a distribution-packaged version looks vulnerable even when it is not.

Comparison of scanning approaches

No single row covers a website end to end. A production site needs at least dependency scanning, host scanning and edge telemetry working together, which is already three tools, three alert streams and three sets of credentials to manage.

Why false positives and unreachable code paths dominate raw output

Three things inflate a scan report.

• CPE mismatch. CPE strings are coarse. A CVE affecting a specific module of a framework is frequently recorded against the whole framework, so every installation in the version range is flagged whether or not the module is installed.
• Unreachable code. A deserialisation bug in a PDF export library matters if your site exports PDFs. If the library ships as a transitive dependency and no code path ever calls it, the risk is theoretical. Reachability analysis is improving in some ecosystems but is not reliable across PHP applications with dynamic autoloading.
• Compensating controls. A CVE requiring an authenticated administrator session on a site where the admin path is IP-restricted and behind MFA is a different proposition to the same CVE on an open login form.

The correction for all three is context, and context is a person who knows the application. CVSS base score alone is a poor prioritisation signal; it describes the worst case for anyone, not your case. Pairing it with EPSS, which estimates the probability of exploitation in the wild, and with the CISA Known Exploited Vulnerabilities catalogue, which lists what is being used right now, produces a far shorter and far more honest list.

The work between an alert and a patched production site

This is the part that tool vendors do not show in the demo. For a single confirmed, reachable vulnerability on a live enterprise site, the sequence is roughly:

1. Confirm the component is genuinely installed and the version genuinely in range, not a fingerprint artefact.
2. Determine exploitability in your configuration: is the feature enabled, is the endpoint reachable, does it require authentication.
3. Find the fix. A patched release, a vendor backport, an upstream commit you can apply, or a configuration change if no patch exists yet.
4. Check for a dependency conflict. Bumping one package often forces a major version of another, which in a Silverstripe or Drupal application can cascade into module incompatibilities.
5. Deploy to staging from a production-matched database snapshot and run the build.
6. Regression test the paths that matter: forms, checkout, search, authentication, integrations, scheduled tasks.
7. Schedule the production release, take a restore point, deploy, verify, and keep the rollback path warm.
8. Close the finding with evidence, so the next audit or penetration test does not reopen the same argument.

Multiply that by the volume of advisories a typical CMS stack generates in a month. The scanning is minutes. The remediation is the job.

Backporting, and why the reported version is often wrong

Enterprise Linux distributions do not ship upstream releases. Debian, Ubuntu and Red Hat take the security fix from a newer version and apply it to the version they already support, keeping the version number stable so nothing else breaks. Ubuntu might ship 8.1.2-1ubuntu2.20 containing fixes that upstream only released in 8.1.27. The banner still says 8.1.2.

Any scanner comparing that string to an NVD version range will report a dozen vulnerabilities that were patched months ago. The reverse also happens: a package pinned by a third-party repository can sit on a version the distribution considers fixed while missing the actual patch. Resolving this means reading rpm -q --changelog or the Debian security tracker and checking whether the specific CVE identifier appears in the package changelog. There is no automated shortcut that is trustworthy across a mixed estate.

Cadence, routing and who is accountable for closure

The NVD publishes continuously, so a quarterly scan guarantees that for up to ninety days you are unaware of something an attacker already knows. A workable arrangement looks like this:

• Dependency scanning on every commit and every build, failing the pipeline on new high-severity findings.
• Host and OS scanning daily, with automatic application of security-only repository updates where the package manager supports it.
• Advisory feed monitoring for the specific platforms in use, so a core security release is seen on the day it ships rather than on the next scan.
• Remediation time targets keyed to severity and exploitation data, not to a calendar, and written into the support SLA so there is a contractual owner.

Alert routing matters as much as cadence. If findings land in a shared mailbox, nobody owns them. If they land in a ticket queue with a named assignee, a due date derived from severity, and a weekly review of anything ageing, they close. The technical difference between an organisation that gets breached through a known CVE and one that does not is usually this piece of process, not the quality of the scanner.

When a tool is enough, and when you need a managed service

The common failure is structural rather than technical. The hosting provider keeps the server up but will not touch the application. The web agency built the site but does not monitor advisories or hold infrastructure access. The scanner reports a vulnerability in a CMS plugin and both parties agree it is the other one's problem. The organisation in the middle carries the risk it thought it had outsourced. Combining security monitoring with the development capability to act on it removes that gap, because the party that detects the issue is the party contracted to fix it.

Frequently Asked Questions

What is a CVE scanning tool?

A CVE scanning tool compares the software components it can identify in your environment against published vulnerability databases such as the National Vulnerability Database, the GitHub Advisory Database or OSV, and reports which known CVE identifiers may apply. Tools do this by reading dependency lockfiles, querying installed operating system packages, or fingerprinting versions from HTTP responses. The output is a list of candidate vulnerabilities, not a verified assessment of your actual risk.

Why does my scanner report vulnerabilities that are already patched?

Enterprise Linux distributions backport security fixes into older package versions without changing the version number, so a scanner matching version strings against NVD ranges will flag packages that are already fixed. Confirming this requires checking the distribution's security tracker or the package changelog for the specific CVE identifier. This is one of the most common sources of false positives in host and external scan reports.

How often should a website be scanned for vulnerabilities?

Dependency scanning should run on every build, host and operating system scanning should run at least daily, and advisory feeds for your specific CMS and frameworks should be monitored continuously. Quarterly or annual scanning leaves a window of weeks or months in which a publicly exploited vulnerability goes unnoticed. The appropriate cadence is driven by how quickly you can remediate, not by audit scheduling.

Is CVSS score a good way to prioritise patching?

CVSS base score describes the worst case for any affected deployment and ignores your configuration, so on its own it over-prioritises theoretical issues and under-prioritises exploited ones. Combining CVSS with EPSS exploitation probability, the CISA Known Exploited Vulnerabilities catalogue and whether the vulnerable code path is reachable in your application produces a much shorter and more accurate priority list. That combination requires human judgement about the specific application.

What is the difference between vulnerability scanning and a penetration test?

Vulnerability scanning is automated, continuous and matches known identifiers against observed versions and configuration. A penetration test is a time-boxed human engagement that chains weaknesses together, tests business logic and attempts actual exploitation. Scanning keeps the known-vulnerability backlog under control between tests, and a clean scan history makes a penetration test far more productive because testers are not spending their time on findings you could have closed yourself.

Does a WAF remove the need to patch?

No. A web application firewall can block known exploit signatures and buy time while a patch is tested, which is genuinely valuable for a zero day or an urgent release. It does not remove the vulnerable code, it can be bypassed by novel payloads, and auditors will still record the component as unpatched. Treat edge protection as a control that shortens exposure, not as a substitute for remediation.

Managed CVE scanning and vulnerability monitoring

UnDigital runs server vulnerability scanning and CVE monitoring as a managed service for enterprise and government websites on WordPress, Silverstripe, Drupal, Magento and custom applications. That covers dependency and host scanning, advisory feed monitoring, triage against your actual configuration, patch testing in staging, production deployment with a rollback path, and documented closure. The process from NVD advisory to deployed patch is owned by one team, under one SLA, on infrastructure we also manage. Agencies without in-house infrastructure capability can deliver the same thing to their own clients through the Agency Hosting Program, white-labelled, with UnDigital handling fulfilment.

Every engagement starts with an infrastructure and vulnerability audit of what you are running today, so the first conversation is about your actual findings rather than a generic scope.