We started the month with a simple exercise: put Attack Surface Scan next to the two biggest names in external attack surface management, Microsoft Defender EASM and Google's attack surface product, and list every gap that mattered to a small security team or an MSP. Then we closed the ones that fit how we work: flat pricing, nothing to install, and only scanning what you have proven you own. This post is the tour. Each section links to a longer guide and to the technical documentation.

Known vulnerabilities, ranked by exploitation

The biggest addition. Every scan now reads the software versions your hosts announce (server headers, page generators, versioned script files, and the greeting a service sends when you connect) and matches them against published CVEs for about 45 products commonly found on the internet: web servers, SSH and mail servers, content management systems, application servers, VPN and edge appliances, DevOps tools, and front-end JavaScript libraries.

What matters is the order. A CVSS score says how bad a flaw could be, not whether anyone is using it. So findings are raised a step when the CVE is on the CISA Known Exploited Vulnerabilities catalog or has a high EPSS score, and a KEV match is flagged in the app with its own badge and alerted immediately. Software past its vendor's end of life gets its own finding.

  • Honest about uncertainty. When an edge appliance hides its version, we only raise a "potential" match for CVEs on the KEV list, capped at medium, with instructions for checking the real version yourself.
  • No live lookups during a scan. Vulnerability data refreshes nightly and scans read the stored copy, so a slow third-party service never slows or changes a scan.
  • No exploit attempts. A match means "this version is listed as affected", not "we broke in". Backported fixes can make a match wrong, and the finding says so.

Read more: prioritizing vulnerabilities with CISA KEV and EPSS, and the vulnerability matching docs.

Exposed services: 123 ports instead of 14

The port check grew from 14 common ports to 123, grouped by what they expose: databases, remote administration, file sharing, message queues, container and orchestration APIs, industrial protocols, development servers and VPN portals. It is still a plain connection check. Where a service greets new connections on its own, we read that greeting (we send nothing) and feed the version into vulnerability matching. Hosts that sit entirely behind a shared CDN are only checked on web ports, because the other ports belong to the CDN, not to you. See the full port table.

An asset inventory, not just a host list

The new Inventory page shows everything we know about your external footprint:

  • Hosts under your verified domains, and the IP addresses they resolve to, with the network owner and cloud or CDN provider for each (AWS, Google Cloud, Azure, Cloudflare, Fastly and more).
  • Dependencies: third-party services your hosts point at, such as a SaaS help desk or a hosted storefront.
  • Candidates: related domains we noticed (in your certificates, for example) that you may own. They are never scanned until you add and verify them.
  • History: what was added or removed in the last 7 or 30 days, and whether a person or the system did it. Assets unseen for 45 days are retired automatically; anything you set by hand stays as you set it.

Discovery also got broader. On top of certificate transparency, we now look at names in your own DNS records, walk the zone where its DNSSEC setup allows it, check the Wayback Machine and Common Crawl archives, follow links on your own pages, and try a short list of common host names. Only names under your verified domains that actually resolve are kept, and plan limits still apply. Discovery runs nightly, or on demand from the Inventory page. Read more: shadow IT and external asset inventory and the inventory docs.

Domain registration hygiene

Four new checks on the domains themselves:

  • Registrar locks: whether transfer, update and delete locks are on. A missing transfer lock is how many domain hijacks start, and you get an alert if a lock is ever removed.
  • DNSSEC: missing, or worse, published but broken.
  • security.txt: whether researchers can find out how to report a problem to you, and whether the file has expired.
  • Weak certificate signatures: certificates still signed with SHA-1 or MD5.

The Domains page now shows each domain's registrar, expiry date and lock status, and warns you when your domains are spread across several registrars. Read more: the domain hygiene checklist and the domain hygiene docs.

Website privacy checks

