From dev to production: How do you generally handle npm audit flags marked "high" or "critical" severity?

Developers Client dev
#1

I wanted to ask the community for comments, guidance and experiences regarding the “npm install” step in the developer guide, please.

Specifically, how are you handing cases where the given npm installation provides or invokes modules which are flagged by npm audit as “high” or “critical” in severity?

<ASIDE>I realize that these flags will frequently be present in development branches,  or may exist generally for development reasons.  In a pure development context, lowered security and greater risks are accepted---devs often strive first for compatibility with modern components.</ASIDE>

I am especially interested to hear from folks who are adopting and/or customizing Jitsi (perhaps “downstream”) for organizational, production use cases (such as the classroom).

  • Do you take some steps to mitigate these flags? What and how?
  • Would you mind sharing your experiences?

Without pointing to specific examples, I feel that locally patching or force-fixing any flagged npm modules (e.g. with more their more-stable versions) would result in builds that are not comparable with the public release. So practical testing and functional equivalence (as compared with the public release) would be lost.

  • Is there a process or workflow that works well in your scenario?

Thanks to all for sharing any insights, and thanks to the Jitsi developers who’ve made the software open and accessible.

#2

I personally go through them one by one to make sure they are in need of action. If they are just noise, I postpone “fixing” them, since sometimes they are a transitive dependency and hard to do.

#3

Thanks for the kind feedback @saghul!

So, just to be sure I understand properly, is that a pre-release step or practice, prior to publishing any publicly-available client version?

@damencho mentioned elsewhere that the public meet.jit.si service is (understandably) customized, and secured/audited company internally. (e.g.) Security audit? —so I’m also thinking that you’re saying you personally supervise and make decisions in the deployment steps, prior to public consumption.

Am I understanding your workflow properly?

Thanks again for helping the community so much.

#4

I mean I do that as my usual dev workflow, in case I see new alerts popping up, either on the GH UI or on the npm CLI.