> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Target

> Define scan targets — root domains, IP addresses, and CIDR ranges — for asset discovery

A **Target** defines the scope for asset discovery within a workspace. Targets are the input to scanning: discovery resolves them into [assets](/asset), and every [job](/jobs) runs against a target's scope.

You can reach the module from the console sidebar by opening **Targets** (under the **Attack surface** section; route `/targets`).

Targets help standardize how scan inputs are defined, reused, and monitored, making it easier to manage large and complex attack surfaces.

> [!NOTE]
>
> Targets are workspace-scoped. All targets are isolated per workspace and cannot be accessed across different workspaces.

***

## Target types

A target accepts one of the following input types:

| Type | Description | Example |
| - | - | - |
| **Root domain** | A registered domain; discovery enumerates subdomains and services beneath it | `example.com` |
| **IP address** | A single IPv4 address | `203.0.113.10` |
| **CIDR range** | A contiguous network block (`/24` is the typical entry) | `203.0.113.0/24` |

Prefer **root domains** over deep subdomains — starting at the root lets discovery map the full subtree. Use **CIDR ranges** when you operate whole network blocks (for example cloud ranges), and single **IP addresses** for isolated hosts.

***

## Target scope

Each target is marked as either **Internal** (belongs to a non-internet-facing network) or **External** (part of your internet-facing attack surface).

***

## Targets list

The Targets page lists every target with:

| Column | Description |
| - | - |
| **Target** | The target value (domain, IP, or CIDR) |
| **Services** | Number of services discovered for the target |
| **Last Discovery** | When the target was last discovered |
| **Scan status** | Current status of the most recent scan |

Filter the list with the **All types**, **All statuses**, and **All targets** dropdowns to narrow by input type, scan state, or a specific target. Click a target to open its detail page (`/targets/:id`).

***

## Start discovery

Discovery is started from the **Start discovery** button, which opens a wizard (`/targets/start-discovery`):

**1. Enter your targets**

The wizard prompts: *"Enter one or more targets to scan, separated by commas or new lines"*. Type one or several targets into the textarea — the placeholder shows the expected format: `e.g. example.com, test.com, demo.org`.

**2. Choose the type**

Select the input type from the radio options:

* **Root domain**
* **IP address**
* **CIDR /24**

**3. Start the scan**

Review your entries and click **Start Discovery**, or **Cancel** to discard. The target is created and the discovery job begins.

> [!NOTE]
>
> Bulk entry is supported: separate multiple targets with commas or new lines in the same field, so you can onboard a whole set of domains or hosts in one go.

***

## Target detail

The detail page (`/targets/:id`) shows the target's status and recency, e.g. **Scan status** with **4 days ago** since the last run. Two tabs organize the target's data:

### Inventory

The discovered inventory for the target. Sub-filters (IP / Port / Technology / Status Code / Host / TLS Host / Date) narrow the results, and view modes (Services / Hosts / Ports / IP Addresses / Technologies / Status Code / TLS / Graph) pivot the perspective. A typical service row shows:

| Field | Example |
| - | - |
| **SERVICE** | `oasm.dev:8443` |
| **SCREENSHOT** | Visual preview of the service |
| **TECHNOLOGIES** | e.g. `Cloudflare`, `HSTS` |
| **CERTIFICATE** | TLS certificate state |
| **TIME** | When the observation was recorded |

### Vulnerabilities

The [vulnerabilities](/vulnerability) detected on this target, with severity, status, and analysis state — the findings that came out of scanning this scope.

***

## Discovery lifecycle

Every discovery run starts **Queued**, moves to **Running** while it scans the target, and finishes as **Completed** (assets were updated) or **Failed** (check the [job](/jobs) details for the error).

> [!NOTE]
>
> Track runs in the [Jobs](/jobs) module, where each discovery shows its status, trigger (manual or scheduled), and result. A failed discovery does not remove previously discovered assets.

***

## What discovery yields

A successful discovery run produces or updates:

* **Services** — host + port combinations (e.g. `oasm.dev:8443`)
* **Technologies** — detected frameworks and services (e.g. Cloudflare)
* **TLS state** — certificates and TLS hosts
* **Screenshots** — captures of web-based services
* **Vulnerabilities** — findings detected on the discovered services, visible in the target's **Vulnerabilities** tab

These feed the [asset inventory](/asset), keeping **Last Discovery** fresh and the attack surface view current.

***

## Best practices

* **Prefer root domains** over deep subdomains so discovery enumerates the full tree
* **Use CIDR for ranges** — a single `/24` beats dozens of individual IP entries
* **Monitor Last Discovery** — stale targets (e.g. **4 days ago** and growing) mean your inventory is out of date; re-run discovery
* **Separate internal and external scope** — mark targets as Internal or External so public and private exposure stay clearly distinct
* **Use bulk entry** to onboard target sets quickly with comma/newline-separated input

***

## Related pages

> **[Assets](/asset)**
>
> Discovery populates the asset inventory from targets.

> **[Groups](/group)**
>
> Organize discovered assets into named collections for scoped runs.

> **[Jobs](/jobs)**
>
> Monitor discovery runs and their lifecycle.

> **[Vulnerabilities](/vulnerability)**
>
> See what scanning the target uncovered.

***

> [!NOTE]
>
> Everything available in the console is also available through the API — see the API Reference tab.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.