Sort signals into hard blocks, review triggers and informational notes. Block on states the registry or maintainer marks as unsafe. Send to review when several soft signals combine or a high-impact package changes. Allow the rest and log why. Avoid one composite score deciding alone.
Three buckets
| Bucket | Meaning | Example signals |
|---|---|---|
| Block | Do not install without an exception | Yanked or retracted version, quarantined project, version affected by a known critical flaw that is reachable in your code |
| Review | A human decides | New package with a lookalike name, new install script, publisher change, archived project, missing license |
| Note | Record and move on | Version starts with 0, no SECURITY.md, low contributor diversity for a small project |
The thresholds are yours. The sources cited here, the OpenSSF Concise Guide and Scorecard documentation, describe signals and risks, not cutoffs, and both say even good projects may do poorly on some questions.
Steps to build the rule
- List the signals you can collect automatically: registry flags, publish dates, advisories, Scorecard checks, provenance presence.
- Assign each to a bucket using two questions: how reliable is the signal, and how bad is a wrong call?
- Add a role multiplier. Anything in the build and CI tier moves one bucket stricter.
- Define combinations. For example, a maintainer change plus a long release gap plus a new install script goes to review even if each alone is a note.
- Write the exception path: who can approve, for how long, and where it is recorded.
- Run the rule in report-only mode for a few weeks and tune it against real pull requests.
Why not a single score
A weighted score looks tidy, but it hides which signal tripped, invites arguing over weights, and can be gamed by a package that polishes the measured items. Scorecard documents each check separately for a reason. Keep reasons visible: show the reviewer the three signals that fired and the values.
Examples
A pull request adds a package created last month with a name one letter off a popular one. Identity signal fires, so the result is review, and the reviewer confirms the intended name.
A version bump to a build plugin adds a postinstall script. The role is build tier, the script is new, so the result is review, with the diff attached.
A finding on a package with no reachable path from your code lands as a note, not a block, until you change how you use it.
Keep it honest over time
Review the rule quarterly. Count how many reviews ended in no action. A high rate means the rule is too noisy and people will stop reading it. A zero rate may mean it is too quiet.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate turns a policy into a pass, hold or fail on a pull request.
Where Safeguard fits
Safeguard provides policies, gates and guardrails with SBOM and dependency scanning and reachability analysis, so rules like these can run on every pull request. A free scan is at gold.safeguard.sh/scan.
Quick check
Should a block ever be overridden?
Yes, with a named approver, a reason and an expiry date, recorded where audits can find it.
How many signals are enough?
Start with five to eight that you can collect reliably. Add more only when a real case shows a gap.
Sources
Last reviewed: 19 October 2026.
