Auto-detection and default attestors

cilock run -- <command> tries to do the right thing without a wall of flags. Two mechanisms make that work: a small always-on default set, and detector-driven auto-attachment.

The default attestor set

Some attestors always run and are not controlled by -a:

• product and material: the input/output Merkle trees. Always on. These two are the only attestors --no-default-attestor can drop, and dropping both is a fatal error.
• command-run: the wrapped argv, exit code, and stdio. It runs whenever cilock run wraps a command, and --no-default-attestor cannot drop it.

Three more are the default value of -a, so they're replaced if you pass your own -a:

• environment: OS, arch, working dir, (obfuscated) env vars.
• git: commit, branch, remotes, tag.
• platform: the run's binding to a logged-in TestifySec platform tenant. It is dropped from the defaults when there is no platform session (offline, not logged in, or the platform disabled). An explicit -a platform is never dropped and fails the run when it cannot be produced.

So a bare cilock run -- go build ./... already yields environment + git + command-run + material + product, signed, plus platform when you are logged in.

--workload: when detection runs

cilock can inspect the workspace (and the wrapped command's argv) and attach the attestors that match — go-build for a go build, git for a .git/ directory, sbom/sarif for a tool that emits those formats, and so on. Whether that detection runs depends on --workload (default auto) and whether you passed -a:

The rule in one sentence: detection runs by default only when you don't pass -a; passing -a means "this exact set" unless you also say --workload auto. This is so cilock run -a sarif -- … means what you wrote, while the zero-config path stays smart.

Detection rules live in the catalog (detector.yaml per tool), so the set of things CI/lock can auto-attach is exactly what cilock tools list shows. See the detector catalog for every rule, and step categories for how a detected tool also infers --step.

--validate-only: dry-run the plan

Before committing a CI/lock invocation to CI, run it with --validate-only:

cilock run --validate-only -- go build ./...

It performs the pre-flight workload + tool-availability checks, prints the planned attestor set and any warnings, and exits without running your command. Use it to confirm detection picks what you expect.

See also

• How CI/lock captures files — walk vs trace vs fanotify (separate from which attestors run)
• Step categories — the lexicon and --step inference
• Tools / detector catalog — every auto-detection rule
• CLI reference — --workload, --validate-only, --no-default-attestor