How should you read an OpenSSF Scorecard result when vetting a library for adoption?

## What Scorecard is OpenSSF Scorecard is an automated assessment that inspects a project's repository and release practices and reports a set of named checks, each scored on a 0-10 scale, plus a weighted aggregate. Checks are grouped by the risk they speak to, and each carries its own risk weighting, so the aggregate is not a plain average. It is a *process* measurement performed from the outside, entirely without reading the project's logic for correctness. ## The check families and what they tell you **Is anyone maintaining it.** A maintenance check looks at recent commit and release activity; a vulnerabilities check looks for known, unfixed advisories affecting the project itself. These are the closest thing to "is this alive and is it currently carrying a known problem". **How changes get in.** Code review and branch protection checks ask whether commits reach the default branch without a second pair of eyes. This is the single most decision-relevant family for supply chain risk: if anything can be merged and released unilaterally, then compromising one account compromises the artifact, and no amount of downstream scanning changes that. **Build hygiene.** Pinned dependencies, restrictive workflow token permissions, absence of dangerous automation patterns, and absence of committed binary artifacts. A binary blob checked into a source repository is code you cannot review and cannot reproduce, which is why its presence is a genuine finding rather than an aesthetic one. **Disclosure and release integrity.** Whether a security policy exists, and whether releases are signed. The first tells you where to send a report; the second matters only if you actually intend to verify something on the way in. **Testing rigour.** Whether CI tests run on pull requests, whether static analysis runs, whether the project is fuzzed. Fuzzing in particular is meaningful for anything that parses input. ## Why the composite number is the weakest output Three reasons. *It has no notion of your blast radius.* The same score means different things for a two-file string utility and for a framework that terminates TLS in your service. Scorecard cannot know which one you are adopting or what it will be allowed to touch. *It penalises smallness and unusual hosting.* Many checks look for infrastructure that a tiny, stable project has no reason to have, and several depend on the project living somewhere the checks can inspect. A low score frequently means "there was nothing to measure", not "this is dangerous". *Mechanical checks are gameable.* Because the checks are public and deterministic, a project can raise several of them by flipping settings — adding a file, changing a repository option — without changing how it actually reviews or releases code. The score improves; the behaviour does not. Any metric that becomes a target stops being a measurement. ## Using it well Treat Scorecard as a question generator for a human review. A failing code-review check turns into "who reviews changes here, really?". A failing pinned-dependencies check turns into "can an upstream change of theirs alter what I receive?". A failing security-policy check turns into "where would I send a report?". Answers to those questions, weighted by what the dependency will be allowed to reach in your system, are the vetting decision. The common organisational mistake is turning the aggregate into a merge gate — for example, refusing anything under some threshold. That gate fails small, healthy libraries; passes projects that gamed the cheap checks; provides no way to express that this particular dependency will hold keys; and shifts every conversation into arguing with the tool rather than about the risk. If you want a mechanical rule, apply it to a *single* check whose failure genuinely maps to a threat you care about, and always with a documented exception path and an owner. ## What it never gives you Scorecard does not audit the code, does not vet the humans, does not tell you whether the published artifact matches the source you inspected, and does not tell you whether the library is a good fit for your problem. It measures the shape of the project's process. That is genuinely useful and genuinely limited, and a candidate who can say exactly where the line falls is showing more judgment than one who quotes a number.