I helped build Witness and contributed to the CNCF’s supply-chain guidance. That work taught me to distinguish two questions: what did a workflow intend to run, and what evidence do we have about the work it actually performed?
The March 2026 Trivy and LiteLLM incidents made that distinction concrete. Aqua’s incident report describes overwritten action tags carrying malicious code. LiteLLM’s incident report describes compromised package releases and startup behavior. The details matter; neither incident justifies a blanket claim that nobody could investigate what happened.
A workflow file describes intended execution. A trace can add observations within its capture boundary. A signed statement identifies a producer and binds the recorded claim to its subject. We need to know which of those we are looking at.
The same gap, now with agents
An agent can edit source code, change a workflow, and report that its tests passed. A gate should not accept that report solely because it is fluent or signed. It needs requirements controlled outside the work being evaluated, evidence bound to the relevant change, and a producer identity the organization has chosen to trust.
Protecting that producer matters. If the agent can replace the test, forge the result, or use the trusted signing authority to sign arbitrary statements, a signature does not repair the boundary.
What CI/lock actually does
CI/lock captures configured work on your compute or hosted infrastructure and creates attestations that a verifier can inspect. The recorded fields depend on the selected attestors, capture backend, operating system, and permissions. It does not promise to observe every filesystem read or network action in every environment.
Use Your first attestation for the maintained commands. Inspect the record, verify its signature and subject, and check the producer against your policy. Decoding a payload is not signature verification.
Short-lived signing credentials reduce credential lifetime. They still need protection while valid. Policy signing, policy publication, repository activation, evidence production, and push signing are separate roles; one of those actions does not prove the others occurred.
Built for how we ship now
The workflow starts where the work happens: a developer machine, an agent workspace, or CI. Pushgate checks the required evidence at the Git push boundary. The platform manages the gates, policies, identities, and evidence across repositories.
A technical-control mapping can reuse a suitable result for another review. That requires an explicit mapping and a test that addresses the control’s scope; the presence of an attestation does not automatically satisfy a framework.
The original article also overstated SLSA assurance. A signed build is not automatically Build L3. Review the support matrix and the actual isolation between the build and its signing authority.
If you’re already running Witness
Witness and CI/lock share an in-toto attestation lineage. That gives teams familiar formats and concepts, but it is not a guarantee that every predicate, key type, identity policy, or version verifies unchanged in both directions.
Keep existing evidence. Test representative envelopes with the verifier and policy versions you plan to use. Follow the Witness project documentation for Witness-specific operations and the CI/lock guides for CI/lock.
Try it on your next build
Choose one existing build or test. Capture it, inspect what was recorded, and verify the exact subject. Then try a missing result, a changed artifact, and an untrusted producer before relying on the decision.
Start with one result. Use the trust model to decide what that result establishes.