Absence of evidence is never safety
An account that has never run a scan gets unconfirmed on everything, and it is labeled unconfirmed rather than green. A dashboard that turns quiet into reassuring is worse than no dashboard.
DomainGuard · vulnerability alerts
A CVE that matches a product name is not an exposure.
Most vulnerability alerting is a catalogue lookup wearing an alarm's clothes: your watchlist says you use a product, a feed says that product has a critical advisory, and you get a red row. DomainGuard asks the harder question afterwards — is that thing actually running here, at a version this advisory covers — and puts the answer on the alert.
KEV and CVE alerting is not plan-gated. It runs on the free plan, against whatever your scans have observed.
The four verdicts
Every alert carries one, and it is derived from your evidence.
Not from a vendor's severity score, and not from whether the product name appears somewhere in your account. From what scans on your own domains actually observed.
- Confirmed
- A scan on your account cited this CVE outright, or the affected product is observed running at a version that falls inside a published affected range.
- Possible
- The product is observed running here, but the version is unknown or the advisory publishes no machine-readable range to compare against. Anything ambiguous lands here rather than in one of the confident buckets.
- Not affected
- The product is observed running and every observed version sits outside every published affected range. This is the only verdict that claims safety, and it needs both a concrete observed version and a concrete published range to be issued.
- Unconfirmed
- No scan on this account has ever observed the product. It is on your watchlist; that is all we know. Unconfirmed means we have not seen it, not that you are fine, and the interface says so in those words.
What the verdict is built from
Four sources, joined per alert.
Each one is something your account already holds because a scan produced it. Nothing here is inferred from your industry, your plan, or a questionnaire.
01
Scanner findings
A vulnerability scanner naming the CVE directly on one of your hosts. The strongest signal there is.
02
Observed components
What technology fingerprinting saw running on each domain, with a version where the site exposed one.
03
Service banners
Product and version parsed from an open port's banner during service discovery.
04
Published version ranges
The CPE version bounds NVD publishes for the advisory, which is what makes a not-affected verdict possible at all.
Four rules that keep it honest
Each of these is here because something went wrong first.
They are not principles somebody wrote on a slide. They are the fixes for specific defects, kept as rules so the defect cannot come back.
Name matching is not substring matching
A token-based match will happily connect a product called WP Engine to Microsoft Exchange advisories through the word engine. That exact failure happened here and the matcher was rewritten because of it. Matching a product name is a harder problem than it looks and it is treated as one.
A dismissal survives a re-scan
Dismissals key off what a finding is, not off the database row it arrived in. Deciding once that something does not apply to you means it stays decided the next time the scanner runs.
Inventory is reconciled, not appended
An append-only list of everything ever observed slowly fills with software you removed two years ago. What is currently running is resolved at read time, so retired components stop generating alerts.
Where the advisories come from
Two public feeds and one private half.
The public half is the same data everyone has. The private half is what makes an alert about you rather than about the internet.
- CISA KEV
- The Known Exploited Vulnerabilities catalog, pulled hourly with a conditional request so an unchanged catalog costs nothing.
- NVD
- The National Vulnerability Database, pulled incrementally and throttled, so new advisories arrive without hammering a public service.
- Your own observations
- The other half of the join. Feeds say what exists in the world; scans say what exists on your hosts. An alert is the intersection, with a verdict attached.
Open ports and running services are discovered by an active scan, which only runs against domains where you have proved control — a DNS record, a file on the site, or an email at the domain, valid for 90 days. That gate is deliberate and it is what keeps the scanner usable: an unauthenticated port scanner aimed at strangers is how a platform account gets terminated.
Straight answers
Questions about CVE alerting.
Why not just alert on everything that matches?
Because that was tried and it does not work. An account watching a couple of dozen common products accumulated well over a hundred KEV rows, nearly all of them for software no scan had ever seen running on any of that account's domains, and several for versions the account demonstrably did not run. Everything was red and nothing was actionable, which is functionally the same as no alerting at all. The verdict layer exists to make the red rows mean something.
What does the scanning actually reach?
Two levels. Passive checks read what your site already serves anyone: security headers, TLS posture, and technology fingerprinting. Active work — port and service discovery, and the aggressive web scanners — reaches further and is gated on you proving control of that specific domain, by a DNS record, a file on the site, or an email at the domain. Proof lasts 90 days and is per domain.
Why is proof of ownership required at all?
Because unauthenticated port scanning of arbitrary third parties from a shared platform is the kind of activity that gets a platform account terminated, and every customer on it goes down with it. The gate is what keeps the active scanner available. There is also a denylist that always applies: banks, government and military sites, and major platforms are refused regardless of what anybody proves.
Do CVE alerts cost anything?
No. KEV and CVE alerting is not plan-gated at all — the feeds are matched against every account's observed components regardless of plan. There is a real catch worth stating: on the free plan that inventory only advances when you run a scan by hand. The alerting is automatic; the observing is not. Scheduled vulnerability scanning starts on Starter at $6.99 a month.
Does DomainGuard patch anything?
No. It finds, verifies against your own evidence, and tells you what to do. Applying the fix happens on your server, your CMS or your host. If you would rather hand that off, NHM does managed IT and security work in Northeast Ohio, and that is a separate conversation from the software.
Get the first observation in
Alerts are only useful once something has looked at your hosts.
Run one scan on the free plan and every future advisory gets measured against what it found. The iPhone app is in a public TestFlight beta and signs in with the same account.