Open AmalChandru opened 4 days ago
@AmalChandru Thanks for reporting this. Lets talk about [1] first.
I tried running
vet scan --purl pkg:npm/metrics-monkey@1.0.2 --transitive --filter 'true'
This tells me the package and its transitive dependencies (upto a certain depth). I don't see any vulnerabilities reported by vet
. Can you share how you identified "known vulnerabilities" in this version of the package?
When I run the same command but with our default policy, I do see some violations:
vet scan --purl pkg:npm/metrics-monkey@1.0.2 --transitive --filter-suite ./samples/filter-suites/fs-generic.yml
At this point, I am not sure how to check the known vulnerabilities for pkg:npm/metrics-monkey@1.0.2
because I don't see anything on deps.dev
or osv.dev
. Can you help?
I believe my choice of the term "known vulnerabilities" might have caused some confusion. What I intended to highlight is the major version drift in the direct dependency (can pose a security vulnerability), which is already being detected by Vet. As shown in Fig. 2, it's indicating that one library is out of date due to a major version drift in the direct dependencies.
Description:
I was playing around with Vet locally and encountered a couple of issues when scanning one of my npm libraries:
1.0.2
. However, when scanning with that version, no vulnerabilities or issues were detected, despite known security vulnerabilities. Ideally, when the latest version of a package is provided, it should run and display results in the CLI. Is this expected behavior? [fig:1]11.0.0
(which doesn’t exist), the system suggested updating to1.0.2
, even though11.0.0
is not available. Ideally, Vet should flag an invalid version as feedback. Shouldn’t it? [fig:2]Steps to reproduce:
vet scan --purl pkg:npm/metrics-monkey@1.0.2
vet scan --purl pkg:npm/metrics-monkey@11.0.0
1.0.2
.Expected behavior:
Screenshots: