Probus Web Application Attack Surface

Probus is a Guard capability that extends web application attack surface coverage with automated tier-one vulnerability discovery. When a target exposes an OpenAPI-backed web application model, the Probus adapter runs automatically and translates its deduplicated findings into Guard Risk and proof output pairs. API fuzzing results from Probus now appear alongside findings from all other capabilities in the standard Guard findings view.

Requirements

For the Probus adapter to activate against a target, the following conditions must be met:

• The target carries a valid web application model key.
• The target has a resolvable application details record.

No additional configuration is required for authenticated scanning. The adapter participates in Guard's existing WebAuth lifecycle hook, so coverage of authenticated application surfaces is handled automatically.

How It Works

1. Guard evaluates the target and confirms it matches the web application adapter criteria above.
2. The Probus library is invoked against the target's OpenAPI-defined attack surface.
3. The static planner builds requests for each endpoint, co-sending all required query parameters alongside each probe payload.
4. Probus produces a deduplicated set of tier-one findings.
5. Each finding is mapped to Guard Risk and asset types — including severity, evidence, and asset attribution — and delivered through the standard compute pipeline.
6. Findings appear in your Guard results alongside findings from other capabilities, with full lifecycle classification (Role and Outcome metadata).

Key Capabilities

Findings and Output

Each finding Probus identifies is surfaced as a standard Guard Risk with an associated proof artifact. Findings include Role and Outcome metadata, ensuring they render correctly and carry lifecycle classification. Findings appear in the Guard interface and reports in the same format as risks produced by other capabilities, allowing unified triage and remediation workflows.

Sibling Query-Parameter Coverage

Prior to this update, the static planner omitted sibling required query parameters when constructing fuzzing requests. Requests missing required parameters are often rejected by the target before reaching the parameter under test, which could cause valid findings to be missed. The planner now populates all required query parameters for an endpoint when probing any individual parameter, consistent with the behavior already applied to body parameters.