信任信号如何工作

What trust signals are

GraphCanon surfaces sourced, dated heuristics to help you compare open-source AI development tools. They are decision inputs, not certifications.

Every trust report names its methodology version, when signals were computed, and what data we actually inspected. We do not ship a composite letter grade or a black-box safety score.

Maintenance signals

Maintenance posture is derived from public GitHub repository metadata refreshed on ingest and on scheduled GitHub sync. The label and percentage signal reflect recency of activity, not code quality or security.

Methodology version: github_public_v1.

• Archived on GitHub → label Archived (repos marked archived are treated as unmaintained by definition).
• No pushed_at timestamp → label Unknown.
• Last push within 7 days → Very active; within 30 days → Active; within 90 days → Steady; within 365 days → Slowing; older → Dormant.
• When metric history exists, we also store 30-day deltas for stars and open issues alongside the push recency signal.
• Discovery surfaces may show the persisted label or the same heuristic when trust metadata has not been computed yet.

Provenance signals

Provenance fields identify the upstream repository and basic lineage from GitHub's public API. They help spot forks and account type; they do not verify maintainer identity or organizational endorsement.

Methodology version: github_public_v1.

• github_id - stable numeric id for the repository on GitHub.
• is_fork and parent_repo - whether the catalog entry points at a fork and, when known, the parent owner/repo.
• owner_type - GitHub account class (Organization vs User) when returned by the API.
• computed_at - ISO timestamp when these fields were last merged into stored trust metadata.

Dependency security scans

When enabled for a tool, security status comes from an automated dependency advisory lookup against lockfiles present in the default branch. This is intentionally narrow: known CVEs in declared dependencies, not a review of application code.

If no supported lockfile is found, status is No lockfile and we do not infer a clean bill of health.

Methodology version: osv@v1.

• Scanner: OSV batch queries against declared package versions.
• Lockfiles tried (up to three per repo): package-lock.json, pnpm-lock.yaml, poetry.lock, requirements.txt, go.sum.
• At most 150 unique package coordinates are queried per scan to bound cost and latency.
• Findings list severity, advisory title, package coordinate, and CVE alias when OSV provides one.
• A status of No criticals means no critical-severity advisories matched scanned packages on the scan date - not that the project is secure.

MCP code pattern checks (regex heuristics)

For MCP server repos, we optionally run pattern checks on a small set of source files (not full dependency advisories). Findings are heuristic regex matches, not the Semgrep engine, a full static analysis run, or a penetration test.

Critical and high findings are reviewed before surfacing broadly. Expect false positives on legitimate subprocess or HTTP usage.

Methodology version: mcp-regex-heuristics@v1.

• Rule pack covers common MCP risk patterns (SSRF, subprocess, auth-disabled, transport).
• Eligibility: MCP topic/manifest heuristics or manually flagged repos only.
• Scans run asynchronously on a daily cap - not on every page view.

deps.dev advisory enrichment

GraphCanon also queries the public deps.dev API for advisory keys attached to resolved lockfile package versions. Advisory details are hosted by OSV; deps.dev provides package-version linkage and CVSS metadata.

When the same advisory appears in both OSV and deps.dev scans, GraphCanon deduplicates by CVE or advisory id and keeps all source attribution.

Methodology version: deps.dev@v1.

• Source: deps.dev Insights API v3 (CC-BY 4.0 generated data; upstream advisories from OSV).
• Queries up to 30 unique package coordinates per scan and up to 50 advisory detail lookups.
• A version with no deps.dev record is not_available, not a clean result.
• Partial means package or advisory caps were hit before every coordinate was checked.

OpenSSF Scorecard (external intelligence)

When available, GraphCanon ingests published OpenSSF Scorecard results from the public REST API. This is third-party repository health metadata, not a GraphCanon audit.

Weekly public Scorecard scans omit some checks at scale; we store returned checks and mark coverage partial when those omissions apply. A missing Scorecard record means the source has no public result for that repository, not that the project passed review.

Methodology version: openssf-scorecard@v1.

• Source: OpenSSF Scorecard REST API (CDLA Permissive 2.0).
• We persist individual check scores and reasons, not only the aggregate 0-10 score.
• Low-scoring checks surface as dated findings with links to Scorecard check documentation.
• No published findings from this source as of the evidence date is not the same as verified clean.

Verified publisher badge

A verified publisher badge means a signed-in GitHub user with repo admin access claimed the listing via **Verify ownership** on the tool page. It is distinct from the owner_type heuristic (Organization vs User) which comes from GitHub metadata alone.

Maintainers can also submit **Report inaccurate data** on the tool page when categories, compatibility claims, trust copy, or graph edges look wrong. Verified publisher reports are prioritized in admin triage.

• Claim requires GitHub sign-in and proof of admin, maintain, or write access to the repository.
• Verification checks that the GitHub login matches the personal owner, or that collaborator permissions are sufficient.
• Stored alongside other provenance fields on the tool's trust report.

What we never claim

Trust signals must not be read as warranties. GraphCanon does not run penetration tests, code audits, or maintainer background checks.

• We do not claim a tool is safe, production-ready, or verified secure.
• We do not claim pen-test coverage, SOC 2 compliance, or supply-chain certification.
• We do not endorse maintainers, organizations, or downstream use in regulated environments.
• Absence of findings in a dependency scan is not proof of absence of vulnerabilities (unscanned lockfiles, private deps, runtime-only risk, etc.).
• Maintenance labels describe GitHub activity heuristics, not whether you should adopt the software.

Freshness and limits

Trust metadata is recomputed when a tool is ingested or synced from GitHub. Security scans run on that same cadence when the scanner is enabled for the corpus.

GitHub facts can lag reality (force-pushes, mirror delays, archived state changes). Always confirm critical decisions against the live repository and your own security process.