Before adopting a dependency, check whether the project can sustain itself and defend itself: is it maintained, does it require review, who can publish releases and how many people stand behind it. Public data answers most of these in a few minutes, and none of it requires reading the code.
Why this matters
The xz incident, described by Andres Freund on the oss-security list in March 2024, involved a build script in release tarballs that was not in the git source. He noted that the committer was either directly involved or compromised. The case is a reminder that the people and processes behind a package are part of its security.
Signals worth checking
OpenSSF Scorecard turns many of these into automated checks, scored out of 10 each. You can run it from the command line on any public project. Relevant checks include:
- Maintained: recent activity suggests someone is responding.
- Code review: changes are reviewed before merge.
- Branch protection: the main branch cannot be changed casually.
- Security policy: there is a way to report problems.
- Signed releases: you can verify what was published.
- Pinned dependencies and restricted workflow permissions: the build is harder to tamper with.
- Contributor diversity across organizations: the project does not depend on a single company.
Signals Scorecard does not give you
Read a few things by hand.
- How issues and pull requests are handled: courteous, timely, or ignored.
- Whether security reports get acknowledged publicly.
- Whether maintainership has changed recently, and how the change was announced.
- How the package is published to the registry, and who holds the publish rights.
Turning it into a decision
Score each signal as good, weak or unknown. A weak signal does not rule a package out. It sets how much you compensate:
- Weak review: pin versions, delay updates, review diffs on upgrade.
- One maintainer: have a fallback plan, such as an alternative package or a fork you could maintain.
- Unmaintained: avoid for new work, or schedule replacement.
Keep it current
Health is not static. Re-run checks every quarter on your critical dependencies, and also when a package changes owner or has a sudden burst of unusual commits.
Limits
Automated checks cannot prove a project is trustworthy. A well run project can be compromised and a small project can be solid. Use the signals to focus your attention.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Is a low score a reason to reject a package?
Not always. It tells you to add controls such as pinning, delayed upgrades and a fallback plan.
How often should I recheck a dependency?
Quarterly for critical ones, and sooner after a change of maintainer.
Sources
Last reviewed: 19 October 2026.
