Evidence Bundles
The current External Attack Surface Review package boundary, reconstructable manifest references, and the separation between producer output and independent verification.
An evidence bundle is the portable package around a receipt. The package carries the bytes needed to reconstruct evidence references and run checks that a receipt-only surface cannot perform.
1. External Attack Surface Review package
The current proof-engine delivery contract uses this layout:
| Path | Role |
|---|---|
README.md | Human entry point and package limits |
package_index.json | Package file inventory |
receipt.json | Canonical witnessops.receipt.v0 profiled receipt |
evidence_manifest.json | Artifact IDs, source metadata, and hashes |
verification_result.json | Producer-side build and comparison check output |
report.md | Human-readable bounded review result |
public_key.json | Included when the package is signed |
evidence/ | Staged source artifacts named by real manifest artifact IDs |
normalized/ | Deterministically normalized records used for comparison |
results/comparison_result.json | Claim-by-claim comparison output |
This is not the public /verify request shape. /verify accepts one supported receipt JSON object and rejects bundles, evidence, keys, registries, policies, and verifier results supplied by the caller.
2. Reconstructable evidence references
The bounded OffSec adapter stages actual source files and assigns each staged source artifact the exact future manifest artifact ID in the form offsec_<24 lowercase hex>.
The ID is deterministically derived from the source run identity, normalized source path, and source SHA-256. It is therefore a stable manifest reference, not a sequential UI label or a replacement for the artifact digest.
A reviewer reconstructs a claim reference by:
- locating the ID in
evidence_manifest.json - locating the staged file identified by that manifest entry
- recomputing the file digest
- comparing it with the manifest digest
- evaluating whether the artifact supports the recorded claim status
Receipt-only /verify performs none of steps 1–5 because the manifest and files are not supplied.
3. Producer output is not independent verification
verification_result.json is emitted by the proof-engine build. It preserves deterministic producer-side checks and unresolved states. It does not become independent merely because it is named “verification result.”
An independent verifier must separately receive the package and explicit trust inputs, recompute the relevant bytes, validate the receipt signature and signer policy, and emit its own result.
The canonical full verifier is currently an internal implementation without a supported public distribution. Public docs do not treat the producer result or a web sample result as a substitute for that run.
4. Required trust inputs
A complete package may contain a public key, but package-contained key material is not automatically trusted. Production acceptance also requires a server- or reviewer-owned policy that pins the registry revision and hash, authorizes the key ID and usage, checks validity and revocation, and records custody approval.
When required evidence or trust inputs are missing, the correct outcome is incomplete or indeterminate, not an upgraded pass.
5. Other package profiles
Older documentation described a universal CLAIM.json, DSSE envelope, RFC 3161 token, NDJSON receipt chain, and trust-directory layout. Those artifacts may exist in retained, compatibility, or design lanes, but they are not the canonical External Attack Surface Review package and are not required inputs to the current public receipt adapter.
If a package declares DSSE, RFC 3161, in-toto, continuity, or transparency layers, verify the matching artifacts with tooling that implements that exact profile. Do not infer those layers from filenames or receipt JSON alone.
6. Limits
A complete, intact package still cannot establish everything about original capture. It does not by itself prove source-tool correctness, uncompromised capture hosts, correct human judgment, or completeness outside declared scope.
7. Next-page handoff
Read Verification for the public and internal path separation and Receipt Specification for the exact product profile.