Scanner Output Formats: SARIF, Nessus, Burp, CSV, and JSON

Why format choice matters

A finding survives delivery only if the evidence behind it survives the import. A scanner that produced a clean reproduction at scan time loses that signal if the export drops the request/response pair or the plugin output. The downstream cost is a tester redoing the proof under engagement pressure or a finding shipping without the verification trail an auditor can follow. The format choice sits at the boundary between detection and delivery; treating it as an afterthought collapses the rest of the workflow into manual recovery.

Three structural realities shape format choice. First, every scanner class emits a native format that captures its detection signal best. Second, every consumer (a findings record, a SIEM, a ticketing system) reads a subset of those formats and maps them to its own schema. Third, the gap between native fidelity and consumer schema is where evidence drops out. The discipline is choosing the format that minimises that gap for each tool, not standardising every tool through one lossy intermediate.

The major scanner output formats

Five formats cover the majority of scanner output a programme will see. The table below lists what each format encodes natively and where each one tends to lose information when used outside its origin tool.

None of the formats is strictly better than the others. SARIF wins for code analysis because the schema was designed for code locations and rule traces. Nessus XML wins for network output because it carries plugin output that no general format standardises. Burp XML wins for web application findings because it preserves the request/response pair. CSV wins on universality and loses on fidelity. The right format is the producer’s richest format that the consumer can read.

SARIF: when to use it and when not

SARIF is the OASIS standard for static analysis output. It carries enough structure to represent the rule that fired, the file and line where the issue lives, the data flow that triggered detection, the fingerprint that identifies the issue across runs, and the suppression history. Tools that emit SARIF natively include Semgrep, CodeQL, many ESLint security plugins, and a growing set of SCA scanners.

Nessus and Burp Suite native exports

Network and web application scanners are the two cases where native formats most consistently outperform any general intermediate. The discipline is using the native export at import time and converting only when the consumer cannot read the native format directly.

CSV imports without silent loss

CSV remains the format of last resort for tools without a structured export, for handovers between teams that do not share tooling, and for ad-hoc data captured in spreadsheets. The discipline is treating CSV as a structured handover with an explicit column convention rather than as an opaque dump that the importer hopes to interpret.

• Document the column convention up front: which column maps to title, severity, asset, trigger, evidence, fix location, and tool-native identifier. The convention lives alongside the engagement, not inside the importer.
• Normalise severity strings: Critical/High/Medium/Low maps to a numeric scale at import. The mapping table is recorded so that downstream severity comparisons remain anchored to verified thresholds rather than tool-local language.
• Preserve multi-line evidence: wrap fields that contain line breaks in quotes per the CSV spec, or store evidence in a separate file referenced by row. The failure mode is evidence cells getting truncated at the first newline.
• Fall through to manual review: rows that the column convention cannot resolve land as drafts pending manual triage. The alternative is silent coercion that ships malformed findings into the record.
• Keep the source CSV attached to the import: even after the rows are parsed and merged into findings, the original file stays attached so the audit trail walks back to the source export.

CSV is not the enemy. CSV without a column convention is. The discipline that turns a CSV into a defensible import is documented, reviewed, and reproducible mapping; the same discipline that any other format earns by design.

Planning format choice across an engagement

Format decisions made under engagement pressure tend to default to CSV because it is the one format every tool can produce and every consumer can open. That default is the source of most evidence loss in scanner imports. Planning the import path before the scan runs is what avoids the default.

Common format anti-patterns

Three patterns recur in programmes that ship scanner output through ad-hoc imports. Each one creates a recoverable failure mode that compounds across the engagement until someone fixes the input convention rather than the output.

• CSV-only by default: every tool exports CSV regardless of what richer format the tool offers, because CSV is universal. The evidence lost at export is not recoverable; the importer cannot reconstruct what the CSV did not encode.
• Format pinned to the wrong tool: SARIF forced on a Nessus export, or Nessus XML forced on a SAST tool. The schema cannot represent the evidence; the import succeeds but the finding ships without the fields the consumer needs.
• Lossy conversion at import: the importer normalises every format to a common intermediate that drops fields the original format carried. The intermediate looks clean; the finding has lost the evidence that made it reproducible.

The shared root cause is treating import as a step that has to succeed rather than as a step that has to preserve. Imports that succeed without preservation produce findings that fail at delivery; imports that preserve evidence produce findings that survive audit.

How SecPortal handles format imports

SecPortal accepts scanner output as draft findings against the engagement. Native imports parse Nessus XML and Burp Suite exports for plugin or issue identifier, severity, asset, trigger, and per-finding evidence. CSV imports use a column-mapping step that resolves each column to a finding field, with a fall-through to manual review for rows the convention cannot resolve. Each draft surfaces in the workspace for triage rather than landing as a finished finding.

The scanner result triage workflow covers the import-to-triage cycle that turns raw scanner output into a workflow-ready record. The bulk finding import workflow covers high-volume cases where output crosses tools and formats. The findings management feature keeps the originating format and tool identifier attached to the consolidated record so the audit trail walks back to the source export.

Once the formats are imported, the next discipline is collapsing duplicates without losing evidence. The scanner output deduplication guide covers how to merge findings across formats and tools while preserving the per-source evidence each export carried. For the upstream coverage envelope, the scanner coverage and limits guide covers what each scanner class actually finds and where formats start losing information. For the triage discipline that runs alongside import, the scanner false positives guide covers how to validate findings before they leave the draft state.

The branded client portal surfaces the consolidated findings to the client. Raw scanner output stays in the workspace; the report represents verified findings backed by the per-format evidence each import preserved.

An import-ready format checklist

Vulnerability classes where format choice bites hardest

Some classes lose more evidence under format choices than others, because the proof depends on a request, a packet, or a code path that not every format can carry. The pages below cover the classes most often degraded by lossy exports.

• SQL injection: DAST detection depends on request/response evidence; CSV exports drop the proof.
• Cross-site scripting: reflected and stored XSS evidence is the request/response pair; native Burp exports preserve it where CSV does not.
• Vulnerable dependencies: SCA findings carry package, version, advisory, and file references; SARIF preserves the location chain that CSV flattens.
• TLS/SSL misconfiguration: Nessus plugin output records the cipher and certificate detail; CSV exports often keep only the title.
• Missing security headers: header detection is high volume; native exports cluster per asset, while CSV fragments them across rows.

For the analytical view of how unverified or evidence-thin findings drive retest volume, the pentest retest economics research covers how the input fidelity compounds across the engagement. For severity scoring on imported findings, the severity calibration research covers how to anchor scores to verified evidence rather than to whichever export preserved the most.

Scope and limitations

Format choice cannot recover evidence the producer never captured. A scanner that does not record request/response data cannot produce a Burp-equivalent export regardless of the wrapper. A scanner that does not maintain stable rule identifiers cannot produce SARIF that survives version changes. The leverage point is choosing tools whose native output already records the evidence the workflow needs and then preserving that evidence at export.

Formats also drift across tool versions. A SARIF schema field that ships in version N may be missing in version N+1; a Nessus plugin output structure may change between major releases. The pragmatic discipline is documenting the producer version alongside the format choice, so that a future reader of the export knows which schema variant generated the file.

For the operational step that turns these formats into structured findings on the engagement record, the guide to importing third-party scanner results covers the parsers for Nessus, Burp Suite, and CSV, the severity normalisation across scanner scales, the CSV column mapping decision, and the post-import triage that promotes drafts into canonical findings.

Frequently Asked Questions