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 — vulnerability posture, provenance, signature chain, SBOM completeness — 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 the integer mean of four equal-weight signals, each scored 0–100:

trust_score = round(mean(vulns, provenance, signature, sbom))

  vulns       ∈ [0, 100]
  provenance  ∈ [0, 100]
  signature   ∈ [0, 100]
  sbom        ∈ [0, 100]

Equal weights are a judgment call, not an empirical result. We chose them because each signal answers a different question a production operator asks (is it patched? can I prove where it came from? is the signature fresh? do I know what's inside?), and we do not yet have evidence that one should dominate the others. If your threat model disagrees, see the open questions below.

Vulnerability posture (0–100)

Derived from the most recent Trivy scan. Every critical finding deducts ~20 points, every high ~8, every medium ~2, clamped to [0, 100]. A clean scan scores 100.

Counts are taken from the scan against the module's published image. Scans happen on every republish.

Provenance (0–100)

This is what the republish pipeline actually produces: a Sigstore / Rekor transparency-log entry for the signed image, and the upstream digest we re-published from. We do not claim an SLSA build level — the pipeline re-tags and re-signs an upstream image rather than building one, so build provenance is not ours to assert.

In short: signed provenance, upstream digest recorded.

Signature chain (0–100)

Flareo uses cosign keyless exclusively. A real Sigstore entry (Rekor index + Fulcio identity) is full credit; missing either is zero.

SBOM completeness (0–100)

CycloneDX is the format Flareo standardized on for downstream consumption — security teams have CycloneDX importers, and the format accommodates the dependency kinds we encounter.

Score interpretation

The score's color in the UI is graded:

• ≥ 90 (good, green) — production-suitable across all four signals.
• 70-89 (warn, amber) — usable but with one weak signal.
• < 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.
• An SLSA level. We record signed provenance and the upstream digest; we do not claim SLSA L1/L2/L3/L4 for republished images.

Open questions about the weights

Equal weights are a judgment call. 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/Yolo1105/flareo/.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.