Run live application testing
Use Battletests in your Enterprise deployment to start testing and review past results. You need permission to run scans in the target’s organization.
Start a battletest
Section titled “Start a battletest”Open Battletests and select Start battletest.
- Targets: Choose an organization and select the hosts to test. Search by hostname or filter by environment. To register a missing host, select Add target. Registration is checked against any configured scope restrictions before you continue. Enterprise deployments do not require DNS verification.
- Testing level: Choose Discover, Probe, or Full exploit. Full exploit requires an explicit authorization confirmation for the selected targets.
- People: Search organization members by name, email, or username. Selected people receive viewer access and an invitation notification when testing starts. Select Save as my default to reuse that invitation list for future battletests in this organization.
- Review: Check the targets, level, and people, then select Start battletest. Each selected target starts a separate battletest.
If some targets cannot start, the dialog lists their errors and keeps only those targets selected for retry. The battletests that started remain in your history.
Prepare a target describes authorization, reachability, and the account requirements for authenticated coverage.
Reuse a configuration
Section titled “Reuse a configuration”Select Use configuration beside a past battletest, or Use a previous battletest in the launch dialog. Review the loaded targets, testing level, and people before starting. Full exploit authorization must be confirmed again. Remove unavailable targets or people before continuing.
Older battletests may not have a complete saved configuration. The dialog loads the recorded values and asks you to select any missing testing level.
Find past battletests
Section titled “Find past battletests”Search by target or environment, then filter by status, testing level, environment, or date. Open a battletest to follow progress and inspect its findings. Completed and failed entries also provide a report link.
What happens during testing
Section titled “What happens during testing”A run maps the application, tests within its selected level, and records findings and coverage.
1. Discovery
Section titled “1. Discovery”Discovery is passive. It sends ordinary HTTP requests to map what the application exposes, and nothing it does is distinguishable from normal traffic. It takes 5–15 minutes depending on application size, and it produces:
- 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 header analysis
- Informational findings from the passive pass
At the lowest permission tier this is where a run stops. There are no injection findings, no port scan results, and no active probes, because the tooling that would do those things is not available to the agent at that tier.
2. Active probing
Section titled “2. Active probing”Raising the permission tier makes injection testing, directory enumeration, and port scanning available. This is an explicit, recorded approval, and steps that could change state pause for a human decision. A typical application takes 15–30 minutes at this stage.
The permission tier model describes what each tier permits.
3. Confirmation
Section titled “3. Confirmation”Confirmation decides what ends up in the report. A finding is marked Confirmed only when the agent replayed it against the running system and reproduced it from a second, unrelated account. A confirmed finding carries:
- The endpoint and parameter that were vulnerable
- The exact payload that triggered it
- The server response that confirmed it
- Reproduction steps you can run yourself
- Remediation guidance for your stack
Findings marked Potential were detected but not confirmed. They are reported as unconfirmed, and the report says why confirmation did not happen.
A run also reports what it could not reach. An SSO-only login wall, an unreachable subdomain, or a tier that withheld the tooling needed to prove something are all stated in the record. Coverage you did not get is a fact about the assessment.
4. Comparison
Section titled “4. Comparison”Each run is compared against the previous run of the same environment. Findings are classified new, persistent, resolved, or regression. Regressions get the most attention: they mean something the team already spent time fixing has come back.