This worked example scores an invented npm library, called example-parse, against a five-row rubric. It ends with an adopt-with-conditions decision and a list of controls. Every detail about example-parse is made up for illustration. No real project or person is described.
The setup
Your team wants a small library to parse a configuration format. It will run in your production service on input from customers, so the blast radius is meaningful. You use the rubric from our vetting overview: five rows, 0 to 2 points each, with 8 or more as a clean adopt and 5 to 7 as adopt with conditions. Those cutoffs are our own starting point.
Row by row
| Row | Evidence found | Points |
|---|---|---|
| Activity | Last release 3 months ago, commits monthly, issues answered in days | 2 |
| Release practice | Built in CI, provenance present, token publishing still enabled | 1 |
| Vulnerability handling | Two past advisories, both with fixed versions, precise ranges | 2 |
| Continuity | One person wrote most commits, two accounts can publish, no org | 1 |
| Automation risk | Workflows use read-only permissions, actions pinned by tag not SHA, no install scripts | 1 |
Total: 7 of 10.
How the evidence was gathered
Activity came from the repository insights and the registry release dates. Release practice came from the package page, plus npm audit signatures on a test project to confirm attestations verify. Advisory history came from the GitHub Advisory Database and OSV, matching affected and fixed ranges to released versions. Continuity combined a bus factor estimate with the registry owners list. Automation risk came from reading the workflow files against GitHub's hardening guidance on read-only tokens and pinning actions to full commit SHAs.
Scorecard output would be a supporting input, for example its Token-Permissions and Pinned-Dependencies rows, but not the decision itself.
The decision
A score of 7 lands in adopt with conditions. The weak rows point directly at conditions:
- Pin the exact version and keep the lockfile hash.
- Ask the maintainer to disable long-lived publish tokens and offer to help. See questions to ask a maintainer.
- Add example-parse to monitoring for new advisories.
- Wrap it behind a small interface in your code to keep an exit cheap, and write the exit plan.
- Re-review on any change of registry owners.
What the rubric did not catch
Be honest about limits. The score does not detect a malicious maintainer or a freshly stolen account. It does not read the code either. For a package parsing customer input, add a code skim of the parser entry points and run it through your normal scanning. That residual risk belongs in the record.
What to take away
The value is less the number than the traceable reasoning. Anyone can open the record, see why 7 was assigned, and challenge a row. That is the repeatable part.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Is example-parse a real package?
No. It is invented for this walkthrough, and the findings are illustrative.
Can I change the point values?
Yes. Weight rows by your risk, for example doubling release practice for build tooling.
Sources
- OpenSSF Scorecard repository
- GitHub Docs: security hardening for GitHub Actions
- npm Docs: generating provenance statements
Last reviewed: 19 October 2026.
