Threat model

What Flareo protects against, what it doesn't, and which paths that could execute third-party code have been removed.

Trust boundary (verify-and-republish)

Flareo has two tracks:

Catalog (Track A): re-publish a pinned upstream image with receipts. Bits are identical to upstream; Flareo did not rebuild.
Verify (Track B): verify the Sigstore signature of any image against the public-good trust root. Outside the catalog, the response is signature status only (resolved digest, signer identity, issuer, Rekor index from the verified bundle) — no on-demand scan, no trust score.

The trust boundary is: Flareo attests to signature, SBOM, scan, and recorded upstream digest for catalog images, and to verified signature status for anything else. It does not vouch for upstream intent, and it does not execute stranger-supplied build inputs anymore.

Paths that execute third-party code

Dockerfile builds — removed. Accepting an arbitrary Dockerfile onto infrastructure that holds a signing identity was the fatal case: a sandbox escape reaching that identity collapses the trust model. An open build path is also an abuse magnet and is incompatible with reproducibility claims. The sandbox implementation is preserved at apps/worker/src/legacy/build.ts (ADR-012).
Shared demo instances — retired. Seven fixed images on a single host (s-*-demo.preview.flareo.dev), no user input. The host and its domain are gone; ops scripts live under docs/archive/deploy-preview.
Per-user preview allocation was never more than a stub behind a disabled feature flag. It remains gated off (ADR-013).

In scope

Supply-chain tampering during pull. Sigstore verification against a pinned digest detects a swapped image.

Registry account takeover. An attacker who pushes under Flareo's ECR namespace still cannot produce a signature from Flareo's OIDC identity. Pinned digests remain valid.

Unauthorized signing identities. Forks that run their own CI produce a different certificate identity; verifiers that pin the expected identity reject them.

Silent upstream compromise (partial). Trivy will not catch zero-days. The SBOM documents what went in; lastRebuiltAt makes pipeline gaps visible.

Out of scope

Your local runtime. Verification does not prove the image you actually ran matches the image you verified.

Upstream maliciousness. A Flareo signature attests that Flareo re-published a given digest with receipts — not that upstream intent is trustworthy.

Side-channel leaks, DoS against Flareo infra, encryption of your volumes. Ordinary container and ops concerns outside this project's scope.

Red-team playbook

docs/red-team-playbook.md lists 14 attacks across 4 categories. It was written against the build path. Most of those attacks no longer have a live target — that is the intended outcome of retiring the path, not an omission in coverage.

What signal we do ship

Cosign keyless signatures on catalog modules, with Rekor index
Trivy results plus OpenVEX annotation per module
Upstream digest recorded for byte-equivalence checks
Admission policy templates (Kyverno, sigstore/policy-controller) in Audit mode
Catalog policy verdicts at /api/v1/modules/<slug>/policy

Reporting

Open a private report via GitHub Security Advisories. Do not file public issues for active vulnerabilities.