Application Discovery

Overview

Give NightVision one domain and Application Discovery returns an inventory of the internet-facing web applications behind it: subdomains of that domain, related domains belonging to the same company, and for each host what it appears to be, how exposed it looks, and how often it turns up in breach records. Hosts you decide to test become scan targets in a click, and scans can start from there.

The problem

You cannot test what you do not know about. Most estates have more public surface than anybody has a list of: a staging environment that was never taken down, an admin console on a subdomain nobody remembers, a product from an acquisition still running on its original domain. These are rarely in the inventory the security team works from, so they are rarely in scope for testing either. Building that list by hand is slow, and it goes stale as soon as it is finished.

The solution

Application Discovery enumerates the estate from public sources, checks each host it finds, and keeps the result as a living inventory you can re-run. Every host carries the evidence behind it: which sources found it, whether it answered, what it appears to be, and the facts that produced its exposure score.

Nothing is scanned as a result of a discovery run. Discovery tells you what is out there; you choose what to test.

Application Discovery and Source Intelligence work at different levels

Application Discovery maps the estate, so you know what is out there to test. Source Intelligence maps a single application’s code, so NightVision knows how to test it.

	Application Discovery	Source Intelligence
Starts from	A domain name	Your source code
Finds	Internet-facing hosts owned by a company	REST endpoints declared in the code
Produces	An inventory of applications	An OpenAPI specification
Runs	In NightVision’s cloud	On your machine or in CI

What a run does

A run works through eight phases, and the run screen names each one as it happens. The first six are the discovery itself; the last two enrich the result after the run has reported.

Phase	What it does
Setup	Normalizes the domain you gave it and looks up the registered company behind it.
Subdomain enumeration	Collects hostnames under that domain from public sources: certificate transparency logs, passive DNS datasets, web archives, and DNS resolution.
Probing hosts	Requests each hostname over HTTP, following redirects, and records what came back.
Sibling discovery	Looks for other domains the same company owns, such as subsidiaries, acquisitions and rebrands.
Sibling confirmation	Weighs evidence that a candidate domain really belongs to the same company, and promotes only the ones that clear the bar.
Report	Assembles the inventory, scores every host, and stores the result.
Classification	Assigns each live host a category such as Login portal or Admin panel. See Classification.
Breach records	Counts how often each confirmed host appears in a breach and infostealer corpus. See Breach records.

What discovery sends to your infrastructure

Subdomain enumeration is passive: it reads public records and does not touch the hosts it is naming. The later phases are not.

• Probing issues an ordinary HTTP request to every hostname found, HTTPS first and then HTTP, follows the redirect chain, and reads the response.
• Sibling confirmation fetches the homepage, favicon and TLS certificate of the hosts under your domain and of each candidate domain, because those are the fingerprints it compares.
• On live hosts that belong to the estate, probing also requests a small, fixed set of well-known paths that disclose misconfiguration when they are readable:

/.git/HEAD
/.env
/server-status
/actuator/env
/.well-known/security.txt
/robots.txt

Each is confirmed by content rather than by status code, so a catch-all site returning 200 for everything does not produce findings. This is a bounded check, not a scan: no fuzzing, no authentication attempts, no port scanning, and no payloads.

“Belongs to the estate” means every host under the domain you gave, and a related domain only once confirmation has found at least two strong infrastructure matches for it. An unconfirmed related domain may not be yours, so it gets the ordinary probe and nothing more.

The breach-record phase sends nothing to your estate. It asks a third-party corpus for counts; no credentials are retrieved or stored.

Only run discovery against estates you are authorized to assess

A run contacts real infrastructure under your organization’s name. Run it against domains you own or have been explicitly authorized to test.

Availability

Application Discovery is on for every team workspace on a Professional or Enterprise plan. When it is on, Discovery appears in the left sidebar of the portal; when it is not, the section is not shown at all.

It is off by default for personal workspaces, whatever their plan, and for workspaces on a trial. NightVision can switch it on or off for a specific workspace; contact NightVision to arrange that.

Within a workspace, what you can do depends on your role:

Role	Run on a new domain	Re-run a domain	Stop a run	Classify hosts	Mark key assets	Create targets
Organization Admin	Yes	Yes	Yes	Yes	Yes	Yes
Project Manager	Yes	Yes	Yes	Yes	Yes	Yes
Scan Operator	No	Yes	Yes	No	No	No
Read-Only	No	No	No	No	No	No

Starting a run on a new domain creates an inventory in a project, so it needs the permission to change that project. Re-running a tracked domain needs only the discovery permission.

Controls you do not have permission for are hidden rather than disabled, so a Read-Only member sees the inventory and no buttons. The one exception is the Key asset switch, which is shown disabled with a tooltip.

Next steps

Running a discovery ▶ Reading the inventory ▶ Creating targets from discovery ▶ FAQ ▶