CVE monitoring for your domains: connect exposure to known flaws
CVE monitoring connects your exposed services to known vulnerabilities. Learn how to prioritise what to patch and why continuous beats point-in-time scanning.
CVE monitoring is the practice of continuously matching the software you expose to the
internet against the public catalogue of known vulnerabilities — the Common
Vulnerabilities and Exposures list — so that when a flaw is disclosed in something you are
running, you find out before an attacker uses it against you. It sits at the intersection
of two things you should already be tracking: what you expose (your attack surface) and
what is known to be broken (the CVE feed). On its own, a CVE is just an entry in a
database. CVE monitoring is what turns "there is a critical flaw in this web server" into
"we are running that web server on app.example.com, and it is reachable from the
internet right now."
Why a CVE only matters when it touches your surface
There are tens of thousands of CVEs published every year. Almost none of them apply to you. The skill is not reading the feed — it is the join between the feed and your estate:
- A CVE in a database engine you do not run is noise.
- The same CVE in a database engine you have accidentally exposed on a public IP is an incident waiting to happen.
This is why CVE monitoring depends on a complete, current inventory of exposed services. You first need to know which hosts you have, which ports they listen on, and what software and versions answer there. Only then can the CVE feed tell you anything actionable. Skip the inventory step and you are either drowning in irrelevant CVEs or, worse, blind to the one that matters because the affected host was not on your list.
From exposure to known flaws: how the connection is made
The pipeline that makes CVE monitoring useful has a few stages:
- Enumerate hosts. Know every subdomain and address you expose (this is where subdomain enumeration and CT-log discovery feed in).
- Identify services. For each live host, determine which ports respond and what software is behind them — server banners, response fingerprints, TLS metadata.
- Resolve versions. Pin down the software and, where possible, its version.
- Match against CVEs. Cross-reference the identified software against the CVE catalogue to flag known vulnerabilities affecting those versions.
- Prioritise and act. Triage the matches by real-world risk and patch accordingly.
The output you want is not "here are 4,000 CVEs" but "here are the handful of exposed services on your estate with published vulnerabilities, ranked".
Prioritising what to patch first
You cannot patch everything at once, and not everything deserves the same urgency. Sensible prioritisation weighs several factors together rather than chasing a single number:
| Factor | Question to ask | Pushes priority up when |
|---|---|---|
| Exploitability | Is there known exploitation in the wild? | A working exploit exists and is being used |
| Exposure | Is the affected service reachable from the internet? | It is publicly exposed, unauthenticated |
| Severity | What is the CVSS / impact rating? | High or critical, especially RCE |
| Asset value | What does this host do or have access to? | It handles sensitive data or auth |
| Effort | How hard is the fix? | A patch or version bump is readily available |
A medium-severity flaw in an internet-facing service that is being actively exploited usually outranks a "critical" in something tucked behind authentication that nobody is attacking. Public exploitation catalogues — the kind that track which CVEs are known to be exploited — are far more useful for prioritisation than raw severity scores, because they reflect what attackers are actually doing rather than what is theoretically bad.
Continuous vs point-in-time scanning
The most consequential choice in CVE monitoring is cadence, and it is where point-in-time scanning falls down.
A scan is a snapshot of a moving target. Two things change constantly and independently:
- Your surface changes. New hosts come online, services are upgraded or downgraded, ports get opened. A scan from last quarter describes an estate that no longer exists.
- The CVE feed changes. A host that was clean on Monday becomes vulnerable on Tuesday the moment a new flaw is disclosed for software it has been running unchanged for a year. Nothing about the host changed — the world's knowledge of it did.
That second point is the killer argument for continuous monitoring. The dangerous gap is not the day you scan; it is the weeks between scans when a fresh CVE lands against software you are still running. Continuous monitoring re-evaluates your known inventory against the latest CVE data as it arrives, so the alert fires on disclosure day, not at the next scheduled scan.
| Point-in-time scan | Continuous monitoring | |
|---|---|---|
| Catches new CVEs against existing hosts | Only at next scan | On disclosure |
| Catches new exposed services | Only at next scan | As they appear |
| Best use | Compliance snapshot, deep audit | Day-to-day defence |
Knowing the limits
Be honest about what monitoring does and does not do. CVE monitoring finds and flags known vulnerabilities on services you expose — it identifies likely-affected software and tells you to look. It is not a pentest, it does not exploit anything to confirm exploitability, and it does not patch your servers for you. Version-based matching can produce false positives (a backported fix on a vendor build) and occasional false negatives (software it cannot fingerprint). Treat its output as a prioritised worklist for humans, not a verdict. Used that way, it is one of the highest-leverage controls a small team can run.
DomainOps ties CVE flagging directly to the attack surface it already maps for you: exposed services discovered through continuous subdomain enumeration and port checks are matched against known vulnerabilities and surfaced as prioritised alerts — not a raw feed to wade through. The exposure-monitoring docs cover how detection and CVE matching work together. To start watching your own estate continuously, get started here; and if you want to see what you expose before anything else, map a domain with the free subdomain takeover scanner.