osv-scanner: "failed: no package sources found in ." when run from a subdirectory
Fixes osv-scanner failing to find any lockfiles when run from a subdirectory. Use it when the scanner reports no package sources even though the repo has lockfiles. Key trigger: running osv-scanner from a folder that contains no lockfile itself.
TL;DR: Run osv-scanner from the repository root, or pass the lockfile paths explicitly. The scanner looks for package sources starting at the directory you give it, and a subdirectory with no lockfiles of its own yields nothing. Pointing it at the lockfiles directly fixes the scan.
failed: no package sources found in .- Confirm where the lockfiles actually live. From the repo root, list lockfiles a couple of levels deep.
Expected: you see lockfiles (package-lock.json, Gemfile.lock, go.mod, requirements.txt, and friends) in the root or in subdirectories, but not in the directory where you ran the scanner.
- Re-run from the repo root, or hand the scanner the lockfile directly with the lockfile flag pointed at the file's path.
Expected: the scanner reports the lockfiles it parsed instead of the no-sources error.
- In a monorepo, pass each lockfile explicitly rather than hoping one invocation finds them all.
Expected: every package's dependencies get scanned, with findings attributed per lockfile.
Use this when
- osv-scanner reports no package sources from a subdirectory
- CI runs the scanner with a working directory that is not the repo root
- the repo keeps lockfiles in nested package folders
Not for this skill when
- the scanner finds lockfiles but reports no vulnerabilities; that is a clean result, not this error
- the lockfile itself fails to parse; that is a format problem with a different fix
- you are scanning a container image or SBOM; those use different input flags
Variant phrasings
osv-scanner no package sources found
osv-scanner cannot find lockfile in subdirectory
osv-scanner fails when run from nested folder
how to point osv-scanner at a lockfile path
Why it happens
osv-scanner discovers package sources by walking the directory you hand it, matching known lockfile names. Give it a directory whose walk finds no matches and it has nothing to query, so it fails loudly rather than silently reporting zero vulnerabilities. The error is the scanner refusing to pretend an empty scan is a clean scan.
Edge cases
- A pnpm workspace with a pnpm-workspace.yaml but no pnpm-lock.yaml at the root still yields no sources at the root; point at the actual lockfiles.
- Some setups generate the lockfile during CI before the scan step; if the scan runs before generation, the directory is legitimately empty at scan time, so order the steps correctly.
- Symlinked monorepo layouts can confuse the directory walk; explicit lockfile paths are immune to that.
- The recursive walk can be slow on huge repos; explicit paths are faster as well as more predictable.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_lONEz46FTDmyBxlyWvtsjw