Know exactly which CVEs are open on your servers right now.
Every server we host or manage has its installed software inventoried and matched, continuously, against the National Vulnerability Database and Ubuntu Security Notices. When a CVE lands that affects something you are actually running, it appears in your portal with a severity, a version, and an answer to the only question that matters: has it been patched yet.
Most vulnerability reports are mostly wrong.
Ubuntu does not upgrade to a new upstream version to fix a security bug. It backports the fix into the version you already have. The upstream version number never moves — so a scanner reading the CVE feed alone reports vulnerabilities that were patched weeks ago.
Matching against NVD alone
Fourteen critical findings
The version number on the server matches a long list of published CVEs, so every one of them is reported against you.
Thirteen already fixed
Canonical backported those patches without changing the version string. Nothing in the report knows that.
A day of engineering to disprove
Somebody has to check each finding by hand before anyone can act, so in practice nobody acts at all.
Cross-checked against NVD and USN
One real finding
The thirteen already patched by the distribution are resolved automatically. What is left is genuinely open.
Nothing outside the package manager is missed
Reading the distribution feed alone would hide your CMS, its components and the libraries your application pulled in at build time. Both feeds are read, so neither blind spot applies.
A report you can act on the same day
A short list of things that are actually broken, with the fixed version beside each one. That is the difference between a vulnerability report and a list of things to argue about.
No agent, no scan window, no load on your site.
Your software is inventoried
01Operating system packages, language runtimes, libraries and CMS components on every server we host or manage. Collected as part of normal server management, so there is nothing for your team to deploy or keep alive.
It is matched against both feeds
02Continuously, as new advisories are published, rather than on a monthly or quarterly cycle. A CVE disclosed on a Saturday does not wait for the next scheduled scan to become visible.
You see it in your portal
03Per server, with severity, installed version, fixed version and whether the patch has landed. Exportable, for the times somebody asks you to prove any of it.
Everything installed, not just what answers a port scan.
A vulnerable image-processing library that is never exposed on a port will not show up in an external scan. It is still the thing that gets exploited when someone uploads a file through your CMS. This finds it — alongside, not instead of, the perimeter controls and penetration testing that catch what no database knows about.
Operating system
Distribution packages and the system libraries underneath them, cross-checked against the vendor's own security notices.
Runtimes & libraries
The language runtimes your application depends on, and the dependencies pulled in at build time that no perimeter scan can see.
CMS & components
The platform and the modules bolted onto it, which is where most real-world website compromise actually begins.
A policy says you patch. A record shows when you did.
Most organisations do not commission vulnerability scanning because they want it. They commission it because a framework, an insurer or a procurement panel asked for evidence, and nobody could produce any.
Patch applications and patch operating systems are two of the eight. Both are assessed on how quickly you patch, which is impossible to demonstrate without a continuous record of what was vulnerable and when the fix landed.
Technical vulnerability management asks you to show identification, assessment and remediation as an ongoing process. A quarterly PDF from a vendor who scanned once does not satisfy it.
An answer to "do you scan for vulnerabilities, and how often" that is not aspirational — produced by a third party rather than a self-assessment.
It also makes penetration testing cheaper. Clearing known CVEs before a test means the budget is spent on business logic flaws and broken access control, rather than on rediscovering unpatched packages you could have fixed yourself.
Included with every managed hosting plan and every website support SLA. Not an add-on, not a line item at renewal.
The questions security and digital teams actually ask.
How often does the scan run?
Continuously. The software inventory is re-checked against both feeds as new advisories are published, rather than on a monthly or quarterly cycle. A CVE disclosed on a Saturday does not wait until the next scheduled scan to become visible.
Does it slow the website down or affect uptime?
No. It reads a software inventory rather than probing the running site, so it generates no request load and needs no maintenance window. That is one of the practical advantages of inventory matching over external scanning.
Do I need to install an agent?
No. On infrastructure we host or manage, the inventory is collected as part of normal server management. There is nothing for your team to deploy or keep running.
What is the difference between NVD and USN?
NVD is the global record of disclosed vulnerabilities, indexed against upstream software versions. USN is Ubuntu's record of what has been fixed in its own packages. Because Ubuntu backports security fixes without changing the upstream version number, checking NVD alone reports vulnerabilities that were patched weeks earlier. Reading both is what makes the report actionable.
Does this replace penetration testing?
No, and treating it as a replacement is a mistake. Continuous CVE monitoring catches known vulnerabilities in known software, which is the majority of real-world compromise. A penetration test finds the things no database knows about. Running the monitoring first means the test is not spending its budget rediscovering unpatched packages.
Does it cover the CMS and its plugins, or only the operating system?
Both, where the software is visible in the inventory. Operating system packages, language runtimes and libraries are covered, alongside CMS components and their modules. Anything installed by hand outside the package manager and never documented is the known limitation, and finding those is part of an infrastructure audit.
Is it available without hosting with UnDigital?
It is included with hosting and with SLA plans rather than sold separately. If your infrastructure sits elsewhere, a management-only arrangement is the usual route — talk to us about what you are running.
What happens when it finds something critical?
On managed plans, severity and exposure determine the response, and a genuinely critical internet-facing vulnerability is treated as an incident rather than a ticket. Where a fix cannot be applied immediately, mitigation at the firewall or configuration layer buys the time to patch properly. Unplanned work outside that scope is handled as break/fix and emergency support.
What is open on your production servers right now?
If the honest answer is a shrug, a spreadsheet, or a quarterly PDF from a vendor who scanned once, that is the gap this closes.