Penetration Testing¶

VirtualSutra AI supports two ways to get penetration test findings into the platform: ingesting a report from an existing tool (Burp Suite, or any SARIF-producing scanner), and dispatching VirtualSutra's own bounded, non-destructive pentest-agent against a target you explicitly authorize. Both paths land in the same Findings pipeline and the same per-target report.

Where to find it¶

• Settings > Connections > Pentest Targets: register targets and their standing authorization.
• Runs > New Pentest (/runs/new-pentest): upload a report or dispatch an agent-run test.

Registering a pentest target¶

Before you can upload a report or dispatch a test, add a target under Settings > Connections > Pentest Targets:

Pentest targets are a distinct connection type from DAST web applications. They do not support scope/path exclusions or an OpenAPI spec, since agent-run pentest checks are intentionally narrower and non-destructive by construction (see Safety model below).

Uploading a report¶

Open Runs > New Pentest and select the Upload Report tab.

1. Choose the target this report is for.
2. Upload a file in either format:
3. SARIF (.sarif, .json): the standard static/dynamic analysis interchange format most scanners can export.
4. Burp Suite XML: the native export format from Burp Suite's report generator.
5. Submit. VirtualSutra detects the format automatically, parses it, and creates a run whose findings are immediately visible on the Findings tab.

Severity mapping from SARIF's level field: error maps to high, warning to medium, note/none to low. An unrecognized level is mapped to medium and tagged so you can identify it.

There is a maximum upload size; an oversized file is rejected with a clear error rather than partially ingested. A malformed file is rejected outright; nothing is written.

Dispatching an agent-run test¶

Select the Run Agent Test tab, choose a registered target, and confirm authorization:

1. Type the target's exact hostname into the confirmation field (case-sensitive).
2. Check the attestation box confirming you are authorized to test this target.
3. Both are required before Dispatch Pentest becomes clickable.

Note: This in-UI confirmation is a convenience layer. The server independently re-derives the target's hostname and re-checks authorization at dispatch time, so a request that skips or spoofs the UI confirmation is still rejected server-side.

Once dispatched, the pentest run appears in the Runs list with a PENTEST badge (filterable via the Type filter: All / Inspection / Pentest) and progresses like any other run.

What the agent checks¶

The pentest-agent runs a small, fixed library of read-only, non-destructive checks against the target:

None of these checks are destructive, and the agent never issues anything but GET/HEAD/OPTIONS requests. This is enforced in the agent's code, not just by convention.

When a check could not run¶

A check that could not run - its configuration is unusable - or that failed partway is not reported as "probed, nothing found". The pentest task still completes and the other checks still run, and the task's message names what was missed: INCOMPLETE COVERAGE: N check(s) not covered …. The run shows that entry among its errors and records a coverage gap for the pentest target, so a run with no pentest findings and this message has not shown the target clean for that check. The message names the check and a fixed reason, never a configured value.

For operators - the SSRF marker host. The SSRF check builds its marker URL from the PENTEST_SSRF_MARKER_BASE_URL environment variable of the pentest agent:

• Unset, it uses an inert public default host.
• Whitespace around the value is stripped when it is read - a value mounted from a Secret usually ends in a newline.
• A value that is set but blank, or that has whitespace or a control character inside it, is refused: the SSRF check does not run and is reported as incomplete coverage. So is a marker URL that the outbound guard refuses.

Safety model of agent-run checks¶

Every dispatch passes through several independent gates, in order: a write-permission check on your API key/session, an SSRF guard on the target URL itself, a per-target cooldown (15 minutes by default) to prevent accidental repeat dispatch, and the typed-confirmation check described above. A pentest run can never be re-run via the normal "repeat this run" action, and retrying or resuming a failed run never re-dispatches the pentest task; you must go back to the wizard and confirm again each time.

Findings¶

Pentest findings appear on the Findings tab like any other finding, with:

• A Pentest filter in the source sidebar.
• An origin chip on the finding detail sheet, Pentest · Ingested for uploaded reports and Pentest · Agent Run for agent-dispatched checks, so you can tell which path produced a given finding even after both have contributed to the same target's history.

Reports¶

Each pentest target gets its own report, titled Penetration Test Report, combining findings from both ingested reports and agent-run checks for that target into a single document rather than a separate report per origin. Pentest reports are HTML only (no PDF tier), consistent with the reporting engine's other per-scope reports; see Reports for downloading and sharing.