Signal / 023 — OpenSSF Scorecard turns repository habits into a security signal

Explainer: Every dependency is borrowed code plus borrowed process. OpenSSF Scorecard tries to make part of that process visible before it becomes your incident.

OpenSSF Scorecard runs automated checks against open-source repositories and reports signals tied to software-supply-chain risk. Its checks cover areas such as branch protection, dangerous workflow permissions, dependency update practices, signed releases, packaging, fuzzing, and whether published artifacts include provenance.

A score is the start, not the answer

The useful part is not the headline number by itself. It is the evidence underneath each check. A repository may lose points because releases are unsigned, because CI tokens have more permissions than necessary, or because security policy information is missing. Those findings point to different risks and require different decisions.

Automation also has blind spots. A small but carefully maintained project may not expose every practice in a machine-detectable way. Repository hosting permissions can limit what a scanner sees. A high score cannot prove that the code is free of vulnerabilities, and a low score does not prove that maintainers are careless. Context still owns the final merge.

A practical dependency gate

Opinion: Use Scorecard as a review queue. For a dependency that will parse untrusted input, run in production, or receive powerful credentials, inspect the failed checks and recent maintenance activity. Then pin versions, minimize privileges, verify release artifacts where possible, and keep an exit plan.

That workflow is less glamorous than installing a package and moving on. It is also how teams escape the default assumption that popular code is automatically safe code.

AI-assisted summary: This explainer was drafted with AI assistance and reviewed against OpenSSF Scorecard’s official project documentation.