Evidence Pack Specification v1.0

The missing standard for assurance evidence.

Evidence Packs define a consistent way to package assurance evidence into a single ZIP file, so it's easier to send, easier to review, and easier to compare over time.

Not a platform. Not a portal. Just a ZIP you can store anywhere.

Read the Spec CLI & Go SDK →

Built on the same cryptographic infrastructure securing software supply chains worldwide.

No purchase required. It's just a ZIP file with a standard structure and table of contents. Anyone can create or read one.

No broad access. Vendors can publish packs without giving anyone "keys to the kingdom."

No lock-in. Share packs however you already share files. Store them anywhere. Your evidence stays yours.

What it is

Evidence Packs are a standardized "evidence bundle." Instead of every vendor sending assurance evidence in a different shape (portal links, scattered PDFs, spreadsheet attachments), it's packaged the same way every time.

Before

"Every vendor, a different process." PDFs, portals, spreadsheets, screenshots. No consistency to build on.

"Did anything actually change?" No way to compare this year to last year. Every review starts from scratch.

Evidence is hard to trust. Checkmarks with no explanation. Opaque outside-in scans. Low-signal audits optimized for throughput instead of rigor.

Hard to automate. Every review is a custom process. No consistent format to build tooling around.

With Evidence Packs

Same format, every vendor. One request. One ZIP. Watermarked or per-recipient files work too.

Last year vs. this year? Diff two packs and see exactly what changed. No more starting from scratch.

See what informed the assessment. Artifacts are listed in the manifest. You can see what's behind the checkmark. Signatures lock it down: proof of who created it and that nothing changed.

Build tooling around it. Consistent structure means your tools (and AI) can parse every vendor the same way.

What's in a pack

evidence-pack.zip

artifacts/ The actual evidence: audit reports, pentest summaries, compliance docs, configuration exports.

Where this goes

Assurance got stuck chasing collection instead of outcomes. Evidence Packs flips the model: vendors publish their posture on their terms, reviews start with what changed, and teams spend time on judgment instead of logistics. No broad access grants. No surprises from outside-in scans. Rigor becomes visible. Strong security becomes a selling point, not a checkbox.

Inside-out becomes normal. Vendors publish their posture directly, reviewed before it ships. Buyers verify what matters to them, against their standards, not someone else's checklist.

Rigor scales. Diff-first turns review into a focused problem: here's what changed. Thoroughness stops being a bottleneck because you're no longer re-reading the whole world.

Less assembly, more analysis. Teams stop spending cycles assembling evidence and start spending them evaluating it. The work shifts from logistics to decisions.

The path forward

Evidence Packs work with what you have today. But the format is designed for where this is going.

Today

• PDFs, reports, and policy docs packaged consistently
• One format across all vendors. Compare apples to apples.
• Year-over-year comparison: "these files are different"
• Profile validation. Declare what a pack must contain; tooling checks completeness and content.
• Share files however you share files today. Google Drive, Box, your trust center, etc.

As tooling matures

• Machine-readable posture, signed at the source so you know it's real
• Structured data you can query: compare posture across your entire third-party population
• Automated collection, vendor-approved release. Evidence stays current instead of going stale between audits.
• Profile registries. Shared type definitions across organizations; fetch schemas on demand.

The format stays the same. The artifacts inside get richer. Start with documents. Graduate to data.

CLI & SDK

Get started

The spec is open and free. Pick your path.

Pick a path based on your role:

I want to request packs from vendors See exactly what's included and what changed since last year.

I want to share packs with customers One ZIP, one manifest. No more follow-ups asking for "one more file."

I'm an auditor Your signature tied to exactly what you reviewed. Show your work.

I'm building tools One integration unlocks every vendor. Check out the CLI & Go SDK at epack.dev.

Read the spec CLI & Go SDK →

Frequently asked questions

Why do we need Evidence Packs when we have AI?

AI summarizing PDFs is just doing human work faster, not making assurance better. The real opportunity is continuous assurance: pipelines that collect evidence automatically, sign it at the source, and publish updates on a schedule. Evidence Packs make that possible by giving evidence a consistent, machine-readable shape. Reviewers see what changed since last time instead of starting from scratch. AI can help analyze the diff, but the structure is what makes it automatable.

So it's a ZIP and a JSON file. What's the big deal?

Exactly. The format is intentionally simple, but the precision is real: 200+ normative requirements define exactly how to compute digests, sort artifacts, validate paths, and handle edge cases. That rigor is what makes verification and diffing actually repeatable across implementations. Add signatures, and you can prove who created it. Add a pipeline, and evidence stays current instead of going stale between audits.

How is this different from just sharing a folder?

You could compute hashes yourself and store them in a text file. But your vendor does it differently, and the next vendor does it another way. Evidence Packs get everyone speaking the same language: same manifest format, same digest algorithm, same attestation schema. Your tooling works across every vendor without custom glue. And when packs are signed, you know exactly who created the evidence and that nothing changed in transit.

Why can't buyers just hash whatever vendors send today?

They can, but then every buyer invents their own "bundle," renaming files, reorganizing folders, computing hashes differently. That breaks comparability. The manifest defines how to compute hashes (canonical format, sort order, digest algorithm) so every tool gets the same answer. It also carries metadata you can't derive from files alone: which collectors generated each artifact, when they were gathered, and what controls they map to. Signatures prove provenance. Without the manifest, you have files. With it, you have a package any tool can verify the same way.

Does this encourage oversharing sensitive documents?

No. A pack is just a consistent container. Vendors can maintain separate streams for different audiences: a public posture pack, a standard due diligence pack, and a sensitive pack for deeper reviews under NDA. The stream identifier makes it clear which collection a pack belongs to, so teams can share less, more intentionally, and still be verifiable.

Portals provide watermarking, access logs, and revocation. How does a pack handle that?

Those are distribution features, not format features. Evidence Packs defines what gets delivered. You can deliver packs through controlled channels when needed. The epack CLI supports pushing packs to registries with built-in versioning and access control. The artifact stays portable and verifiable regardless of how it's hosted.

What if my vendor won't adopt this?

You can create packs yourself from evidence you already receive. The format is simple enough to build by hand or script. As more buyers ask, vendors will follow. Low friction is how standards spread.

Who benefits from this?

Everyone who doesn't charge to make this more complicated than it needs to be. Security teams who want to stop re-reviewing from scratch. Vendors who'd rather show their actual posture than be graded by opaque outside-in scans. Auditors whose work deserves to be verifiable. Tool builders who want one format instead of a hundred.

How is this different from OSCAL, SAF, SARIF, or other machine-readable security formats?

Evidence Packs solve a different problem: how do you package evidence, prove who created it, and track what changed over time? OSCAL, SARIF, and OHDF define what the data means. Evidence Packs define how you release it. A pack can include any of those formats (plus PDFs or exports) with a manifest that fingerprints every artifact and optional signatures that prove provenance.

How does signing work? Do I need to manage keys?

No long-lived keys to manage. Evidence Packs use Sigstore for keyless signing. Signers authenticate via existing identity providers (GitHub, Google, Microsoft) and receive short-lived certificates. Every signature is recorded in a public transparency log (Rekor), so you can verify who signed and when. The signature bundle is self-contained, so verification works offline without fetching keys from anywhere.

Can I generate packs from CI/CD?

Yes, and this is where it gets powerful. The Sigstore certificate embeds the commit SHA, repository, and workflow path, so the signature proves exactly which code generated the evidence. If your collector is open source, reviewers can view the exact immutable version that ran. No secrets to rotate, no keys to leak. Full transparency into how artifacts were generated, cryptographically tied to the signature.

What goes in the artifacts folder?

Anything that constitutes evidence. PDFs, JSON exports from security tools, compliance reports, configuration snapshots, pentest summaries. The manifest lists each artifact with a digest, so reviewers know exactly what's inside and can detect if anything changed. For machine-readable artifacts, the manifest can include a schema field (like github/branch-protection/v1) so tools know how to interpret the data.

How do I know a pack is legitimate?

Check the attestations. Each attestation includes a signer identity: either an email (for humans) or a workflow URL (for CI/CD). You decide which identities to trust. If a pack from Acme Corp is signed by security@acme.com or their GitHub Actions workflow, and the manifest digest matches, you know it hasn't been tampered with. The transparency log provides non-repudiation: Acme can't deny they signed it.

Initiated by

Locktivity

We built Evidence Packs in the open because portable, verifiable assurance is a problem bigger than any one vendor.

Governance

Get support · About the initiator