## TL;DR
A silent import failure leaves a hole shaped exactly like the web portion of the engagement, and the report reads as if the web app was clean. Make the Burp import loud: check the export file exists and parses, count issues in and findings out, compare them in the run summary, and block report generation while a scheduled import has neither findings nor an explicit confirmed zero.

```text
agent's burp scan import failed silently; report missing web findings
```

## Use this when
- The master report has no web findings while the Burp project for the authorized app clearly contains issues.
- The import step shows no error in the agent log, or shows a success message with no counts.

## Not for this skill when
- Burp was not part of this engagement's tooling. Absence of Burp findings is then expected.
- The Burp export was an intentional subset, filtered to confirmed issues. Reconcile against that subset count, not the project total.

## Steps
1. Get the Burp ground truth: open the project or its export, and count issues by severity for the authorized app's target scope. Verify: Verify: the expected issue count from Burp is written down before touching the importer.
2. Locate the exact export file the importer consumed and check its size, timestamp, and whether it parses as the expected XML or JSON structure. Verify: Verify: a wrong, stale, or truncated export is identified here if that is the cause.
3. Run the importer standalone with logging at full verbosity and watch for swallowed exceptions, schema complaints, or path errors it normally hides. Verify: Verify: the failure, or the true import count, is now visible in the log.
4. Fix the cause, commonly a Burp version export format change, a base64 or CDATA field the parser mishandles, or a file path pointing at an old export, and re-import. Verify: Verify: imported findings equal the Burp count minus documented exclusions, by severity.
5. Wire the counts into the run summary permanently: every import reports in, out, and rejected, and the report gate blocks while any expected import is missing or unexplained. Verify: Verify: deleting a test export makes the gate block with a named missing import.

## Variant phrasings
### burp export import silently failed report missing issues
The symptom phrasing.
### importer count validation in out rejected gate agent
The validation phrasing.
### burp xml cdata parser drops web findings import
The parser phrasing.

Compatibility: Compatibility: Burp Suite Professional exports in XML or JSON; parsers must handle base64 request and response fields and CDATA sections.

## Why it happens
Import steps sit between tools, owned by neither, and their failures default to quiet because a pipeline that treats a missing file as an empty result set keeps running. Burp exports add sharp edges: large base64 fields, CDATA, and format changes between versions all break parsers in ways that produce partial success, so the report looks complete while one whole tool's work is absent.

## Edge cases / pitfalls
- A partial import is more dangerous than a total one; count by severity, since parsers often drop the long, complex issues first, which skew severe.
- Keep the Burp export file frozen with the engagement records; regenerating it later from an edited project breaks reproducibility.
- The gate should distinguish not scheduled from scheduled and failed; only the second blocks delivery.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GFu9dFpk-LI4JPgZ_ZmM0Q