Zegit in a nutshell

What it is#

Zegit is a governance gateway that sits in front of your existing Git host and turns every release into an audit-grade evidence bundle aligned to the EU Cyber Resilience Act. Instead of re-running your CI, it verifies signed evidence that validation already ran — under a policy defined in Git, by an identity you can prove.

Governance lives in version control, identity is passkey-backed, and every release produces non-repudiable cryptographic proof of the validation and approval chain. The loop runs end to end today — passkey login, signed validation, gateway enforcement on push, quorum-approved tags, offline-verifiable bundles — and zegit governs its own source repository with it. What is still roadmap (GitHub.com enforcement, attested build runners, the expert-reviewed Annex I mapping) this page says plainly.

Know · work · prove#

The platform is three tools that share one evidence vocabulary.

meerkat is the knowledge base your agent can query over MCP, so work starts from what is actually true at your org. mongoose is the agent harness that runs the work — and emits an evidence record bound to the exact git state for every meaningful step. zegit signs, gates, and bundles what happened into proof. Each tool is useful alone; together, the compliance artifact falls out of good engineering instead of being bolted on.

The lifecycle of one change#

A change flows through one chain. You — or an agent in mongoose — write code. zg validate runs your pipeline (lint, tests, security analysis, review agents) and assembles an evidence record bound to the exact commit and tree. The policy engine renders a decision — ALLOW, REQUIRE_REVIEW, or BLOCK.

On ALLOW, the record is signed into an Attestation of Validation and written to refs/zegit/aov/<commit_sha>; a pre-push hook carries it alongside your commits, and the gateway admits only ALLOW. At release, a Tag Request gathers the required approvals — each a fresh passkey touch, on the CLI or in the Control Plane — and finalizes a signed tag; the gateway admits the tag only when the Control Plane confirms quorum for that exact commit. zg evidence bundle then turns the tag into a CRA Evidence Bundle anyone can verify offline.

One record, three envelopes#

The evidence never changes shape. mongoose emits an unsigned record into .zegit/evidence/<run_id>.jsonl — a free local audit trail with zero zegit. A policy engine evaluates it and stamps a decision, making it validated, still unsigned. zegit wraps that exact same payload in a DSSE signature to make it signed and audit-grade.

Each hop adds metadata; none reshapes the payload. The escalation is the upgrade path: free unsigned evidence today, signed proof when you adopt zegit.

What "proof" actually means#

A signed AoV is a DSSE envelope wrapping an in-toto Statement — standard, interoperable formats, not a proprietary blob. It is verifiable offline: zg evidence verify-bundle checks signatures, the certificate chain to the root, and the git-state binding with no network call.

With attested runners#

Today the developer signs the AoV, so it proves who asserted a validation, not that the pipeline actually ran — a developer could point .zegit/config.yaml at a check that trivially passes and still produce a valid AoV. The fix is to move the signature off the developer and onto a trusted builder.

ZeGit's build runner images — signed OCI images, pinned by digest — are the vehicle. When validation runs inside a Tier 2 Verified image, the AoV is signed by the attested runner identity instead of the developer (a runner-signed AoV). Now the decision comes from a known-good, digest-pinned runner the committer can't trivially forge, and a policy can require that protected refs carry one — closing the v1 gap. Tier 3 adds TPM-backed runner attestation and hermetic builds on top.

The CRA payoff#

Because the proof is generated as a byproduct of validating each change, the compliance artifact assembles itself. A bundle ties together every AoV since the last tag, the signed Tag Request and its approvals, the effective policy snapshot, the SBOM you supply, and a human-readable summary mapped to CRA Annex I — the document a compliance officer takes to an auditor.

Bundle assembly, signing, and offline verification work today; a bundle with a commit that lacks a valid AoV is written but fails with exit 20, so a pipeline cannot mistake incomplete for complete. The Annex I mapping exists but has not yet been through CRA-expert review — treat it as a draft, not a certified mapping. Vulnerability scan reports are not yet ingested.