Can a scanner match a dependency pinned to a git commit or URL?

Often only partly. A dependency pinned to a git commit or tarball URL has no registry release number to compare against advisory ranges, so many scanners skip it or report it as unknown. Some advisories do use commit ranges, but matching depends on the scanner supporting them.

How git dependencies look

The npm package.json documentation says dependencies can be identified with a tarball or git URL, in addition to a version range. So an entry can point at a repository and commit instead of a version number.

{
  "dependencies": {
    "some-lib": "github:example/some-lib#a1b2c3d"
  }
}

The example is a placeholder. There is no 1.4.2 here for a scanner to read.

Why matching struggles

Advisory databases usually describe affected releases by version ranges. The OSV schema documents several range types, including SEMVER, where introduced and fixed values are semantic versions, and GIT, where ranges are expressed as commits and the entry uses no package field. That is the supported way to describe commit based ranges.

So three things must line up for a hit: the advisory has a GIT range, the scanner understands it, and your dependency's commit can be resolved to a point in that history. Often at least one is missing.

What to do

1. Find them first. Search manifests for URL and github: style dependency specs.
2. Ask why each exists. Often a fork is carrying a patch, or an unreleased fix was needed.
3. Check whether the upstream released the fix. If so, return to a registry version, which scanners handle better.
4. If you must keep the commit pin, record which upstream release it is based on, and treat advisories for that release as potentially yours.
5. For forks, see will scanners flag vulnerabilities in a renamed fork.

Control the habit

Git dependencies bypass registry controls such as malware screening and publish history. Some teams block them in CI by policy. See block git dependencies with npm allow git.

Make the unknowns visible

In your scan output, list components with no registry version as their own category. They are your known unknowns. Review that list monthly and aim to shrink it. See what does an unresolved component mean.

Safeguard offers dependency scanning and a free scan at gold.safeguard.sh/scan. Test a git pinned dependency in a canary repo to see how any tool treats it.

A short decision rule

When you meet a git pinned dependency, ask three questions in order. Is there a released version that contains the commit? If yes, switch to it. Is the commit your own patch on top of a release? If yes, record the base release and watch its advisories. Is it an unreleased upstream commit with no release yet? If yes, set a reminder to revisit when one ships, and list it as unresolved until then.

This keeps the list of git pins short and each one owned, which is the practical goal.

Quick check

Sources

• npm docs: package.json dependencies
• OSV schema specification

Last reviewed: 19 October 2026.