EVIDENCE PACKS · GRC ENGINEERING

The best GRC teams already work like engineers.

Evidence Packs give them the tooling to match: live system configuration turned into signed, verifiable files so audit readiness stops being a scramble and starts being infrastructure you build once and run forever.

New to engineering—or ready to level up?

These are the building blocks you need to ship trusted evidence. Start with a system your team already checks by hand.

See how to get started

$ brew install locktivity/tap/epack

$ epack new my-collector

$ epack build evidence.epack posture.json --stream myorg/security

$ epack sign evidence.epack

# Sigstore, no keys to manage

THE CORE PREMISE

Compliance is the outcome. Signed evidence is the primitive.

Not a platform. Not a portal. Just a file format—open, inspectable, and yours to keep. Everything else on this page is what you can build once you stop treating evidence as a once-a-year fire drill.

MANIFEST

Every artifact, fingerprinted

Each pack ships a manifest listing every file with a SHA-256 hash—so nothing gets swapped, edited, or quietly re-exported after the fact.

ATTESTATION

Signed with Sigstore, not a login

Keyless signing tied to a GitHub, Google, or Microsoft identity. Anyone can confirm who created a pack and that it hasn’t changed—no vendor tooling required.

STREAMS

One collector, many audiences

Route the same underlying data into a public stream, an auditor stream, and an internal stream—without collecting it three separate times.

EVIDENCE, OPERATIONALIZED

Same collectors, same signed packs powering multiple workflows.

You don’t stand up separate infrastructure for each of these. You point the evidence you’re already collecting at a different problem.

Questionnaire defense → Evidence-backed automation

Turn a stale question bank into responses driven by live .epack state. Every answer becomes an assertion backed by a signature, not a sentence someone typed once and forgot to update.

Customer audits → Zero-touch review rooms

Publish scoped, live evidence streams into a secure review room. Buyers inspect portable, Sigstore-signed artifacts self-service—without pulling your engineers into another walkthrough call.

Customer trust → Continuous proof

A trust center where the green checkmarks mean something, because each one traces back to a signed pack a visitor can verify themselves—not a badge someone renews once a year.

Audits without the scramble → Audit-ready as a state

Collectors run on a schedule and flag drift the day it happens—not the week before an audit, when it’s too late to fix quietly. When the auditor asks, you publish. You don’t go looking.

Access reviews, unlocked → Continuous access monitoring

Run a one-off access review, or move to continuous monitoring—either way, know who has access to what, every day, and get alerted the moment that changes.

What’s your use case?

The opportunities are endless—find yours, then point a collector at it.

See how a collector works

DON’T TAKE OUR WORD FOR IT

Auditors shouldn’t have to trust your evidence. They should be able to check it.

Most “verified” evidence just means someone trusts the vendor who produced it. A signed pack flips that: the auditor—or an AI agent working on their behalf—verifies the file directly, with open tooling, without asking you for anything else.

epack verify

Checks the manifest hashes and the Sigstore signature against public transparency logs—no Locktivity account, no vendor API key, no phone call to confirm authenticity. The same command works whether the reviewer is a human auditor, an internal security engineer, or an MCP-connected agent doing a first-pass access review.

A WINDOW, NOT A DATA REQUEST

Give customers something to check, not something to ask for.

When a prospect’s security team asks “how do we know your MFA policy is actually enforced,” most vendors respond with a shared drive of PDFs. You can respond with a live page they can refresh—and a file they can independently verify if they want to go deeper.

Route your public-facing collectors into a trust stream and point customers at it directly. It’s a small thing in a sales cycle, but it’s a real one: competitors selling the same platform are still asking security reviewers to wait for a questionnaire response. You’re handing them a link that’s already current.

It’s the same collector you already built for your own audit—just pointed at a different stream.

$ epack build trust.epack posture.json --stream myorg/trust

$ epack sign trust.epack

# same collector, public-safe fields only

# customers verify it themselves, anytime

BUILD YOUR OWN COLLECTOR

If your platform isn’t in the registry yet, that’s the job.

Every collector currently in registry.epack.dev: for Okta, AWS, GitHub, Google Workspace, and dozens more exists because a GRC or security engineer got tired of pulling the same report by hand and wrote code instead. It’s a four-step loop.

01

Install the tooling

The epack CLI ships via Homebrew or as a Go module - no separate agent or daemon to run.

$ brew install locktivity/tap/epack
# or
go install -tags components github.com/locktivity/epack/cmd/epack@v0.3.0

02

Scaffold the collector

Generates the project layout and the epack.yaml manifest your build step will fill in.

$ epack new my-collector && cd my-collector

03

Write the extraction logic

Authenticate to the target system’s admin API with a scoped, read-only credential, and shape the response into a plain JSON payload. This is the only part that’s specific to your platform—everything downstream is standard.

04

Build, sign, verify

Package the JSON into a pack, sign it, and confirm the signature checks out before anyone else sees it.

$ epack build my-evidence.epack posture.json --stream myorg/security
$ epack sign my-evidence.epack
$ epack verify my-evidence.epack

OPEN SOURCE PAYS YOU BACK

Ship a collector, and it stops being just yours.

The registry isn’t a marketing page, it’s a shared toolchain. The Okta collector you’d otherwise write from scratch may already exist because another GRC engineer, at another company, needed exactly what you need and published it to registry.epack.dev. That’s the deal: publish the collector you write, and the next one you need might already be waiting for you.

Contributing back is also the fastest way to build a public track record as a GRC engineer. Code in an open registry is a portfolio in a way a Q&A bank never was.

Before you build

Check registry.epack.dev - collectors and remotes for the major identity, cloud, and SaaS platforms are already published there. When you build something new, the CLI’s remote tooling handles versioning and access control for publishing it back.

NEW TO COMPLIANCE ENGINEERING?

You don’t need ten years of audit or engineering experience to have real impact here.

If you’re a GRC analyst who’s picked up some scripting, or an engineer who just landed on a security team, this is one of the most direct paths to shipping something other people rely on. The collectors, the CLI, and the open spec are the building blocks - you don’t have to invent the format, just point it at a system that matters.

Locktivity runs free, hands-on training for GRC analysts and security engineers who want to build and maintain collectors on the open standard, no software background required to start, and no cost to join. The best first project is usually the tool your own team already checks manually.

ONE COLLECTOR, THREE STREAMS

You decide what each audience sees. The underlying data stays the same.

A stream is just a named, scoped destination for a pack. Most teams end up with roughly three, though nothing about the format limits you to exactly that many.

Trust / public

Prospects, customers, sales

Pass/fail summaries - MFA enforced, encryption on, no named individuals or raw logs.

Audit

SOC 2 / ISO 27001 / NIST reviewers

Point-in-time configuration snapshots, retention settings, admin rosters - no session tokens or raw log dumps.

Internal

Security & GRC engineers

The full raw API response, for root-cause triage when something actually drifts.

FREQUENTLY ASKED

The questions engineers actually ask before they build one.

What is an Evidence Pack, exactly?

Read

Will auditors actually accept a signed pack instead of screenshots?

Read

We don’t have engineers who write collectors. Now what?

Read

Does this replace our GRC platform?

Read

GET STARTED

Your first signed pack is four commands away.

No account required to try it. The spec, the CLI, and the registry are all open.

evidencepack.org · epack.dev · registry.epack.dev · Sigstore-signed

Evidence Pack is an open standard maintained in the open. Built by Locktivity and the community that keeps the registry growing.