Trust Passport methodology

Trust is a primary product surface here, not a decorative badge. Every listing carries a Trust Passport: 22 individually visible components across five categories, plus one automated composite score.

How the 0–100 score is computed (v1)

Methodology version 1.0: the score is an equal-weight pass fraction.

score = round(components_passing / 22 × 100)

Each component resolves to one status: pass, warn, fail, or unknown.
Only a pass counts toward the numerator.
warnand unknown components count as not passing, but are shown separately so a buyer can see what wasn’t checked versus what was checked and failed.
The denominator is fixed at all 22 components for every listing in v1 — it does not yet vary by product type. A not_applicable status and a per-component weight field exist in the schema for a future weighted methodology version, but v1 does not use them: every component is equal-weight and treated as applicable to every listing.

An automated score — at any level — is never a guarantee of security, correctness, or fitness for purpose. It reflects which automated and disclosed checks passed at computation time, nothing more. Always read the individual components, not just the number.

The 22 components, grouped

Identity

3 components

Who published this, and can they prove it.

Publisher identity
The creator's identity (individual or organization) has been verified.
Domain verified
Control of the product's public domain has been confirmed.
Repository ownership
Ownership of the linked source repository has been confirmed.

Supply chain

6 components

What's actually in the artifact, and where it came from.

Release signature
Published releases are cryptographically signed.
SBOM available
A software bill of materials (SPDX or CycloneDX) is published for the release.
Provenance
A build provenance attestation (SLSA, in-toto, or GitHub attestation) is available.
Secret scan
Static scan for committed secrets and credentials.
Dependency scan
Static scan for known-vulnerable dependencies.
License scan
Declared licenses are checked against what the codebase actually contains.

Code health

6 components

Whether the codebase and its claims hold up.

Static analysis
Static code analysis for common defect classes.
Test evidence
Evidence of automated test coverage.
Build reproducibility
The published artifact can be reproduced from its declared source.
Documentation completeness
Documentation covers setup, configuration, and known limits.
Permission review
Requested permissions and scopes have been reviewed against the product's stated purpose.
Data-handling disclosure
What data the product touches, and how it's handled, is disclosed.

Operations

3 components

Whether it keeps running, and whether anyone's minding it.

Deployment verification
Hosted or managed deployments are verified to actually run.
Maintenance recency
Time since the last meaningful release, fix, or security update.
Support history
Track record of responding to support requests.

Market evidence

4 components

What real buyers experienced, not just what the listing claims.

Verified installation success
Real installs report succeeding, not just being attempted.
Verified purchase reviews
Reviews are tied to a verified purchase or installation, not open submission.
Refund history
Refund rate and pattern for completed purchases.
Dispute history
History of moderation cases and disputes involving this listing.

Full methodology writeup

The complete methodology document, including scan tooling and known v1 limitations, is maintained in the repository at docs/trust-score-methodology.md.