The Witness GitLab component was introduced to help teams capture attestations from GitLab CI/CD jobs. This article remains at its original URL as a record of that 2024 release; the missing YAML from its earlier migration is no longer presented as a runnable setup guide.
Why do you need attestations?
A scan result needs to be associated with the source or artifact that was scanned. A signed statement can carry that association across systems, along with the producer identity and the recorded result.
That makes evidence easier to verify and reuse. It does not guarantee that the scan was comprehensive or that the producer reported honestly.
How to produce attestations with Witness and GitLab CI/CD
Use the maintained Witness documentation and the GitLab CI/CD component documentation when selecting a component and configuring its inputs. Pin a reviewed component revision and Witness release rather than relying on a moving tag.
Keep the build or test command inside the observed job. Retain the output and signed evidence as job artifacts, then verify the exact output before the downstream action that relies on it. A successful evidence upload is not a successful policy evaluation.
Generating attestations with Witness and Sigstore in GitLab CI/CD
The signing setup must match the identity issuer and services available to the runner. Public Sigstore services and a private GitLab installation are not automatically interchangeable. Follow the Witness keyless-signing guide or its KMS signer guide for the selected release.
Constrain the signer identity and issuer in verification policy. Do not upload sensitive evidence to a public service without deciding whether it belongs there.
What does the attestation look like?
The available fields depend on the configured attestors. Look for the artifact digests, step name, producer identity, and results required by your policy. A pipeline URL helps a reviewer navigate to a run; the URL alone does not authenticate the producer or prove execution.
Test the policy against missing evidence, a failed result, a changed artifact, and an unexpected signer. Make sure the downstream decision rejects those cases.
Using CI/lock on a runner today
CI/lock captures work on your compute or hosted infrastructure. Start with your first attestation and check the environment support matrix. Running a command on a GitLab runner does not imply parity with every historical Witness component input.
Get in touch
For a workflow spanning multiple repositories, explore the TestifySec platform or talk to us about the gates and evidence you need.
