What CI/lock is built for, tested against, and known to interoperate with.

Sources: rookery/cilock/go.mod, rookery/.github/workflows/release.yml, rookery/cilock/cmd/cilock/main.go.

Toolchain

Released platforms

The official rookery release pipeline produces static binaries for:

macOS and Windows binaries are not OS code-signed (no Apple Developer ID or notarization, no Authenticode); see Verify the cilock binary.

Container image

The release pipeline publishes binaries only: it builds no container image and creates no GitHub Release (release.yml). Earlier versions of this page listed a ghcr.io/aflock-ai/cilock image; the current pipeline does not build or update it. To run CI/lock in a container, install the release binary into your own image.

CI platforms

Tested integrations from the cilock-action ecosystem:

Signers

The default cilock binary blank-imports three signer providers, file, fulcio and piv (verified from cilock/cmd/cilock/main.go):

The default binary links no KMS backend, so it registers no --signer-kms-* or --verifier-kms-* flag; passing one is an unknown-flag error. A build that imports plugins/signers/kms/{aws,gcp,azure} or plugins/signers/vault-transit registers them, and a ref whose scheme that build does not link errors with no kms provider found. The other "builder opt-in" signers likewise exist as Go modules in rookery but aren't blank-imported by default. Add the import to cilock/cmd/cilock/main.go (or use rookery-builder --with …) and rebuild — see build a custom CI/lock.

Timestamp authorities

RFC 3161 compatible TSAs. Tested against:

• The platform TSA (derived from platform-url; the cilock-action default when timestamp-servers is not set)
• Sigstore TSA (Sigstore-operated public TSA)
• Self-hosted TSAs reachable over HTTPS

URL pattern: TSAs are passed via --timestamp-servers <url> (repeatable; -t). There is no config file: it was removed, so flags (or the action's timestamp-servers input) are the only way to set them.

Evidence storage

Witness compatibility

CI/lock shares witness's DSSE + in-toto envelope format, but interop is asymmetric — witness → CI/lock, not fully the reverse:

• CI/lock attestation type URLs use the https://aflock.ai/attestations/<name>/v0.1 namespace.
• Legacy witness URLs (https://witness.dev/attestations/<name>/v0.1) are accepted via aliases registered in attestation/legacy.go, called from main.go at startup via attestation.RegisterLegacyAliases().
• Witness-signed policies (DSSE payload type https://witness.testifysec.com/policy/v0.1) work with cilock verify.
• Witness-produced attestations verify under cilock verify.
• The reverse holds only for the shared base attestors. CI/lock's v0.3 Merkle-tree product/material attestations (tree:products root + inline leaves), standalone inclusion proofs, and trace records use predicates and verification logic witness doesn't implement, so witness verify cannot validate most CI/lock attestations.

Predicate types in scope

Version pinning recommendations

What's not covered

• Blocking network egress. With --trace, CI/lock records network activity (connections, DNS lookups, TLS SNI hostnames) so a policy can fail the step, but it does not block traffic while the step runs. Pair with StepSecurity Harden-Runner for inline blocking.
• Developer laptop or production server protection. CI/lock operates in CI/CD only.
• Windows attestor coverage. The released Windows binary has no omnitrail attestor and no --trace backend (--trace fails the run), so a Windows runner cannot produce evidence that needs either.