search

xeroxinteractive / jest-package-audit

Filter and retry yarn/npm audit command with Jest.
https://www.npmjs.com/package/jest-package-audit
MIT License
2 stars 1 forks source link

Allow not yet patched vulnerabilties #347

Closed northvik closed 2 years ago

northvik commented 4 years ago

I think this package could have an option that would ignore vulnerabilities that don't have a patch. example:

Low: Prototype Pollution
Package: lodash
Patched in: No patch available
Dependency of: jest [dev]
Path: jest > jest-cli > @jest/core > jest-runtime > jest-config >
      jest-environment-jsdom > jsdom > request-promise-native >
      request-promise-core > lodash
More info: https://npmjs.com/advisories/1523

In that example, you can see that this vulnerability have no fix at that point in time Patched in: No patch available, which mean that the audit test would fail. The solution, in that case, would be to add lodash tot the list of allowed packages, but if in a few days there is a patch that is published, then it wouldn't be caught by the audit test next time it's run.

What I propose is an option like patchedOnly: true that would ignore the vulnerabilities that are not patched, and put them in a separate list. This would result in a passing test, and it could also print out that non-patched vulnerability list so that the user is aware of it.

thank you very much for that amazing package.

AndrewLeedham commented 4 years ago

Hi @northvik thanks for reaching out. My concern with this feature is this: say a dependency has a critical vulnerability but no patch, this option would suppress said vulnerability and the build might end up in production. Whereas with the current flow, it would stop the deployment and you would have to manually allow the package through, meaning you can review if the issue actually affects your code.

If you feel this is still a feature you need, I think I would rather have the allow option take a function that is passed the data for each table and then you can return a boolean which determines if the package is 'allowed' or not. Then you can implement this feature and any other type of checking as you see fit :)

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 4.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

AndrewLeedham commented 2 years ago

@northvik You can now pass a function to allow in jest-package-audit@4.0.1.