Security model¶

This page describes how untrust protects your evidence and your decisions, and what each of its guarantees does and does not cover. The short version: deny by default, fail closed, and never read an unknown, a skip, an error or absent evidence as a pass.

Trust roots¶

Hardware evidence is verified against the hardware vendors' own roots of trust, never against anything the evidence carries about itself:

AMD SEV-SNP reports chain to AMD's root keys, with certificate revocation checked.
Intel TDX and SGX quotes chain to Intel's roots, with TCB status from Intel's collateral.
NVIDIA GPU reports chain to NVIDIA's roots, and their measurements are appraised against reference integrity manifests.
Nitro Enclaves attestation documents chain to the AWS Nitro root.
GCE launch endorsements are checked against Google's signing roots.

If a vendor service or its collateral is unavailable, the affected check is ERROR, never PASS, and a release decision that depends on it is denied.

Signing¶

Key-release receipts and evidence packs can be signed with an asymmetric key (ECDSA P-256) held in a cloud key management service. The private key never enters the untrust service process: signing is a call to the key service.

A signature is honoured only against a public key the verifier supplies. A key embedded in a receipt or pack is never trusted on its own.
Every receipt and pack names the organization it belongs to; verification fails for any other organization.
Without a signer, receipts and packs are honestly labelled unsigned. Integrity then rests on the ledger's hash chain or the pack's manifest digest, and supplying a key later never upgrades an unsigned entry to signed.
Ledger entries are hash-chained and append-only, so an altered entry is detected independently of its signature.

You can check all of this yourself with the offline verifiers. The Threat model lists each attack these controls stop.

Tenant isolation¶

Every resource belongs to exactly one organization, and every request re-reads the caller's current membership and role. A role is never taken from the request or from a cached session.
Within an organization, an administrator can turn on project access enforcement. It is off by default. Once it's on, project access is an authorization boundary, not just a view filter: a project-restricted member's requests are limited to the projects they hold grants on. While it's off, every member sees every project in the organization.
API keys are stored only as a digest, expire, are capped by their creator's current role, and cannot manage members or other keys.
CI tokens are accepted only at the ingest endpoint of the one binding they were minted for, and cannot read the console or change bindings.
Each collector signs with its own enrolled key; a report is accepted only for the fleet that key enrolled into.
Changes to members, keys, connections, bindings, fleets and rules are written to the organization's audit log in the same transaction as the change.

Sign-in uses OpenID Connect with the authorization code flow and PKCE. ID tokens are verified for signature, issuer, audience, expiry and nonce.
Membership comes only from an invitation an administrator created. Email addresses, provider roles and group claims never create an account or grant a permission.
Session cookies are Secure, HttpOnly and SameSite=Lax; the credential never reaches page JavaScript or browser storage. State-changing requests also require a CSRF token and a matching origin.
Sessions last at most one hour and never outlive the identity provider's token. Provider access and refresh tokens are not retained.

Evidence handling¶

Scans run in your environment with your credentials. untrust never asks for, stores or uploads cloud credentials; connection forms reject access keys, private keys and secrets.
Cloud connections use federation or role assumption scoped to one connection (an external ID on AWS, a connection-specific delegate on GCP and Azure), never shared static keys.
CI evidence is an authenticated submission tied to a pinned pipeline identity. It is never promoted to verified hardware posture.
Collector bundles are signed on the host and verified by the service before their hardware evidence is appraised. Evidence that fails verification is labelled unverified.
Text from a scanned artifact (file names, finding text) is length-bounded and stripped of control characters before it is shown in a pull request or the console.

The key-release gate¶

When your key broker asks untrust before releasing a secret, the decision is deny by default. A key is released only when every required policy is present and passing on verified evidence, the evidence is bound to the caller's nonce and wrap key, the fleet and platform match, and the host is not quarantined. Any verifier fault, missing evidence or vendor outage denies the release, and every decision is recorded.

Limits¶

Verification proves provenance, not truth. A verified receipt proves untrust recorded it for your organization; it does not prove the hardware evidence behind it was honest. That is what the attestation checks assess.
Configuration checks see configuration. Some threats are out of scope for a deployment scanner: timing side channels, attestation freshness inside your application code, input validation in a host-to-enclave protocol, and physical or microarchitectural attacks. These need code review, runtime self-checks inside the TEE, or the hardware vendor's mitigations.
CI labels are labels. Commit and run identifiers in a build or IaC receipt are checked against the CI token, but the receipt does not prove the scanned artifact is the one you deployed.

Reporting a vulnerability¶

If you believe you have found a security issue in untrust, contact your untrust representative or security@untrustsecurity.com. Please do not file it in a public issue tracker.