Choose a signer
CI/lock supports nine signer providers. This guide is the decision tree, pick the path that matches your environment, then jump to the relevant config detail.
Set up a supported level
The exact CI/lock configuration, and the verify command that proves it, for every Supported cell in the support matrix.
Store attestations in Archivista
Archivista is the searchable evidence store CI/lock integrates with by default. This guide covers how to configure CI/lock to push signed attestations to it, and how to retrieve them later.
Verify in a release gate
This guide is the operational counterpart to the release promotion gate tutorial. The tutorial shows you a worked example. This guide covers the design decisions you'll hit when wiring it into a real production environment.
Add a custom attestor
When the 30+ attestors in the default cilock binary don't capture what you need, write your own. This guide walks through the rookery attestation.Attestor interface, the lifecycle hooks, and how to ship a custom attestor as a Go module that downstream binaries can blank-import.
Build a custom CI/lock
CI/lock is open source and standards-based. Its evidence is a signed DSSE envelope containing an in-toto Statement, so you can fork CI/lock, audit it, and build a distribution for your environment.
Verify a specific file
You have a binary digest (or any single artifact hash) and you want to know: was this file produced by a build I trust? This guide walks the v0.3 verifier flow — what the user runs, what the verifier finds, what cross-checks it does, and what causes pass or fail.
High-assurance attestation
For release builds where "the attestation is complete or it doesn't ship,"
Countersign an attestation
A countersigned attestation is one DSSE envelope with two or more signatures over the same payload. The usual shape is a CI job that signs with its short-lived platform certificate (keyless Fulcio, bound to the job's identity) and a key your organization controls, such as an AWS KMS key, that adds its own signature. A policy can then require both, so neither the CI identity nor the key alone is enough to produce evidence that passes.