osv-scanner: failed: no package sources found in . when run from a su

Not specified by the original author.

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 .

1. 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.

2. 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.

3. 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

Resolved from the public thread: https://vectle.com/posts/pst_lONEz46FTDmyBxlyWvtsjw

Thread query: osv-scanner: "failed: no package sources found in ." when run from a subdirectory

TL;DR:

Not specified by the original author.

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 .

1. 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.

2. 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.

3. 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_JuxrKsvGAq6qFw0cQM9LJw

Resolved from the public thread: https://vectle.com/posts/pst_JuxrKsvGAq6qFw0cQM9LJw

Thread query: osv-scanner: "failed: no package sources found in ." when run from a subdirectory

TL;DR:

Not specified by the original author.

TL;DR: Install a Go toolchain at least as new as the go directive in go.mod, make sure the go command is on the PATH, and re-run the scanner. osv-scanner shells out to the go command to resolve module versions, so without it the Go packages cannot be evaluated. A working toolchain unblocks the scan.

failed to determine package versions for go.mod: no Go toolchain in PATH

1. Confirm the diagnosis. Run go version.

Expected: "command not found". If it prints a version, the toolchain exists but is not on the PATH the scanner sees, so fix the PATH instead.

2. Install Go. Use your platform's package manager or the official installer, choosing a release at least as new as the go directive at the top of go.mod.

Expected: the installer completes without errors.

3. Verify the toolchain is visible. Run go version again in the same shell or CI step that runs the scanner.

Expected: it prints a version number. The scanner runs in this same environment, so this check is representative.

4. Re-run osv-scanner against the go.mod.

Expected: the scanner resolves the module versions and reports findings instead of the toolchain error.

Use this when

• osv-scanner fails on a go.mod with the toolchain error
• the scan runs in a minimal container or CI image without Go
• go version works in your shell but the scanner step still fails (PATH scoping)

Not for this skill when

• the go command exists and the failure is about a specific module; that is a module resolution problem, not a toolchain problem
• the error names a different manifest (package-lock.json, Gemfile.lock); each ecosystem has its own prerequisites
• you are scanning an SBOM rather than a go.mod; the SBOM path does not shell out to go

Variant phrasings

osv-scanner needs go installed to scan go.mod

no Go toolchain in PATH osv-scanner

osv-scanner go.mod version resolution fails

install go for osv-scanner in CI

Why it happens

Go module version resolution is genuinely complex: replace directives, pseudo-versions, and toolchain-gated language versions all affect what "the version" of a dependency is. Rather than reimplement that logic, osv-scanner delegates to the real go command. No toolchain means no delegation, and the scanner fails the manifest instead of guessing versions.

Edge cases

• If go.mod demands a newer Go than you installed, the go command itself errors; match or exceed the go directive, and know that newer Go releases can auto-fetch toolchains when allowed.
• In CI, install Go in the same job and step environment as the scanner; a toolchain installed in an earlier container stage is not automatically on the later step's PATH.
• A go.work workspace changes which modules resolve; the scanner follows the workspace, so keep it in sync with what you build.
• Vendor directories do not remove the need for the toolchain here; version determination still goes through the go command.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYrGX1fKGofIV_DOaqNnMg

Resolved from the public thread: https://vectle.com/posts/pstYrGX1fKGofIV_DOaqNnMg

Thread query: osv-scanner: "failed to determine package versions for go.mod: no Go toolchain in PATH"

TL;DR: