Threat model

What Flareo protects against, what it doesn't, and what we'd like to protect against but can't yet.

In scope

Supply-chain tampering during pull. If an attacker on your network or at an upstream mirror tries to swap the image you're pulling for a malicious one, Sigstore verification against a pinned digest detects it. The content hash won't match; cosign fails loudly.

Registry account takeover. If our ECR Public account is compromised and an attacker pushes a new image under an existing tag, the signature won't verify because the attacker can't sign with the Flareo GitHub OIDC identity. Your pinned digest remains valid, and anyone verifying an attacker's new image gets a signature mismatch.

Unauthorized rebuilds. Only CI jobs running from the flareo organization's protected branches produce signatures. An attacker who forks the repo and runs their own CI produces a different signer identity, which cosign verify --certificate-identity-regexp 'https://github.com/flareo/.+' rejects.

Silent upstream compromise (partial). If upstream ships a backdoored release, our Trivy scan won't catch it (scanners look for known CVEs, not zero-days). The SBOM we generate does document every package that went in, so a retroactive audit is possible. We'll often be the first to notice because our daily rebuild exposes the compromise to more eyes.

Out of scope

Your local build environment. If your laptop has a compromised Docker daemon or a malicious shell alias, Flareo's verification tells you nothing about whether the image you actually ran matches the image you verified. Run containers on a clean host.

Upstream maliciousness. The author of a project we package could publish a malicious release. Flareo's signature attests only that we built the release from upstream source; it does not attest that the upstream source is trustworthy. Signing is not vouching.

Side-channel leaks. Running untrusted container code still risks CPU-level side-channel attacks (Spectre, Meltdown, and friends). Flareo images run as ordinary containers; they don't use gVisor or similar sandboxes.

Denial-of-service attacks on Flareo infrastructure. If flareo.dev goes down, nothing catastrophic happens — you can still verify images against Sigstore directly without us — but the catalog and web tool are unavailable.

Attacks against your data at rest. Flareo doesn't encrypt your container volumes or manage secrets. That's your infrastructure's job.

What we'd like to protect against but don't yet

SLSA level 3. We're at level 2 today: the build is automated and provenance-attested, but the builder isn't isolated per-job (jobs share the GitHub Actions runner fleet). SLSA L3 requires hermetic builds on isolated infrastructure. The operational cost is real and no customer has asked us to prioritize it; if your admission posture requires L3, file an issue and we'll reconsider.

Reproducible builds. We don't currently verify that two independent builds of the same upstream source produce bit-identical images. Rebuilds are deterministic in intent (pinned base images, locked dependencies) but we haven't invested in the tooling to prove bit-for-bit reproducibility. Diffoscope-based CI is on the medium-term list.

Runtime admission enforcement, server-side. We ship admission policies (Kyverno, sigstore-policy-controller) at /docs/admission and a per-module policy verdict endpoint at /api/v1/modules/<slug>/policy. What we don't yet operate is a hosted admission controller that proxies pulls — that's downstream from this catalog and would be a bigger product than what we're trying to be.

What signal we DO ship

To save you reading the rest of the docs to find out what threats Flareo's catalog actively addresses:

• Image tampering between build and pull. Cosign keyless signature on every module, verified by flareo verify or cosign verify directly against the Rekor transparency log. If an attacker substitutes the image, the signature breaks.
• CVEs in the image, with reviewer-judged context. Trivy scan results plus a per-module OpenVEX 0.2.0 document (/api/v1/modules/<slug>/vex) where the reviewer team annotates which findings are actually exploitable. See /docs/vex for the four statuses, scanner integration, and how not_affected is policed.
• Build provenance you can audit. SLSA L2 in-toto attestation on every module — what was built, from what source ref, by what builder. Verifiable independent of Flareo.
• Catalog-level admission verdict. The active admission policy (CVE thresholds after VEX, signature/SBOM/Rekor presence, SLSA level, composite trust score) is evaluated against every module. Verdict at /api/v1/modules/<slug>/policy with the per-rule breakdown. Higher-level signal than "a signature exists" — it's "a known set of rules cleared, including the ones VEX-suppressed."

Trust we ask you to extend

To use Flareo, you're trusting:

• Sigstore's public-good infrastructure (Fulcio, Rekor, TUF trust root)
• GitHub Actions as an OIDC issuer
• The flareo organization's control of its GitHub repositories and ECR Public account
• AWS for hosting the public images

Plus whichever trust chains you extend to your OS, container runtime, and network. Flareo adds one layer to that stack; it doesn't replace any existing ones.

What to do if you find a vulnerability

Open an issue at github.com/flareo/flareo/security/advisories (private advisories), or email security@flareo.dev. We'll respond within 72 hours and work toward coordinated disclosure.

Next steps

• How we sign modules — the cryptographic details
• Verify from the CLI — run the checks yourself