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

# Run Your First Live Battletest

> Add a domain, run a passive discovery scan, approve active probing, and read a confirmed vulnerability finding in your first automated external pentest.

<Warning>
  **Startup plan or higher required** for live battletest. [View plans →](https://battletest.dev/pricing)
</Warning>

In this tutorial you'll add a domain to BattleTest, run a discovery scan, advance to active probing, and read a confirmed finding. By the end you'll understand the three phases of a battletest and know how to read the results.

This takes about 20 minutes end-to-end, most of which is waiting for scans to complete. You'll need a Startup plan or higher and a domain you own or are authorised to test — a staging environment is ideal. If you signed up with email and password rather than GitHub, verify your email first — the **Add Target** button is disabled until you do ([Settings → Account](https://battletest.dev/settings?tab=account)).

<Steps>
  <Step title="Add the target">
    Go to [Tests](https://battletest.dev/tests) and click **New Environment**.

    Enter your domain name without a protocol — for example, `staging.example.com`. Leave the permission tier at **Read-only** for now. Click **Add Target**.

    You're taken to the environment detail page with an *Inactive* status.
  </Step>

  <Step title="Run the discovery scan">
    Click **Activate**. The status changes to *Running* and the discovery phase begins.

    Discovery is passive — it sends ordinary HTTP requests to map what the application exposes. Nothing harmful happens at this stage. It takes 5–15 minutes depending on the application size.

    When the scan completes, click on the scan run to open the results. You'll see:

    * An **endpoint inventory** — pages, API routes, and forms the crawler found
    * A **technology fingerprint** — what stack the application appears to run
    * An **SSL/TLS assessment** and basic header analysis
    * Any informational findings from the passive phase

    At read-only permission, there are no injection findings, no port scan results, and no active vulnerability probes.
  </Step>

  <Step title="Approve active probing">
    To find real vulnerabilities, you need to send attack probes. Go back to the environment detail page and click the **Approvals** tab.

    The four permission tiers are listed — from passive observation to full exploit chain execution. Each tier is irreversible for the current scan once approved; you can always run a new scan at a lower tier if needed. [What each tier does →](/docs/concepts/live-battletest-overview#the-permission-tier-model)

    Click **Approve** next to **Active probing**. Read the confirmation — it describes what this tier does: injection testing, directory enumeration, port scanning. Click **Confirm**.

    Go to the Tests page and click **Run scan** on the environment.
  </Step>

  <Step title="Read the active scan results">
    Active probing takes 15–30 minutes for a typical application. When it completes, open the scan run.

    The report now includes findings from the active phase. Look for a finding marked **Confirmed** — this means the agent verified the vulnerability with a working proof of concept, not just a pattern match. Each confirmed finding shows:

    * The endpoint and parameter that were vulnerable
    * The exact payload that triggered the vulnerability
    * The server's response that confirmed it
    * Reproduction steps you can run yourself
    * Remediation guidance for your stack

    Findings marked **Potential** were detected but could not be confirmed at this permission tier. They're worth investigating manually or by approving the next tier on a dedicated test environment.
  </Step>

  <Step title="Compare with the previous scan">
    Click the **Compare** tab on the scan run. With two scans now — the read-only discovery and the active probe — you can see how the finding count changed between them.

    Findings are classified as: **new**, **persistent**, **resolved**, or **regression**. This comparison view is what you'll use after every deploy or security fix.
  </Step>
</Steps>

You've completed a full battletest cycle: discovery, active probing, confirmed findings, and comparison. The same external-attacker perspective that a traditional pentest provides — scoped to the most automatable vulnerability classes — ran against your domain in under 30 minutes and at a fraction of the cost.

Every subsequent scan on this target follows the same flow. The comparison view is what makes the value compound: each scan tells you not just what's vulnerable today, but whether your fixes held and whether anything new appeared since the last run.

## What's next

<CardGroup cols={2}>
  <Card title="Manage findings" icon="list-check" href="/docs/how-to/manage-findings">
    Dismiss false positives, mark resolved, and track open issues.
  </Card>

  <Card title="Export for audits" icon="file-export" href="/docs/how-to/export-findings">
    Export findings as PDF or JSON for SOC 2 evidence.
  </Card>

  <Card title="Scan results reference" icon="book" href="/docs/reference/scan-results">
    What every field in a scan report means.
  </Card>

  <Card title="Add more targets" icon="plus" href="/docs/how-to/adding-a-target">
    Manage target slots, cooldowns, and add-ons.
  </Card>
</CardGroup>