Built on the OpenSSF Scorecard

Don't build on code you haven't vetted.

Evaluating a tool/Maintaining one

See its trust report before you commit.Find the gaps in your code — and fix them.

Try ossf/scorecard or sindresorhus/got. No sign-in needed to read a report.

Four questions, four pillars — one synthesis

Pillar 1· Is it built securely?

Security & Supply Chain

The full OpenSSF Scorecard — token permissions, pinned dependencies, SAST, signed releases, and more.

Pillar 2· Can I trust the project behind it?

Trust & Governance

License, security policy, who owns it, and whether there is a way to reach them when something breaks.

Pillar 3· Will it be here in a year?

Community & Sustainability

Maintenance, contributors, and recent activity — read as a lifecycle stage, never as a grade.

Pillar 4· Is it well-built?

Functional Quality

Honestly marked “not assessed”. Whether software is good is a hands-on judgement — we never fake it from automated signals.

How it works

Paste a repo

Any public GitHub repository — URL or owner/repo.

Assess it with OpenSSF

The full OpenSSF Scorecard, plus GitHub governance and lifecycle signals.

Read your report by pillar

Each pillar answers a different question, with its own findings and constructive fixes. No single grade papers over the trade-offs — you see where the project is strong and where it isn't.

Send fixes upstream

File a friendly, attributed issue as yourself.

Why no single score?

Each pillar answers a different question. A brilliant, secure library maintained by one person is not “7 out of 10” — it is strong on security and early on community. Collapsing that into one number hides exactly the trade-off you are trying to weigh. So we don't.