Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Auto-sync vulnerability data before scan#132

Merged
andrew merged 1 commit intomainfrom
vulns-scan-auto-sync
Feb 27, 2026
Merged

Auto-sync vulnerability data before scan#132
andrew merged 1 commit intomainfrom
vulns-scan-auto-sync

Conversation

@andrew
Copy link
Contributor

@andrew andrew commented Feb 26, 2026

Ref #131.

vulns scan in cached mode queries stored vulnerability data, but if no sync has been run the database is empty and scan reports "No vulnerabilities found" — a false negative.

Now scan automatically syncs before checking cached data. The existing 24-hour cache means repeated scans don't re-fetch everything.

Changes:

  • Extract sync logic into syncVulnerabilitiesForDeps shared by both runVulnsSync and runVulnsScan
  • Call sync from scan before the cached path (skipped for --live and --no-sync)
  • Add --no-sync flag for CI or offline use where the database is already populated

vulns scan in cached mode queries stored data, but if no sync has been
run the database is empty and scan reports no vulnerabilities found.

Extract the core sync logic into syncVulnerabilitiesForDeps so both
runVulnsSync and runVulnsScan can call it. The scan command now syncs
automatically before checking cached data, using the existing 24-hour
cache to avoid redundant fetches.

Add --no-sync flag for CI or offline use where the database is already
populated.
scanCmd.Flags().StringP("severity", "s", "", "Minimum severity to report: critical, high, medium, low")
scanCmd.Flags().StringP("format", "f", "text", "Output format: text, json, sarif")
scanCmd.Flags().Bool("live", false, "Query OSV directly instead of using cached data")
scanCmd.Flags().Bool("no-sync", false, "Skip auto-sync and use only cached vulnerability data")
Copy link

@ashokfaire ashokfaire Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if something like --sync might also be useful, to ask it to necessarily sync before running.

(As opposed to needing to explicitly run … vulns sync before running the scan, but maybe if someone wants that should they be using --live instead?)

I'm particularly concerned with the case that the cached vulnerabilities don't cover some newly added vulnerability (or if I'm running this in CI, that I won't know whether there are new things versus whenever the cache was synced). But I haven't read the code in detail, so maybe that's already checked somewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR covers that use case already, --live will ensure it checks OSV every time rather than using a cache (up to 24 hours). Triggering sync before hand will only do anything if the cache is empty or valid.

@andrew andrew merged commit 95fb8ec into main Feb 27, 2026
4 checks passed
@andrew andrew deleted the vulns-scan-auto-sync branch February 27, 2026 10:22
miketheman added a commit to miketheman/git-pkgs that referenced this pull request Mar 2, 2026
With the added automatic sync behavior introduced in git-pkgs#132, we can now
experience the latency when the vulnerability data isn't cached.

This refactor does a few things:

- Add test coverage for `syncVulnerabilitiesForDeps` by extending the
  signature to accept an injected `source` database instead of having to
  instantiate inline
- Batch-collection of vulnerabilities in groups of 20 to speed up total
  execution time for large volumes of dependencies
- Console progress updater while downloading so the user gets some
  visual feedback

Signed-off-by: Mike Fiedler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants