Security posture

A release pipeline holds the keys to everything you ship. These are the decisions that follow from taking that seriously — and, at the end, the thing this does not claim.

Credentials

• Envelope encryption, with a pluggable key provider.
• No API returns plaintext, to anyone, including administrators. There is no route that could.
• A job receives short-lived, single-use material scoped to exactly the purposes its declared steps need — computed from the step registry rather than granted wholesale.
• Every fetch is audited. Expiry is monitored and warned about ahead of time.

Untrusted builds

A pull request from a fork runs on a pool with zero credentials and cannot distribute. That property is derived from the credentials a job actually resolves, not declared by a flag — so a step that starts needing a secret stops being fork-safe automatically, rather than when somebody remembers.

Identity

Passkeys are the primary factor, with an emailed code as the fallback that always works — including for somebody invited five minutes ago. Refresh tokens rotate, and reuse of a rotated one revokes the whole family on the assumption that reuse means theft. Every authorisation decision is re-evaluated server-side on every request; the interface hiding a button is a convenience, never a control.

Approvals

A distribution that needs sign-off is checked before any bytes move. An uploaded TestFlight build is already visible to internal testers, so waiting after the upload would be guarding a door that is already open. N approvers means N distinct people, enforced by the schema rather than counted.

Audit

Events are append-only at the database level and hash-chained per organisation, with a verifier that locates any altered record.

What this does not claim

The audit log is tamper-evident, not tamper-proof. Someone with table ownership can bypass the trigger — at which point the chain verifier detects it. We would rather say that plainly than let an auditor infer something stronger.