Trust Score methodology

Every module on Flareo carries a single 0-100 number called the Trust Score. This page documents exactly how that number is computed, why each weight is what it is, and the open questions about whether the weights should eventually be user-tunable.

The score's purpose is consolidation. A module's underlying signals — provenance level, SBOM coverage, signature chain, vulnerability posture — each have to be parsed before they're useful. The Trust Score collapses them to one comparable number so a visitor can scan a marketplace card and decide whether to click in.

The score is not a guarantee. It's a rendering of the cryptographic and policy facts that already exist in the module's receipts. Every contribution is auditable on the module's detail page.

The formula

The Trust Score is a sum of four weighted contributions, capped at 100:

trust_score = vulns + slsa + signature + sbom

  vulns      ∈ [0, 40]
  slsa       ∈ [0, 25]
  signature  ∈ [0, 20]
  sbom       ∈ [0, 15]

The total weight allocation reflects an opinionated ordering of what matters most for a "do I run this in production" decision: vulnerability posture above all else, then provenance, then signature, then SBOM completeness. A module with critical CVEs cannot earn back enough points elsewhere to look safe; that's the design.

Vulnerability posture (max 40)

The double weighting of "critical" reflects the operational reality: critical CVEs frequently mean remote code execution or auth bypass. A module with a critical CVE shouldn't be running in production, period — and the Trust Score reflects that by zeroing the vulns component regardless of how clean the other signals are.

Counts are taken from the most recent Trivy scan against the module's image. Scans happen on every rebuild (daily for canary chains).

SLSA attestation (max 25)

Today, every module Flareo publishes is at least L1; the canary chain promotes verified modules to L3 over their first 30 days. L4 requires manual review and is reserved for modules where reproducibility has been verified — currently a small subset.

Signature chain (max 20)

Flareo uses cosign keyless exclusively, so the working signal here is "is the Rekor entry recent and verifiable." Modules that have not been re-signed within the last 30 days drop into the 15-point bucket, which prompts the canary chain to schedule a refresh.

SBOM completeness (max 15)

CycloneDX is the format Flareo standardized on for downstream consumption — security teams have CycloneDX importers, regulators have CycloneDX guidance, and the format is permissive enough to accommodate every kind of dependency we encounter. SPDX is a partial-credit fallback because it's what some upstream maintainers ship.

Score interpretation

The score's color in the UI is graded:

• ≥ 90 (good, green) — production-suitable across all four signals. No critical CVEs, modern provenance, fresh signature, complete SBOM.
• 70-89 (warn, amber) — usable but with one weak signal. Often a stale Rekor entry or partial SBOM coverage.
• < 70 (bad, red) — flagged for the visitor to look closer. Either critical CVEs are present, provenance is missing, or multiple signals are weak.

The thresholds are deliberately conservative: 89 isn't a low score, it's a "look at the breakdown before deploying" score.

What the score is NOT

The Trust Score is not:

• A reachability analysis. A high CVE count without a corresponding VEX annotation will lower the score even if those CVEs are not exploitable in this module's request path. VEX support — which annotates which findings are actually applicable — is on the roadmap (see /roadmap). Until then, the score is conservative on CVE counts.
• A reflection of operational quality. Whether a module restarts cleanly, handles backpressure, or has good logging is not measurable from cryptographic receipts. The score answers "is this verified" not "is this well-engineered."
• A reflection of upstream maintainer reputation. A well-maintained upstream with poor security hygiene scores worse than a niche project with a clean recent scan. That's correct: Flareo is signing the version of the image you'd actually run, not the project's track record.
• A guarantee. Trust Scores are computed from Flareo's own pipeline outputs. If our pipeline misses something, the score will reflect that miss. Bug reports for missed signals are welcome — they appear on /incidents after triage.

Open questions about the weights

We have not yet decided whether the weights should be user-tunable. Three positions, none yet committed:

Position A — keep weights fixed. A single canonical Trust Score makes scanning the marketplace fast. Multiple per-user weightings means a "your score" of 96 might be a "my score" of 72 — and a number that means different things to different people stops being a useful summary.

Position B — tunable for organizations only. Free / Pro tiers see the canonical score. Enterprise tier can configure org-specific weights — a team that doesn't care about SBOM (because they have their own tooling) can drop SBOM weight, redistribute to vulnerability posture, and see scores tuned to their threat model.

Position C — tunable for everyone, with the canonical score still visible. The marketplace shows both numbers — "Flareo: 96 · You: 88" — so the canonical comparison still works but power users can express their own priorities.

We're holding the question open until we see whether the demand is there. If you have an opinion, send it our way.

Auditing the score yourself

The score is computed from publicly-visible inputs. You can verify any module's Trust Score using only the receipts on its detail page:

# Pull the SBOM + provenance + signature for a module
flareo receipts vaultwarden > receipts.tar
tar xf receipts.tar

# Run the same scan we ran
trivy image ghcr.io/flareo/vaultwarden:1.30.5 --format json > scan.json

# Verify the signature against Rekor
cosign verify ghcr.io/flareo/vaultwarden:1.30.5 \
  --certificate-identity 'https://github.com/flareo/build/.github/workflows/canary-rebuild.yml@refs/heads/main' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'

# Plug the numbers into the formula above

If your computed score differs from ours, that's a bug. Open an issue on the module's detail page and we'll triage it.