🐛 avoid scanning the filesystem root for commit-only OSV lookups - #5180
Open
pujitha24 wants to merge 4 commits into
Open
🐛 avoid scanning the filesystem root for commit-only OSV lookups#5180pujitha24 wants to merge 4 commits into
pujitha24 wants to merge 4 commits into
Conversation
Motivation: The Vulnerabilities check crashes for repositories with no local on-disk checkout (currently only the GitLab client, whose RepoClient.LocalPath() always returns an empty string). clients/osv.go calls osvscanner.DoScan with a non-empty GitCommits but empty DirectoryPaths in that case. In google/osv-scanner v2.3.2 (bumped in scorecard v5.5.0, from v2.2.4), that combination makes DoScan default to scanning the filesystem root "/" with the default lockfile/sbom/directory extractors, since v2.3.2 folded commit-only scanning into the same directory-walk loop used for lockfile scanning and falls back to "/" when no directories were supplied. On a typical Linux host this walk hits /proc and fails with a permission error, which scorecard surfaces as a hard check failure, breaking `scorecard --repo=<gitlab-url>` entirely unless the Vulnerabilities check is explicitly excluded. Report: ossf#5056 Approach: When there's a commit to scan but no local directory, create a harmless empty temporary directory and pass it as DirectoryPaths instead of leaving it empty. This keeps osv-scanner's rootMap from defaulting to "/". The git-commit-based lookup still runs correctly: osv-scanner's gitcommitdirect extractor is a standalone extractor that returns results purely from the configured commit list and ignores whatever directory it's paired with, so no scanning functionality is lost, only the unintended full-filesystem walk is avoided. The temporary directory is removed after the scan. Validation: Added clients.TestCommitOnlyNoLocalPath, calling ListUnfixedVulnerabilities with a commit and an empty local path. Confirmed it reproduces the exact reported failure (a permission-denied error scanning a restricted path) against the pre-fix code, and passes after the fix: go test ./clients/ -run TestCommitOnlyNoLocalPath -v Also ran, all passing (one pre-existing, unrelated failure in clients/githubrepo from a missing TOKEN_TYPE env var in this sandbox, reproduced identically on main before this change): go build ./... go test ./clients/... ./checks/... ./checker/... go vet ./clients/... golangci-lint run -c .golangci.yml ./clients/... (0 new issues) Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
pujitha24
requested review from
AdamKorcz and
justaugustus
and removed request for
a team
August 14, 2026 08:27
pujitha24
had a problem deploying
to
integration-test
August 14, 2026 08:27 — with
GitHub Actions
Failure
TestCommitOnlyNoLocalPath was marked t.Parallel(), which let it run concurrently with TestEmptyProject. Both call ListUnfixedVulnerabilities, which invokes osv-scanner's SetLogger, a package-level function that writes to an unsynchronized global. That tripped the -race detector in CI (unit-test, integration-trusted, gitlab-integration-trusted). Dropping t.Parallel() from the new test serializes the two calls and eliminates the race. Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
pujitha24
temporarily deployed
to
integration-test
August 14, 2026 10:37 — with
GitHub Actions
Inactive
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #5180 +/- ##
==========================================
+ Coverage 66.80% 70.12% +3.31%
==========================================
Files 230 252 +22
Lines 16602 15868 -734
==========================================
+ Hits 11091 11127 +36
+ Misses 4808 3856 -952
- Partials 703 885 +182 🚀 New features to boost your workflow:
|
TestCommitOnlyNoLocalPath can't run in parallel (osv-scanner's SetLogger writes to a shared global, tripping the race detector against TestEmptyProject), but the paralleltest linter still flags it. Add a nolint directive with a reason, matching existing precedent in this repo. Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
pujitha24
temporarily deployed
to
integration-test
August 14, 2026 11:36 — with
GitHub Actions
Inactive
pujitha24
temporarily deployed
to
integration-test
August 15, 2026 09:44 — with
GitHub Actions
Inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Bug fix: the Vulnerabilities check crashes for repositories that have no local
on-disk checkout (currently only the GitLab client), because osv-scanner
falls back to scanning the entire filesystem root and hits permission errors
on restricted paths such as
/proc.What is the current behavior?
For clients whose
RepoClient.LocalPath()returns an empty string (onlyclients/gitlabrepotoday),clients/osv.gocallsosvscanner.DoScanwith anon-empty
GitCommitsbut an emptyDirectoryPaths. Ingoogle/osv-scannerv2.3.2 (bumped in v5.5.0, previously v2.2.4), that specific combination makes
DoScandefault to scanning the filesystem root/with the defaultlockfile/sbom/directory extractors, since
osvscanner'sscan()setsrootMap = map[string][]string{"/": {}}whenever no directories were givenbut commits were. On typical Linux hosts this walk hits
/procand failswith a permission error, which scorecard surfaces as a hard check failure:
This makes
scorecard --repo=<gitlab-url>fail entirely unless the callerexplicitly excludes the Vulnerabilities check.
What is the new behavior (if this is a feature change)?
When there's a commit to scan but no local directory,
clients/osv.gonowcreates a harmless empty temporary directory and passes that to
DirectoryPathsinstead of leaving it empty. This prevents osv-scanner'srootMapfrom defaulting to/, while still running the git-commit-basedOSV lookup correctly: osv-scanner's
gitcommitdirectextractor is a"standalone" extractor that returns results purely from the configured
commit list and ignores whatever directory it's associated with, so no
scanning functionality is lost, only the unintended full-filesystem walk is
avoided. The temporary directory is removed after the scan.
Which issue(s) this PR fixes
NONE
Special notes for your reviewer
This works around a behavior change in
google/osv-scannerv2.3.2 (theversion bump landed in scorecard v5.5.0): in v2.2.4, a
GitCommits-only scan(no
DirectoryPaths) was handled by an independent code path that nevertouched the filesystem. v2.3.2 refactored this into the same directory-walk
loop used for lockfile/SBOM scanning, and defaults to
/when no directoriesare supplied. This scorecard-side fix avoids triggering that fallback rather
than changing osv-scanner itself.
Validation performed locally (this repo requires
go test/golangci-lintper
CONTRIBUTING.md; no e2e/live-cluster run applies to this change):clients.TestCommitOnlyNoLocalPath, which callsListUnfixedVulnerabilitieswith a commit and an empty local path. Iconfirmed it reproduces the exact reported failure (a permission-denied
error scanning a restricted path) against the pre-fix code, and passes
after the fix.
go build ./...go test ./clients/... ./checks/... ./checker/...— all pass (onepre-existing, unrelated failure in
clients/githubrepodue to a missingTOKEN_TYPEenv var in this sandbox, reproduced identically onmainbefore this change).
go vet ./clients/...golangci-lint run -c .golangci.yml ./clients/...— 0 new issues(
--new-from-rev=HEADreports 0 issues; pre-existinggoconstfindings inunrelated files are unchanged).
Does this PR introduce a user-facing change?
Fixes #5056