Scorecard Vulnerabilities and Dependency-Update-Tool checks, decoded

Scorecard's Vulnerabilities check uses the OSV service to find open, unfixed vulnerabilities in a project or its dependencies. Dependency-Update-Tool only checks whether Dependabot or Renovate is configured. Both are High risk, but the first reflects real exposure and the second reflects intent, so read them differently.

Vulnerabilities

The checks documentation rates this check High. It asks whether OSV reports open, unfixed vulnerabilities in the project or its dependencies. Because it draws on known vulnerability data, it is the one Scorecard check that speaks about actual issues rather than practices.

Its limits are the limits of any known vulnerability data. It cannot see flaws nobody has reported, and it says nothing about whether those issues are reachable in how the project is used.

How to improve it:

• Fix the code, or update vulnerable dependencies.
• If a finding does not apply, document it as ignored in osv-scanner.toml, as the documentation suggests, with a reason.

Dependency-Update-Tool

Also rated High. It checks whether Dependabot or Renovate is configured. The documentation is explicit that it checks configuration only, not whether the tool runs or whether its pull requests are merged.

A repository can pass with a config file and a pile of ignored pull requests. When you evaluate someone else's project, look at the open update pull requests for a more honest picture.

How to improve it:

• Add a Dependabot or Renovate configuration file.
• Merge the update pull requests, or schedule time for them. A passing check with a stale queue defeats the point.

How they fit together

The two checks pull in the same direction. Update tooling reduces the time a known vulnerability stays open, which helps the Vulnerabilities check. The Scorecard FAQ also recommends pairing hash pinning with an update tool, so pinned dependencies do not stop receiving fixes. See fixing Token-Permissions and Pinned-Dependencies.

Reading these as a consumer

• A Vulnerabilities failure means start with the advisory. Check what is affected and whether a fix exists.
• A Dependency-Update-Tool failure is a weak signal on its own. Combine it with release history.
• Both checks look at the repository, not at your deployment. Your own inventory matters more for your risk.

Safeguard's SBOM and dependency scanning plus reachability analysis cover that last point, showing which known vulnerabilities in your own applications are reachable. The free scan at gold.safeguard.sh/scan is a quick way to see it on a repository.

Quick check

Sources

• Scorecard checks documentation
• Scorecard FAQ

Last reviewed: 19 October 2026.