API access

API access is how external systems integrate with traceunified programmatically. Access is governed by API keys managed here. The same Administration page embeds CI evidence ingest settings (caps, builders, PEMs, keyless identities, pinned trust root). Key create/revoke is an organization-administrator action; saving CI evidence ingest settings requires an IT Administrator and an electronic signature.

Programmatic access deserves the same governance as human access. A key is a standing grant that can act without a person present, so scoped, expiring, revocable keys keep the machine-to-machine surface as accountable as interactive access.

Creating an API key

You create a key with a name that identifies its purpose, and it’s given a key prefix so you can recognize it later. The full key is shown once, at creation. Every key must be granted to at least one project with a project role — grants are the key’s project membership. Keys have a mandatory expiry. Creating or revoking a key requires an electronic signature.

Using a key

A request authenticates by including its API key, as described in the API documentation linked from this area. Treat keys as secrets. Pipeline evidence submissions use a project-granted key; authorization follows that project’s grant role. Optional attestations are verified against the CI evidence ingest trust policy below.

CI evidence ingest

CI evidence ingest controls which pipeline submissions are accepted. A project-granted API key submits results as JSON or as JUnit / xUnit / TRX. Each successful submission creates a new automated test run (it does not append to an existing run).

Attestations, when present, verify two ways: trusted PEMs (DSSE / Sigstore bundle) or keyless OIDC identities against a pinned public-good Sigstore trust root. In both cases the attestation’s builder id must be on the trusted builders list. Keyless also needs a matching identity (exact issuer + subject match exact or anchored_prefix) and the pinned root. Attestation binds to the submitted artifact digest and commit SHA; it does not cryptographically sign the test-result body. Attestation is optional unless Require verified DSSE attestation is enabled. GitHub private-repository Sigstore is not supported; ingest never fetches TUF.

Submissions land as automated evidence. A person must open the new run and record a signed Passed/Failed — a CI key cannot promote or sign. Walkthroughs: CI evidence ingest and Configure CI evidence ingest.

Caps and attestation requirement

• Max results per submission and max JUnit bytes
• Max keyless bundle bytes, max certificate chain length, and max transparency log entries
• Require verified DSSE attestation — when enabled, every submission must carry an attestation that verifies

Trusted builders

Allow-list of SLSA builder identities. Required for attested submissions on both the PEM and keyless paths.

Trusted PEMs

Public keys for key-based DSSE / Sigstore-bundle verification.

Trusted keyless identities

Exact OIDC issuer plus certificate subject (SAN) with exact or anchored_prefix match. Optional project scope (empty = all projects). Revoke keeps history for as-of verify.

Pinned Sigstore trust root

Upload a trusted_root.json snapshot (public-good only). The server stamps SHA-256. Set validFrom / validUntil so signing time must fall inside the window.

What verified evidence shows on the run

Provenance (repository, commit, pipeline, tool) and whether verification was by key or keyless (issuer, subject, log index, trust-root fingerprint when keyless).

Revoking access

Any key can be revoked, which immediately cuts off that key without affecting others. Revoked keyless identities keep history for as-of verification.

Integration, governed

Named, project-granted, expiring, revocable keys — and a signed ingest trust policy — keep programmatic reach accountable. Together with data import, this completes how traceunified connects to surrounding systems.