Checkmarx high severity risk for cy.api's yauzl dep

[jprealini]

We are running Cypress 12.8 (planning to upgrade sooner than later) and using this plugin... since a couple of weeks ago our Checkmarx validation started to yell due to a high severity security risk for the "yauzl" package (among others) which is a dependency of cy-api.

What would be the approach to try to solve this? (For cy-api or any other packages.. we are getting high severity risk for other dependencies, most of them are Cypress' deps, but also some of other packages). Try asking Cypress and every npm package developer that has this issues to try to upgrade their dependencies?

I guess that just bypassing or ignoring these kind of warnings in Checkmarx is not an option.

cypress / yauzl @ 2.10.0 cypress / debug @ 3.2.7 cypress-grep / debug @ 4.3.1 cypress / debug @ 4.3.4 cypress / inflight @ 1.0.6

Thanks

[bahmutov]

Open a PR into each project that you want to upgrade with upgraded dependencies Sent from my iPhoneOn Sep 13, 2023, at 08:11, Juan Pablo @.***> wrote: We are running Cypress 12.8 (planning to upgrade sooner than later) and using this plugin... since a couple of weeks ago our Checkmarx validation started to yell due to a high severity security risk for the "yauzl" package (among others) which is a dependency of cy-api. What would be the approach to try to solve this? (For cy-api or any other packages.. we are getting high severity risk for other dependencies, most of them are Cypress' deps, but also some of other packages). Try asking Cypress and every npm package developer that has this issues to try to upgrade their dependencies? I guess that just bypassing or ignoring these kind of warnings in Checkmarx is not an option. cypress / yauzl @ 2.10.0 cypress / debug @ 3.2.7 cypress-grep / debug @ 4.3.1 cypress / debug @ 4.3.4 cypress / inflight @ 1.0.6

Thanks

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jprealini]

Thanks @bahmutov ... and sorry for the dumb question, probably the answer is very obvious, but.. what happens in a case where, for example, a package is using a dependency that's been deprecated? Should I find an alternative package that does the same thing and that is still being maintained, and replace it, do the necessary refactors, and then open a PR? I will suppose that the answer is something like "Well.... if the package owner sees no need to do that, but you do, then do it yourself, propose the change, create the PR, and fix your own problem... " right? :D

[bahmutov]

Really up to you BUT for a testing tool that is not part of your production code the old dependencies do not matterSent from my iPhoneOn Sep 13, 2023, at 13:24, Juan Pablo @.***> wrote: Thanks @bahmutov ... and sorry for the dumb question, probably the answer is very obvious, but.. what happens in a case where, for example, a package is using a dependency that's been deprecated? Should I find an alternative package that does the same thing and that is still being maintained, and replace it, do the necessary refactors, and then open a PR?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>