CVE Monitoring for Websites: From NVD Advisory to Patch

This page explains the full chain of work between a CVE being published on the National Vulnerability Database and a tested patch running in production, and it is written for IT managers, digital leads and security teams who need that chain to actually close on a website they are responsible for.

A scan report is not vulnerability management

Most organisations already have vulnerability data. It arrives as a weekly PDF from a scanning tool, a Nessus or Qualys export from the infrastructure team, an UpGuard score that dropped, or a dashboard with 340 findings and a red number at the top. The data is not the problem. The problem is that nobody owns the next step.

A scanner tells you that a version string it fingerprinted matches a CVE record. It does not tell you whether the vulnerable code path is reachable in your configuration, whether the affected module is even enabled, whether a patched release exists for your major version, whether applying it breaks a template override, or who is going to deploy it on a Thursday night and be awake if the checkout stops working. Those are development and release-engineering decisions, not scanning decisions.

This is where the usual split between a hosting provider and a website provider becomes expensive. The host will patch the operating system and refuse to touch the application. The agency that built the site will touch the application, but only when there is a project and a purchase order. A CVE in a CMS module sits precisely in the gap between them, and it sits there for months.

Where CVE data actually comes from

The CVE Program and the NVD

A CVE identifier is issued by a CVE Numbering Authority, which may be the vendor itself, a coordinating body or MITRE. The identifier and a description are published to the CVE List. The NVD, run by NIST, then enriches many of those records with CVSS scoring, CWE classification and CPE product ranges, which is what most scanners match against.

Two practical consequences follow. First, a CVE can exist with no NVD enrichment yet, so a scanner that relies on CPE matching will not see it. Second, CPE ranges for CMS plugins and PHP packages are frequently imprecise or absent, which produces both false negatives and noisy false positives. Relying on the NVD alone gives you a late and partial picture of a website's real exposure.

Vendor and platform advisories

The authoritative and earliest signal for website stacks is almost always the platform's own security channel. Drupal publishes SA-CORE and SA-CONTRIB advisories with its own risk calculator on scheduled Wednesday windows. Silverstripe issues security releases with CVE references and upgrade guidance per supported minor. WordPress core ships automatic security point releases, while the plugin and theme ecosystem is tracked through advisory databases rather than through core. Magento and Adobe Commerce issue APSB bulletins. Debian and Ubuntu publish DSA and USN notices that often backport fixes without changing the upstream version number a scanner is looking at.

You cannot monitor what you have not inventoried

Accurate CVE monitoring starts with a software bill of materials for each site, refreshed automatically rather than written once in a spreadsheet. For a typical enterprise website that means resolving four layers.

• Application dependencies: composer.lock and package-lock.json or yarn.lock, giving exact resolved versions rather than the ranges declared in the manifest.
• CMS extensions: installed plugins, modules and themes with their versions, including anything installed outside the package manager or customised in place.
• Runtime and services: PHP and Node versions and their extensions, nginx or Apache, MySQL, MariaDB or PostgreSQL, Redis, Elasticsearch, and the OpenSSL and libxml builds underneath them.
• Operating system packages: the full dpkg or rpm manifest, plus any software compiled from source that no package manager knows about.

On top of that you need to record what is internet-facing, what is behind a VPN or IP allowlist, which environments exist, and which code is forked. A fork is the single most common reason a patch cannot simply be applied, and the only cure is knowing about it before the advisory lands.

Deciding what is genuinely urgent

A list sorted by CVSS score is a poor work queue. CVSS describes intrinsic technical severity under worst-case assumptions. It does not describe likelihood, and it knows nothing about your deployment. Three signals used together produce a defensible order of work.

The ACSC Essential Eight gives a useful external benchmark for the timeframes that follow triage: for internet-facing services, patch or mitigate within 48 hours where a working exploit exists, and within two weeks otherwise. If your current arrangement cannot demonstrate that for a CMS plugin, the gap is a process gap, not a tooling gap.

Triage in practice

Triage on a real website looks like a short sequence of questions, answered by someone who can read both the advisory and the codebase.

1. Is the affected component present and at an affected version? Lockfile and package manifest confirmation, not fingerprinting.
2. Is the vulnerable code reachable? A module installed but disabled, a REST route removed, or an unregistered form endpoint changes the answer.
3. What privileges does exploitation require? Unauthenticated remote code execution and an authenticated stored XSS available only to editors belong in different queues.
4. What is exposed? An administration path restricted by Cloudflare Access or an allowlist, with multi-factor authentication enforced, materially reduces urgency.
5. Do compensating controls already block the known exploit pattern? A WAF rule, a strict Content Security Policy, or upload restrictions can hold a line while a proper fix is scheduled.
6. What does the fix cost? A patch release, a minor upgrade, a major upgrade with breaking changes, or a code change to a forked module.

Every one of those answers should be written down. The decision not to patch immediately is legitimate, but only if it is recorded with a reason, a compensating control and a review date.

From patch decision to production

Getting the fix live is where most vulnerability programs quietly fail. The work is ordinary release engineering, done under time pressure.

