trivy: NPM v7 lockFileVersion = 2 is not supported in Trivy filesystem scan
Description
we have NPM7 generated package-lock.json with lockFileVersion = 2. Now when we scan Node.js project using Trivy filesystem scan, Trivy does not find out packages from package-lock.json. It is working with lockFileVersion = 1
What did you expect to happen?
It should find out packages in package-lock.json
What happened instead?
It did not find out packages from package-lock.json
Output of run with -debug:
trivy -d fs 1/ 2021-11-01T11:46:05.190+0530 DEBUG Severities: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL 2021-11-01T11:46:05.216+0530 DEBUG cache dir: /root/.cache/trivy 2021-11-01T11:46:05.216+0530 INFO Need to update DB 2021-11-01T11:46:05.216+0530 INFO Downloading DB… 2021-11-01T11:46:06.602+0530 DEBUG asset name: trivy.db.gz
2021-11-01T11:46:09.851+0530 DEBUG Vulnerability type: [os library] 2021-11-01T11:46:09.863+0530 DEBUG OS is not detected and vulnerabilities in OS packages are not detected. 2021-11-01T11:46:09.863+0530 DEBUG Detected OS: unknown 2021-11-01T11:46:09.863+0530 INFO Number of language-specific files: 0
ls -ltr 1/
-rwxr-xr-x 1 root root 575977 Oct 29 17:39 package-lock.json
cat 1/package-lock.json |head { “name”: “jhipster-public-wesite”, “lockfileVersion”: 2, “requires”: true, “packages”: { “”: { “name”: “jhipster-public-wesite”, “devDependencies”: { “browser-sync”: “2.27.5”, “gulp”: “^3.9.1”,
(paste your output here)
Output of trivy -v:
Version: 0.20.2 Vulnerability DB: Type: Full Version: 1
(paste your output here)
## Additional details (base image name, container registry info...):
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 24 (5 by maintainers)
@ShubhamPalriwala My personal expectation is that this table wouldn’t be different for the different commands https://aquasecurity.github.io/trivy/v0.30.4/docs/vulnerability/detection/language/.
Instead, users would be able to specify
--ignore-dev-dependenciesand literally everything would be scanned consistently across the board.I suppose, as a stretch goal, you would be able to disable/enable specific scanning engines easily. The experimental
regocapability might do this but I don’t know that I’d call that “easy”.Yep, I also had similar ideas about the
--ignore-dev-dependenciesflag to make it consistent across different languages. That would make the ecosystem easy to use and pretty uniform.I do not know much about the
regocapability/ other scanning engines; hence, I think that can be implemented once the initial part is implemented and perfectly working.What do you say?
Just had the same issue. A scan with trivy repo gave me a list of vulnerabilities while trivy fs didn’t.
It would be nice to have the same behaviour across the commands. In the spirit of
--ignore-unfixed, a--ignore-dev-dependencies(or anything with a better name) would be great.Thanks for assigning me this
@rahul2393 Could you take a look at this issue?