Each scan now reads your homepage and up to 10 pages linked from it on the same host, and flags login or personal-data forms served or submitted without encryption, insecure content on secure pages, third-party scripts loaded without an integrity check, and known tracking cookies set before a visitor has consented. It also builds a list of every third-party script host your pages load, which is a useful start on PCI DSS requirement 6.4.3 for payment pages. The crawler does not run JavaScript, so cookies set by scripts are outside what it can see. Read more: website privacy checks for GDPR.

Blocklist monitoring

Your hosts and their IP addresses are now checked against public abuse blocklists, starting with abuse.ch's Feodo Tracker. A listing is often the first sign that a server has been compromised and is being used against someone else. Listings on shared CDN addresses are shown as informational, because they usually concern another customer of the same provider. See the reputation docs.

Compliance views and CSV export

The Compliance page now has a tab for each framework auditors ask about: OWASP Top 10, CWE, CISA known exploited, Privacy (GDPR), CIS Controls v8 and PCI DSS 4.0.1. Each category shows whether action is needed, with the affected hosts one click away. Categories an external scan cannot assess say "Not assessed" rather than a misleading pass. The same view is in the evidence PDF, and every finding, change and inventory item exports to CSV, including for accounts whose plan has lapsed. Read more: mapping scan findings to OWASP, PCI DSS, CIS and KEV and the compliance docs.

Alerts where your team already works

Alongside email, Slack and webhooks, alerts now go to:

  • Microsoft Teams, through a Workflows webhook, with the digest and critical alerts.
  • PagerDuty, for critical and high changes only, grouped so a repeat of the same problem does not open a second incident.
  • Jira, through a Jira Automation rule, so a high-priority change can become a ticket without storing any Jira password with us.
  • Your SIEM, with an optional OCSF format on generic webhooks.

Every channel has a Send test button. MSPs can still route each client's alerts to that client's own channel. Read more: routing alerts into Teams, PagerDuty, Jira and your SIEM and the integration setup docs.

A REST API

Growth, MSP and Enterprise plans can create API keys on the Team page and read findings, assets, changes, scans and domains from a read-only REST API. Keys are shown once, stored hashed, belong to the organization rather than a person, and can be revoked at any time. See the API reference.

On the blog: vulnerability news

Because we now track exploited CVEs, the blog has a new vulnerability news section: short, sourced write-ups of newly exploited flaws in internet-facing products, with affected and fixed versions and a plain answer to whether a scan would catch it.

What did not change

  • Pricing. Plans are still $25, $49 and $149 a month, with no per-asset metering and no overage charges. Every new check is included from Starter up.
  • What we scan. Only domains you have proven you own, re-checked every night. Related domains we discover wait for your verification.
  • How we scan. Ordinary connections and page requests, identified by our scanner's User-Agent. No payloads, no login attempts, no exploit checks.

What we still do not do

To be clear about scope, since the big platforms do some of this: we do not scan whole IP ranges, validate exploits, monitor criminal forums for leaked credentials, or connect to your cloud accounts. If those are on your requirements list, our Defender EASM and Google comparisons say plainly where each is the better fit.

Frequently asked questions

Do I need to change anything to get the new checks?

No. The new checks run on your next scheduled or manual scan. Vulnerability matching starts once the nightly vulnerability data has loaded, and the first scan after that establishes a baseline, so existing issues do not all arrive as "new" alerts at once.

Did prices change?

No. Every new check is included on every plan. The REST API is on Growth and above, and lookalike domain monitoring stays on Growth and above as before.

Does the vulnerability matching scan more aggressively?

No. It reads information your hosts already publish: headers, page markup, script file names, and the greeting a service sends on connection. Matching happens against stored data after the scan, with no extra traffic to your hosts.

Where do the vulnerability and network data come from?

Free public sources, refreshed nightly: NVD, CISA KEV, FIRST EPSS, retire.js, endoflife.date, published cloud and CDN address ranges, and IP-to-network tables. The full list and licences are on the data sources page. This product uses the NVD API but is not endorsed or certified by the NVD.

Sources