CI evidence ingest

Land pipeline results as a new automated test run — JSON, JUnit, xUnit, or TRX, with optional PEM or keyless Sigstore attestation — then promote to a signed verdict.

CI evidence ingest is how a continuous-integration pipeline records verification in the product. The pipeline authenticates with a project-granted API key and submits results (JSON, or JUnit / xUnit / TRX). Each successful submission creates a new test run with status automated — it does not append to an existing human run. Optional attestations are verified against trust policy you configure in Administration. Automated results are never an approved Passed/Failed; a person must open that run and record a signed verdict. A CI API key cannot promote or sign a verdict.

Why a new run per submission

Human execution and pipeline ingest share the same run and result models, but ingest always creates its own run for that submission. Provenance and (when present) attestation bind to that run. Ingested automated evidence on a run is immutable — later CI submissions do not rewrite it; they create another run.

What the pipeline submits

A project-granted API key authenticates each request (every key must be granted to at least one project, with a role per grant). The body is structured results or a report file. Org/project caps bound how large a submission may be (result count, JUnit bytes, and — for keyless — bundle size, certificate-chain length, and transparency-log entries).

Provenance on the submission includes an artifact digest and commit SHA the attestation (when present) must match. An idempotency key prevents silent double-accept of the same submission.

Optional attestations verify that a trusted builder (and, for keyless, a trusted OIDC identity) attested that artifact digest and commit — not that the test-result payload itself is cryptographically signed. They verify in two cryptographic styles:

  • Trusted PEMs — DSSE envelope or Sigstore bundle checked against public keys you uploaded
  • Keyless — OIDC certificate SAN + exact issuer against a pinned public-good Sigstore trust root

In both styles, a non-empty trusted builders allow-list is required when an attestation is present: the attestation’s builder id must be listed. Keyless additionally requires a matching identity and a pinned trust root. Attestation is optional unless Require verified DSSE attestation is enabled (org or project); when required, missing or invalid attestation refuses the submission. GitHub private-repository Sigstore is not supported in this build — public-good only. Ingest verifies offline against the pinned root and never fetches TUF.

Caps, builders, PEMs, keyless identities, and trust roots are saved under Administration → API access (CI evidence ingest) by an IT Administrator, with the same electronic-signature ceremony as other sensitive admin writes. Field reference and steps: API access and Configure CI evidence ingest.

What you see on the run

A successful ingest creates the run, writes automated results, and keeps pipeline provenance (repository, commit, pipeline reference, tool). When an attestation verifies, the run shows whether it verified by key or keyless. For keyless, that includes the OIDC issuer, certificate subject, transparency-log index, and trust-root fingerprint.

Automated results are stored as automated, never as Passed. They are visible on the run and counted in automated buckets. Case Pass Rate and the Execution Report skip automated when picking each case’s latest result, so a newer CI ingest does not knock a signed Passed/Failed/Blocked out of those views. Treat automated output as pipeline evidence — not as approved coverage — until a person signs.

Promote automated evidence to a signed verdict

Ingest records what the pipeline submitted. Promotion is the human act that accepts it.

Before you start Open the new test run created by the CI submission. Confirm automated evidence and provenance look right.

  1. Open that run and review the automated results and provenance (repo, commit, pipeline, attestation method).
  2. For each case that should count as verified, record a signed Passed or Failed (or other human verdict) — the same e-signature ceremony as a manual run. A CI key cannot do this.
  3. On a failure, raise a Defect from the case or step so the finding stays linked.

Result The run carries both pipeline provenance and a person-attributable verdict.

Note When attestation is required by policy, promotion can also be refused until a verified attestation is present on the run.

Where to go next

Was this helpful?