OSV-Scanner vs Anchore Grype: Lockfiles or Container Images

These two end up on the same shortlist for a simple reason. Both are open source, both ship as a single binary, both need no server or account, and both will fail a pipeline on a severity threshold with a few lines of configuration. Both accept SBOMs, so teams assume they are interchangeable. They are not, and picking the wrong one tends to show up as either a pile of findings nobody believes or a gap nobody noticed.

The difference the rest of this article turns on is where each tool starts looking. OSV-Scanner starts from what your package manager resolved: lockfiles, SBOMs, and commit hashes, matched against the OSV.dev database and its per ecosystem version ranges. Anchore Grype starts from the artifact you built: it catalogs a container image or filesystem, finds operating system packages and language packages inside it, and matches that inventory against a database combining distribution security trackers, NVD and the GitHub Advisory Database. One is source shaped, the other is artifact shaped.

The short answer #

Pick OSV-Scanner if your main question is whether the dependencies declared in your repositories are vulnerable, especially with vendored code pinned by commit. Pick Anchore Grype if what you ship is a container image and you need to know what is actually inside it, including the base image packages that a lockfile never mentions. Running both is reasonable and fairly common: OSV-Scanner on the repository at pull request time, Grype on the built image before it is pushed to a registry. They see different populations of components, so the overlap is smaller than it looks.

How they differ #

What each tool treats as the inventory #

OSV-Scanner reads the files your tooling already wrote. A resolved lockfile tells it the exact package and version for every direct and transitive dependency, and an SPDX or CycloneDX SBOM does the same for anything that produced one. It also reads git submodule commit hashes, which is the unusual part: a C library pulled in as a submodule has no manifest entry, but OSV records can express affected commit ranges, so it can still be matched. It can also look at installed OS packages in container images, though that is not its centre of gravity and the supported base images are worth confirming against current documentation.

Grype catalogs the target itself. Point it at an image in a registry or local daemon, an OCI archive or a directory, and it reads the distribution's package database for OS packages, then finds language packages from lock files, installed metadata and archives embedded in the image. The consequence is that Grype sees what ended up in the artifact, including packages a multi stage build copied in and never declared. The flip side is that anything without recognizable metadata, such as statically linked or stripped binaries, is invisible to it.

This axis favours OSV-Scanner for teams whose risk lives in source repositories and vendored code, and Grype for teams whose deliverable is an image.

Where the vulnerability data comes from #

OSV-Scanner matches against OSV.dev, where advisories are recorded as explicit affected ranges within a named ecosystem. Matching is a lookup on an exact package and version rather than a guess from a CPE string, and every result points to a record you can open and read. The trade-off is that coverage is only as deep as what the ecosystems and aggregated sources contribute to OSV. There is no proprietary research layer behind it.

Grype's database leans on distribution security trackers for Alpine, Debian, Ubuntu, Red Hat, SUSE and Amazon Linux, alongside NVD and the GitHub Advisory Database. The distribution trackers are what matter for containers: they know when a distribution has backported a fix into a package whose upstream version number still looks vulnerable, which is the single largest source of false alarms in naive image scanning. Base images still carry findings the distribution has marked as unfixed or low priority, and those need a suppression approach.

This axis favours OSV-Scanner for auditable language ecosystem findings, and Grype for accurate OS package results inside images.

Prioritization beyond version matching #

OSV-Scanner layers two things on top of matching. Experimental call graph analysis for some compiled languages reports whether the vulnerable function is reachable from your code, and a guided remediation mode proposes an upgrade set with the least breakage. Both are narrower than the headline suggests: the reachability language list and remediation ecosystem coverage should be confirmed before you plan around them, and an unreachable result is a hint, not a dismissal.

Grype is pure version matching. It tells you what matched and at what severity, emits JSON, SARIF or CycloneDX, and exits non zero at your threshold. Everything after that is your problem. That narrow scope is part of why it is fast enough for every build.

This axis favours OSV-Scanner for teams that want help ordering the backlog, and Grype for teams that only want a fast, predictable gate.

Where it runs in the pipeline #

OSV-Scanner belongs after dependency resolution and before build: on a developer laptop, or as a pull request check against the committed lockfile. It gives feedback early, when the fix is a lockfile change in the same branch.

Grype belongs after the image exists: a build step, a pre push gate, or a scheduled rescan of stored SBOMs from historical builds so old releases are checked against new advisories without pulling the artifact again. It gives feedback later, but on the thing that actually ships.

This axis favours OSV-Scanner for shift left developer feedback, and Grype for release gating and rescanning what is already deployed.

Where each one falls short #

OSV-Scanner's month three problem is the estate view. It keeps no state, has no dashboard and no waiver workflow that survives the next run, so once dozens of repositories run it, someone is writing glue to collect JSON output, dedupe findings and track exceptions. A language with a thin OSV feed also produces clean scans that mean less than they appear to. And if you ship containers but only scan lockfiles, the base image is a blind spot you will learn about from someone else's scanner.

Grype's month three problem is triage fatigue. Every build produces the same set of base image findings, many of them unfixed by the distribution, and without a documented suppression list the output becomes background noise that developers stop reading. It also keeps no memory between runs, so exceptions live in a config file someone has to own. Vendored native code and stripped binaries never appear in its results, which can give a false sense of completeness.

Pick OSV-Scanner if / Pick Anchore Grype if #

Pick OSV-Scanner if:

• You want findings on the pull request, while the fix is still a lockfile edit.
• You vendor C or C++ libraries as git submodules and need them matched by commit.
• Your auditors or engineers want every finding traced to a public advisory record.
• You mostly deploy language packages or serverless functions rather than container images.
• You want a starting point for prioritization through reachability hints and guided upgrades.

Pick Anchore Grype if:

• Your deliverable is a container image and the base image is part of your attack surface.
• You already generate SBOMs with Syft and want to rescan old builds against new advisories.
• Your images are built on Debian, Ubuntu, Alpine, Red Hat or similar distributions and backported fixes are drowning your current scanner.
• You need a pre push registry gate with SARIF or CycloneDX output.
• Multi stage builds copy in dependencies that never appear in a lockfile.

Frequently asked questions #

Can I use one tool for both lockfiles and images?

Partly. OSV-Scanner can inspect container contents and Grype can scan a directory containing lockfiles, so either will produce results outside its home ground. Each is strongest where it started, though, and most teams that care about both source and images end up running both rather than stretching one.

Will the two tools report the same vulnerabilities?

Not exactly, because they consult different databases and build different inventories. Expect agreement on common language package findings and divergence on OS packages, vendored code and advisories that exist in one feed but not the other. Treat disagreement as a prompt to read the advisory record.

Does either tool replace a commercial SCA platform?

For detection in CI, often yes. Neither provides a portfolio view, exception history, license obligation tracking or ownership routing, so a program at scale pairs them with something like an SBOM monitoring server or builds that layer internally.

Should reachability results suppress findings automatically?

Not from OSV-Scanner's experimental analysis, and Grype does not offer it. Use reachability to order the queue, and keep the finding visible until a human who knows the application has made the call.

Full profiles: OSV-Scanner and Anchore Grype.