Skip to main content
A finding bundle is a single directory that ships everything needed to reproduce, audit, and trust a scan’s findings — SARIF for tool consumers, PoV scripts that re-trigger the attack, raw transcripts, and a manifest.json of SHA-256 checksums.

When to use this

  • You need an auditable artifact to attach to a CI run, a customer report, or a SOC 2 evidence drawer.
  • A downstream consumer (GHAS, Sonar, your own evidence vault) needs SARIF plus the reproducer that proved each result.
  • A finding needs to survive moving between machines — bundles are content-addressed, so tamper of any file invalidates the manifest.

Generate a bundle

Pass --bundle to any scan invocation. The directory is created on demand.
The bundle directory is named bundle_<scan_id> under the path you pass. You can combine --bundle with --pov-gate to keep only findings whose reproducers re-trigger, and with --critic to add the LLM rubric scorer.

Bundle layout

findings.sarif and manifest.json are always written. pov/ and evidence/ appear only for findings that captured a reproducer or evidence file — an empty bundle is still a valid bundle.

What a manifest looks like

The manifest is canonical (sorted-key) JSON so the bytes are reproducible:
The scan envelope is the smallest set of fields a verifier needs to know which run produced the bundle — full provenance (engine, sub-scores, signatures) lives in the signed JSON report described in Report schema reference.

How redaction works

PoV reproducers and evidence transcripts are the most likely files in the bundle to contain attacker-reflected secrets (the swarm’s whole job is to make the target leak things). The bundle writer routes every file written under pov/ and evidence/ through the same PiiRedactor the SARIF and JSON emitters use, so a credential captured by the attacker is scrubbed before it lands on disk. Redaction is on by default. The SARIF emitter inside the bundle inherits the same setting, so a single bundle never mixes scrubbed and unscrubbed output.

How to verify a bundle

Recompute the checksums and compare against the manifest. Any mismatch means a file was modified, replaced, or truncated after the bundle was written.
Expected output for an untampered bundle:
For provenance (who produced the scan), pair the bundle with the signed JSON report and verify it — see Signatures.

How bundles fit the rest of the system

Next step