• Branch and build: bump the dependency, resolve transitive conflicts, and let CI run unit, integration and static analysis checks.
• Staging verification: deploy to an environment with production-like data, run database migrations, and check the specific functionality the patched component touches. Security releases that change escaping, session handling or file uploads break templates and integrations more often than any other kind.
• Regression checks: smoke tests on forms, authentication, payment and search, plus visual comparison on key templates.
• Scheduled window versus out-of-band: routine patches batch into a fortnightly or monthly window. KEV-listed and actively exploited issues go out immediately, with the rollback path confirmed and a restore point taken first.
• Verify and close: re-scan, confirm the version in production, and record the change. A ticket closed without post-deployment verification is not closed.

This pipeline is the reason CVE monitoring only works when it sits alongside deployment capability and a defined response commitment. That is exactly what a website support SLA exists to guarantee, and why patching under an SLA behaves differently to patching on a best-efforts basis.

When there is no patch

Sometimes the upstream fix does not exist, or exists only in a major version you cannot yet reach. Common cases are abandoned plugins, an end-of-life PHP branch, a CMS major version out of security support, or a fork that has diverged too far to merge.

• Remove the component. The cheapest fix is frequently deleting a module nobody has used for three years.
• Backport the fix. Apply the upstream patch to your pinned version and carry it as a documented local patch.
• Virtually patch at the edge. A targeted WAF rule blocking the exploit signature buys time. Cloudflare managed and custom rules are effective for this, provided the rule is reviewed rather than left in place forever.
• Constrain exposure. Restrict the affected path, disable the feature, or move administration behind an identity-aware proxy.
• Schedule the real remediation. Virtual patching is a bridge to a platform upgrade, not a destination. If the underlying answer is a major version upgrade, plan it while the bridge holds.

Evidence and reporting

Auditors, cyber insurers, procurement teams and your own board are not asking whether you scan. They are asking whether findings are triaged, remediated within a stated timeframe and evidenced. Useful reporting includes a current asset and component inventory, a register of open findings with severity, decision and owner, time-to-remediate figures against policy, a change log tying each patch to a deployment and verification, and documented accepted risks with expiry dates.

The same artefacts do double duty. They shorten a penetration test remediation cycle, they answer most of a security questionnaire without a scramble, and they feed directly into broader website governance and risk management obligations.

Who owns this in your organisation right now

Ask three questions internally. Who receives the advisory email for every platform and package your website depends on? Who decides, within 48 hours, whether a given CVE is exploitable in your configuration? Who deploys the fix, and under what agreed timeframe?

If the honest answer to any of them is "the developers, when they have capacity" or "the host, I assume", the chain is broken at that link and it will stay broken until someone is contractually accountable for it.

Frequently Asked Questions

What is a CVE monitoring service?

A CVE monitoring service continuously matches the exact software running on your website and servers against published vulnerability data from the NVD, vendor advisories and ecosystem databases, then triages each match against your actual configuration. A managed service goes further by deciding exploitability, applying and testing the patch, and reporting the change. Monitoring without remediation capability only produces a longer list.

Is monitoring the NVD enough to cover a CMS website?

No. NVD enrichment lags CVE publication, and CPE product data for CMS plugins, themes and Composer or npm packages is often incomplete or absent. Accurate coverage requires platform advisory feeds such as Drupal SA-CORE, Silverstripe security releases and Adobe APSB bulletins, plus ecosystem advisory databases and distribution notices from Ubuntu or Debian.

How quickly should a website vulnerability be patched?

The ACSC Essential Eight benchmark for internet-facing services is to patch or mitigate within 48 hours where a working exploit exists, and within two weeks otherwise. In practice the queue should be ordered by exploitation evidence from CISA KEV and EPSS rather than by CVSS score alone, with anything actively exploited handled as an out-of-band release.

Why does a scanner report vulnerabilities that are not real?

Scanners fingerprint version strings and match them to CPE ranges, so they flag components that are installed but disabled, code paths that have been removed, and backported distribution packages whose version numbers no longer align with upstream. Resolving these requires reading the advisory against the codebase and configuration. The correct outcome is a documented false positive, not an ignored ticket.

What happens when a vulnerable component has no fix available?

The options are removing the component, backporting the upstream patch to your pinned version, virtually patching at the WAF or edge, or constraining exposure by restricting the affected path. Each of these is a temporary measure that should be recorded with a review date and paired with a scheduled upgrade to a supported version.

Can you provide CVE monitoring if our website is hosted elsewhere?

Yes. Monitoring, triage and patching can be delivered as a management-only engagement on infrastructure you already own in AWS, Azure or another provider, or as part of fully managed hosting. Either way the engagement begins with an infrastructure and component audit, because an accurate inventory is the prerequisite for everything that follows.

Managed CVE monitoring and patching with UnDigital

UnDigital runs CVE scanning and vulnerability monitoring as a closed loop rather than a report: inventory, advisory monitoring across platform and ecosystem feeds, triage against your configuration, patch development, staging verification, production deployment and evidence. Because the same team holds the infrastructure and the application, there is no handover point where a finding can stall. It sits inside our wider website security management and monitoring work, and the resulting patch register is usually the fastest way to shorten the remediation cycle after a penetration test.

Every engagement starts with an audit of what you are actually running, because that is the only honest starting point for a patch policy you can defend.