Configure CI evidence ingest

Set submission caps, trusted builders, PEMs, keyless OIDC identities, and a pinned Sigstore trust root so pipelines can land attested results as new automated runs.

CI evidence ingest settings live on the Administration → API access page (under CI evidence ingest). Saving them requires an IT Administrator and an electronic signature. Pipelines authenticate with a project-granted API key and submit JSON or report files; each successful submission creates a new automated test run. Optional attestations verify against the trust policy below. A person still records the signed verdict — a CI key cannot. Verification-side detail: CI evidence ingest.

Create the pipeline key

The pipeline needs a named key granted to the project it will write.

Before you start Open Administration → API access. You'll need organization administrator access to manage keys.

  1. Create a key with a name that identifies the pipeline (for example the repo or workflow).
  2. Grant it to at least one project with a project role — every key must have at least one project grant; set an expiry (keys do not live forever).
  3. Copy the full key when it is shown — it appears once.

Result A project-granted key the pipeline can present on each ingest request. See Set up API access.

Set caps and attestation requirement

Caps bound every submission. The attestation checkbox decides whether unsigned payloads are refused.

Before you start Stay on API access, under CI evidence ingest. You need IT Administrator access and an electronic signature ready.

  1. Set max results per submission and max JUnit bytes.
  2. Set keyless limits as needed: max keyless bundle bytes, max certificate chain length, and max transparency log entries.
  3. Enable Require verified DSSE attestation when every submission must carry an attestation that verifies. Leave it off if unsigned automated evidence is allowed.

Result Oversized submissions are refused. When the requirement is on, missing or invalid attestation is refused before a run is created.

Trust builders (every attested submission)

When an attestation is present, its builder id must appear on the trusted builders list — for both PEM and keyless paths.

  1. Add each allowed trusted builder identity (SLSA builder URL). An attestation whose builder id is not listed is refused.

Result Attested submissions cannot arrive from an unknown builder.

Trust PEM keys (key-based attestation)

  1. Upload trusted PEMs for key-based DSSE / Sigstore-bundle verification.

Result Key-attested submissions verify against public keys you listed (and a trusted builder).

Trust keyless identities and the Sigstore root

Keyless verification matches OIDC identity against a pinned public-good trust root — the server never fetches TUF at ingest time. Prefer exact subject match; anchored-prefix match is prefix-based, so choose prefixes carefully.

  1. Add a trusted keyless identity: exact OIDC issuer, certificate subject (SAN), match mode (exact or anchored_prefix), and optional project scope (empty means all projects).
  2. Upload a pinned Sigstore trusted_root.json snapshot (public-good only). Set its validity window so signing time must fall inside it. The server stamps SHA-256 of the snapshot.
  3. Save — electronic signature required. Revoking an identity later keeps history for as-of verify.

Result Keyless bundles verify only for identities and a trust root you signed into policy.

Note GitHub private-repository Sigstore is not supported in this build. Attestation (when present) binds to the submitted artifact digest and commit SHA — it does not cryptographically sign the test-result body itself.

Confirm on the new run

After the pipeline submits, open the run the ingest created.

  1. Open the new automated test run for that submission (ingest does not write into a pre-existing run).
  2. Confirm automated evidence shows repo, commit, pipeline, and whether attestation verified by key or keyless.
  3. Record a signed Passed or Failed — a CI key cannot sign the verdict.

Result Trust policy and human accountability meet on one run. See CI evidence ingest.

Where to go next

Was this helpful?