● zegit · proves
CRA & compliance
Every release tag can become a CRA Evidence Bundle — a signed, Annex I–mapped, offline-verifiable archive. This is the differentiator: compliance falls out of working well.
The EU Cyber Resilience Act
The CRA — Regulation (EU) 2024/2847 — applies to products with digital elements placed on the Union market. It demands secure-by-design practices, vulnerability handling and coordinated disclosure, incident reporting on tight clocks, conformity assessment with technical documentation, SBOMs and provenance, and a declared support period. CI logs and PR approvals don't satisfy a conformity assessment; zegit produces evidence that does.
Not legal advice — and not yet certified
The bundle format and Annex I mapping currently carry "CRA Expert Review status: PENDING." They have not been reviewed by a notified body or CRA expert and must not be treated as final or as legal advice.
The Evidence Bundle
A bundle is generated on demand by zg evidence bundle for any release tag, and can be uploaded to the Control Plane's Evidence page for browser-side verification. It is a signed ZIP whose top-level manifest.dsse is DSSE-signed with your login certificate and ties everything together. If a commit in the release range has no valid AoV the zip is still written — the manifest records the gap under aov_coverage.missing — but the command exits 20 with ZG_ERR_EVIDENCE_INCOMPLETE, so a pipeline cannot mistake an incomplete bundle for a complete one; --allow-incomplete accepts the gap knowingly.
# produce a bundle for a release, diffed against the previous tag
zg evidence bundle --tag v1.0.0 --prev v0.9.0 --sbom sbom.json --out v1.0.0.zip
# verify it offline against only the Root CA
zg evidence verify-bundle v1.0.0.zip --trust-root /etc/zegit/root.crt --jsonWhat's inside
| Path | Contents |
|---|---|
manifest.dsse | DSSE-signed top-level manifest tying the bundle together. |
tr/tag-request.dsse | The signed Tag Request record. |
tr/approvals/<keyid>.dsse | One signed envelope per approval. |
aovs/<sha>.dsse | Every AoV for every commit since the previous tag. |
policy/ | The effective policy snapshot — ZEGITFILE and .zegit/config.yaml. |
sbom/ | The SBOM you pass with --sbom, verbatim (normalization is a Phase 2 item). |
cra-annex-i.html | A human-readable summary mapped to CRA Annex I, with "your responsibility" slots. |
Vulnerability reports are your input, not bundle output
The bundle ingests the SBOM you pass with --sbom; it does not yet ingest vulnerability scan reports, and the Annex I summary marks vulnerability handling and coordinated disclosure as customer responsibility.
Offline verification
zg evidence verify-bundle re-verifies every signature using only the Root CA and the bundle's own contents — no network call, which is what makes it usable in an air-gapped audit. It reports per-commit AoV coverage, the TR quorum and approvers, and a verdict. Tampering yields ZG_ERR_BUNDLE_TAMPERED or ZG_ERR_SIGNATURE_INVALID and a non-zero exit. Signer certificates are judged on two clocks — strictly at now, then on the accepted-evidence clock — so a bundle for a release older than the signers' short-lived leaves still verifies; revocation is always judged live.
Archive the pair
Store the bundle ZIP and the Root CA certificate together. That pair is self-contained: it verifies years later with no live infrastructure.
Runner image tiers
The honest gap in a v1 AoV — that it doesn't prove the validation executed as claimed — is closed progressively by attested runner images:
| Tier | What it adds | Status |
|---|---|---|
| Tier 1 · Community | Signed image + SBOM + baseline scan. | planned |
| Tier 2 · Verified | Hardening, patch SLA, reproducible inputs, runner-signed AoVs. | phase 2 |
| Tier 3 · Assessed | Notified-body assessment. | phase 3 |
What ships today on the release side: every release archive on github.com/zegit-zoo/zg carries an SPDX SBOM, and the release's checksums file is signed once by the Control Plane's artifact key (releases up to v0.0.133 were keyless-signed on GitHub Actions); container images are signed with the Control Plane's image key and re-verified weekly in the reference deployment. Dedicated runner images for customer validation pipelines are not yet published — validation runs locally or on runners you provision.
SOC 2
SOC 2 is a later phase (Type I, then Type II). zegit builds SOC-friendly controls from day one but makes no early audit claim.
What zegit publishes as a manufacturer
The obligations zegit carries for its own software, so you can check them the way an auditor would:
| Obligation | Where |
|---|---|
| Vulnerability reporting | security [at] zegit.io, human-read; machine-readable security.txt (RFC 9116) with an OpenPGP key. Acknowledgement within 3 business days, triage within 10; high/critical fixes target 30 days, others 90; coordinated disclosure at fix release. No bug bounty. |
| Support period | 5 years per component line; the pre-1.0 line is supported until 2031-06-30 or v1.0 + 12 months, whichever is later. Security fixes ship for the latest release. |
| Update channel | zg update against GitHub Releases, signature-verified before install; advisories in the release notes and SECURITY-ADVISORIES.md. |
| CRA Annex I applicability | All thirteen Part I(2) requirements assessed as applicable, each with an implementation pointer and open items, in the source repository's CRA-ANNEX-I-APPLICABILITY.md — a draft pending expert review. |
Authoritative reference, generated from the component repos. Spot something stale? Tell us.