sbassett added a comment.
In T249039#6322813 <https://phabricator.wikimedia.org/T249039#6322813>, @Lucas_Werkmeister_WMDE wrote: > I looked at these earlier and thought they all looked like false positives Great, thanks for confirming and for your detailed analysis, with which I concur. I'll change this to a risk rating of: {icon smile-o color=sky} **none**. > but I seem to have lost access to the paste now for some reason, so I can’t say for sure. This was due to some mitigations for a non-issue (T258239 <https://phabricator.wikimedia.org/T258239>), the referenced pastes should now be viewable to you. In T249039#6323388 <https://phabricator.wikimedia.org/T249039#6323388>, @Pablo-WMDE wrote: > There recurringly are and recently were efforts to get those numbers down, maybe a recheck (e.g. after sha 5f1d7d106f47dbe7738efb788144d7f2fe391f39 <https://phabricator.wikimedia.org/rEWBA5f1d7d106f47dbe7738efb788144d7f2fe391f39>) is all it takes to find more acceptable counts (is 0 the success criterion?). > This is a moving target, however. At WMDE we are in the process of finding a structured workflow (for the products' and the developers' sake) which prevents those counts climbing again. A push on T228527: Support nested package.json files <https://phabricator.wikimedia.org/T228527> from people with an official security hat would be of great help to make this happen in (ever more popular) monorepos. 0 is of course ideal, though likely not realistic. As noted within the review, outdated packages by themselves, without any additional mention of specific security vulnerabilities, would have a risk of: {icon check-circle color=green} **low**. Per the risk acceptance chart within T249039#6309061 <https://phabricator.wikimedia.org/T249039#6309061>, these issues can be addressed outside of any timeline and the risk is automatically accepted without managerial+ approval. I'm also hopeful that we'll have better automated security monitoring in place both as stand-alone solutions and within CI in the near future. Though that work is likely not to be completed for a while and so we try to call out such issues during manual security readiness reviews when prudent. > I believe this is a false positive. TinyColor (which we depend on via @storybook/[email protected] > [email protected] > tinycolor 1.4.1) does contain a copy of jquery 1.9.1 for its own demo <https://github.com/bgrins/TinyColor/tree/ab58ca0/demo> page, but it is not part of its package, and consequently not loaded in the bridge product. Ok, I'd barely call that a dev dependency then, so the risk would be: {icon check-circle color=green} **low**. Given the volume of issues returned by `npm audit` and `snyk test`, and that while such packages might not be directly deployed to wikimedia production hardware, they are still likely used during critical doc, test and build stages and I would still rate the overall risk at {icon exclamation-triangle color=yellow} **medium**. This risk can be accepted by a manager (I assume @darthmon_wmde) and a risk plan could be as simple as committing to review vulnerable dependencies for security updates within 30 days (for which there obviously //may// or //may not// be updates.) TASK DETAIL https://phabricator.wikimedia.org/T249039 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: sbassett Cc: WMDE-leszek, sbassett, Addshore, Michael, Lucas_Werkmeister_WMDE, Tonina_Zhelyazkova_WMDE, Pablo-WMDE, Lydia_Pintscher, Aklapper, darthmon_wmde, Akuckartz, Dsharpe, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Bawolff, Mbch331, Legoktm
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
