Trivy detecting vulnerabilities in yarn devDependencies

[pnu-s]

Hello there!

Trivy seems to detect vulnerabilities in yarn dependencies which are only in devDependencies, although running a yarn audit will exclude them by default and only check in dependencies.

Posting https://yarnpkg.com/en/docs/dependency-types for reference.

I'm wondering whether this is expected.

Thanks for your great tool and I'm available to discuss this in more details.

[krol3]

@pnu-s still happening the issue?

[aroes]

@krol3 I've also experienced this issue. I first noticed a large difference between yarn dependency vulnerabilities reported by Snyk and Trivy, and determined this to be the cause. Snyk solves the issue by scanning package.json as well, and has a --dev flag, off by default to control this behavior. See here: https://support.snyk.io/hc/en-us/articles/360004712477-Snyk-for-JavaScript

Including a similar feature in Trivy would add significant value to node.js reports imo.

[remipelhate]

Looking at the docs, it looks like this is intended behaviour: https://aquasecurity.github.io/trivy/dev/vulnerability/detection/language/. They explicitly state that devDependencies are included in vulnerability scans for yarn.lock. However, they're not included in package-lock.json. I'm quite curious as for why these have been implemented differently. Perhaps a limitation due to the way yarn.lock is structured? Either way, if there is a way to exclude devDeps for yarn.lock, that would be more than welcome :)

[knqyf263]

As far as I know, yarn.lock doesn't have information regarding the package type. In other words, we cannot identify whether the package is devDependency or not. As @aroes said, we might address the issue if we take package.json together.

[timo-klarshift]

As far as I know, yarn.lock doesn't have information regarding the package type. In other words, we cannot identify whether the package is devDependency or not. As @aroes said, we might address the issue if we take package.json together.

I really dont think this is true. If we humans can know it why can trivy not ? You would simply have to check all dependencies in yarn.lock file and see why they are there (eg referenced by other packages, etc) - so a dependency is either there because you referenced it directly in devDependencies or dependencies or because its a dependency of the former. I think this is just a bit of tree traversion to find out if its a dev or not ...

EDIT: I should have read this more closely. You said that its possible when information additionaly is pulled from package.json.
Sorry for the noise :)

[krol3]

I am not an expert Node, but maybe this repository help to understand more about devDependencies.

• https://github.com/snyk/nodejs-lockfile-parser
• https://github.com/snyk/nodejs-lockfile-parser/blob/master/lib/parsers/index.ts#L114

[dachrillz]

A workaround for this that I've used is to run

yarn install --production

since this can prune the yarn.lock

Somewhat awkward in situations where you don't really want to touch the yarn.lock file (e.g. in a build pipeline), but helps if you don't want to get overwhelmed by development vulnerabilities.

Anyone that understands yarn well could correct me here if I'm wrong but one could do something like:

yarn install --frozen-lockfile
yarn install --production

The first one will do your normal check to see if nothing happens to your lockfile while the second one can prune development dependencies.

Like I said, someone that understands yarn better - feel free to tell why this is a bad idea! :)

[mpumford]

Its a bad idea as you don't want to have to modify yarn.lock to remove devDependencies. You need to keep those in the lock file for development usage of the code.
e.g in Typescript/angular projects yarn.lock defines a lot about your build environment and you don't want that changing just because you decide to do a production build for deployment.
In addition to that yarn install --production leaves the lock file alone. All it does is actually stops yarn from installing dev dependencies. They are still referenced in the lock file.