Request demo

Methodology

How We Collect, Scan and Score.

Researchers, procurement teams and security reviewers tend to ask us where the data comes from, how often it changes, how a finding becomes a priority and what happens when a finding is wrong. This page answers them in writing, and says where the method stops.

Ask about the method How the platform works

Scanall checked

acme.example → 203.0.113.24

  1. WHOISwhois

    registrar · registered and expiry dates · name servers

  2. IP WHOISipwhois

    AS64500 · network owner · range · country

  3. DNSdns

    A 203.0.113.24 · MX · NS · TXT

  4. SSLssl

    issuer · valid to · names covered

  5. Portsport_scan

    3389/tcp open · RDP

    Critical

  6. Web datawebdata

    Apache httpd 2.4.49 · cpe:2.3:a:apache:http_server:2.4.49 · login page

  7. HTTPhttp

    status 200 · headers · redirects

CVSS + EPSS + CISA KEV → one priority

state newly_detected

Each layer stored separately with the date of every check.

Non-intrusive: no authenticated scans, no exploit attempts.

What We Collect and Where It Comes From.

The index under all the modules is our own, built from the open internet: passive DNS, certificate transparency logs, public WHOIS and IP WHOIS records, and crawling of publicly reachable web pages. None of it is collected from behind a login, a paywall or an anti-scraping control.

Vulnerability data comes from public sources too: CVE records with their CVSS metrics, EPSS scores published by FIRST and the Known Exploited Vulnerabilities catalog published by CISA.

400M+ domains across every TLD
2B+ subdomains discovered and resolved
200B+ DNS records cumulative, with history
30B+ SSL certificates indexed

Each Layer Is Kept With Its History.

Monitoring runs on the assets in your inventory: the ones your team adds and the discovered candidates it approves. Each layer is stored separately with the date of each check, so any change can be traced to the scan that saw it.

WHOISRegistrar, registration and expiry dates, name servers, status codes, and the registrant where published · whois
IP WHOISNetwork owner, ASN, allocated range and country · ipwhois
DNSA, AAAA, MX, NS, SOA, TXT, CNAME and other record types, plus PTR records for IP assets · dns
SSLThe certificate a host serves: issuer, validity dates and the names it covers · ssl
PortsTCP and UDP ports found on the asset, with the protocol and state of each · port_scan
Web dataPage content, technologies with their CPE names, login pages and screenshots · webdata
HTTPResponse headers, status codes and redirects · http

Standard monitoring is non-intrusive: no authenticated scans, no exploit attempts and no load tests. Scans run from infrastructure Deepinfo operates and make no attempt to hide from the hosts they check.

We Read CVSS, EPSS and KEV Together.

Severity says how bad a vulnerability could be. Exploitation data says whether anyone is likely to use it.

Every CVE found on your assets carries its CVSS metrics, its EPSS probability of exploitation in the next 30 days and its CISA KEV status, along with its CWE and vDeep, Deepinfo’s own CVSS scoring layer. Prioritization reads CVSS, EPSS and KEV together, so a medium-severity CVE that is listed in KEV and likely to be exploited ranks above a critical one with a low EPSS score and no KEV listing.

Security scores for assets and domains combine the issues found across all layers, weighted by severity and by real-world exploitation signal. A score is computed from a snapshot of findings, so a given set of findings always produces the same score. Customers who want the rubric behind a score can ask us for it.

  • Issues: a severity from Critical to Information, classified against OWASP, PCI DSS, HIPAA, CWE, CAPEC and WASC
  • CVEs: CVSS, EPSS, CISA KEV, CWE and vDeep
  • Assets and domains: a security score with its timeline
  • Third parties: a security score on the scale assets use, because Third-Party Risk Management runs the External Attack Surface Management engine on each vendor
  • Lookalike domains: a risk score with its timeline

CVE on one of your assets

Fix first listed in CISA KEV, known to be exploited

  1. CVE-2021-44228

    10.0

    EPSS 0.99999 CISA KEV

    Critical

  2. CVE-2021-41773

    9.8

    CISA KEV

    Critical

The normal patch cycle EPSS low, not in CISA KEV

  1. a CVE

    9.8

    EPSS low

    Critical

  2. a CVE

    5.3

    EPSS low

    Medium

CVSS alone cannot tell the two 9.8s apart. CISA KEV and EPSS can.

What Updates and How Often.

Deepinfo sets the monitoring schedule, and each layer keeps its own cadence: DNS is checked more often than ports. We don’t publish per-layer intervals here; if your review needs them, ask us for the ones that apply to your scope.

Monitored assetsAll layers are rescanned on a recurring schedule. Each check is stored with its date, so a layer’s history shows when it was last read and what it returned.
On demandYour team can start a scan of any asset, run a port scan that returns its result in the response, or recalculate a snapshot and its score, in the platform or through the EASM API.
Change eventsNew and reappeared issues, score changes, certificate, WHOIS and DNS changes, new assets, new vulnerabilities and new open ports are among the events a notification rule can watch. Each rule delivers instantly, hourly, daily, weekly or monthly.
ScoresRecomputed from each new snapshot of findings. Timelines track the score per asset and per domain at daily, weekly or monthly intervals, and for the whole surface.
ReportsFrom the executive summary to issue detail, as PDF, generated on demand or scheduled daily, weekly or monthly.
The indexNewly registered, updated and deleted domains and newly discovered subdomains are published daily as data feeds.
Vulnerability dataEach CVE record carries its current EPSS score and percentile, with the EPSS history kept per CVE, and its CISA KEV entry with the date it was added.

Every State and Decision Stays on Record.

An issue leaves the open queue in two ways. The scan closes it on its own: verified resolved once a scan no longer finds the signal, with no one having to mark it first, or not applicable when a scan cannot tell. Or your team closes it by a decision kept on record: risk accepted, ignored or false positive. An issue your team marks as resolved still waits for a scan to verify it, and if the signal returns, the issue reopens as reappeared.

Found

Open

The team can decide

Each scan checks

newly detected

orreappeared

unresolved

checked again on every scan

optional, kept on record

  • marked as resolved
  • risk accepted
  • ignored
  • marked as false positive

verified resolved

the signal is gone: no one has to mark itnot applicablewhen a scan cannot tell

How to Challenge a Finding.

Findings rest on evidence, and evidence can be wrong or incomplete. The platform records a dispute as an issue state, so it stays on record instead of in an email thread.

  1. 01

    Check the evidence

    Open the issue. It carries the asset, the issue type with its description and remediation, the evidence the scan collected and the full state history.

  2. 02

    Record the decision

    Mark the issue as a false positive, accept the risk or ignore it, one issue at a time or in bulk through an API filter. Vulnerabilities and leaked credentials take these decisions too.

  3. 03

    Revert if needed

    Any decision can be reverted to the previous state. Candidates your team ignores in discovery or brand monitoring can be reverted too, and anything on your ignore lists is never proposed again.

  4. 04

    Tell us why

    If the detection itself looks wrong, send the issue to [email protected] or your account team, with what you know about the asset. We review the detection with you.

API reference: mark a false positive

Where the Method Stops.

What the platform can’t see, or can’t decide for you, stated plainly so your team can weigh each finding.

Outside-In Only

The platform sees what the internet sees. Internal networks, systems behind a login and anything reachable only through a VPN are out of view by design.

Attribution Needs Your Judgment

Discovery proposes assets from shared registration details, name servers, mail servers and IP addresses. Shared hosting and CDNs put unrelated domains on the same addresses, which is why candidates go to your team for review unless a rule you configured approves them.

Version-Based CVE Matching

CVEs are matched to the technologies and versions a host reports, through CPE names. A vendor backport can fix a flaw without changing the reported version, and that shows up as a false positive for your team to mark.

Between Two Checks

Monitoring is periodic. A change that happens between two checks is seen at the next one, and each layer’s history shows exactly when each check ran.

Probability Is Not Proof

EPSS estimates likelihood, and KEV lists exploitation that has been confirmed. A CVE with a low EPSS score and no KEV listing can still be exploited: prioritization orders the work, it doesn’t close it.

Redacted and Partial Sources

WHOIS records hidden behind privacy services can’t be matched in a reverse WHOIS search. Breach, infostealer and dark web coverage is partial by nature: no result means nothing was found in the sources we cover, not that nothing leaked.

Business Context Comes From You

The platform doesn’t know which assets matter most to your business until your team says so, with tags and a business-importance weight on each asset.

Questions About the Methodology

Is Deepinfo’s scanning intrusive?

No. Standard monitoring runs no authenticated scans, no exploit attempts and no load tests. Port scans and web requests reach only what a host already exposes to the internet.

Which assets does the platform scan?

The assets in your monitored inventory: the ones your team adds, and the discovered candidates that your team, or a discovery rule you configured, approves. Our Terms of Service also require that you only monitor infrastructure you own or are authorized to assess.

Does the platform scan cloud-hosted assets?

Yes, when they are reachable from the internet: a domain, subdomain or IP address on a cloud provider is monitored like any other asset. Cloud consoles and private networks stay out of view.

Can we take an asset out of monitoring?

Yes. Remove it, on its own or by filter, and its scans stop; removed assets stay listed with the date they were removed. Candidates your team ignores in discovery are never monitored.

Can we see how a score is calculated?

Yes. Scores are deterministic for a given snapshot of findings, and customers who want the rubric can ask for it. Score timelines per asset, per domain, per issue type and per issue category show how each score moved and when.

What won’t Deepinfo collect or sell?

The index holds nothing collected from behind a login, a paywall or an anti-scraping measure. WHOIS data hidden by a privacy service stays hidden in our data, and we don’t sell or broker personal data. If any of these lines changes, we’ll document the change publicly, with the reasoning.

Customer assets and findings stay in the customer’s account: we don’t surface them to other customers and we don’t sell them. Where dark web data appears in our coverage, it comes through sourcing practices established across the threat intelligence industry, and we don’t pay for newly stolen data.

Who do we ask when this page isn’t enough?

Ask your account team, or reach us through the contact page. Researchers can apply to the Researcher Program for dataset access and a methodology consultation.

Security issues in Deepinfo’s own infrastructure go through the disclosure process on our Trust page.

Ask the Question This Page Leaves Open.

Per-layer schedules for your scope, the source behind a dataset or the rubric behind a score: ask us.

Ask about the method