This is a question for software engineers who are tasked with managing the development cycle for a Web application using NPM packages for deployment on a customer's Intranet or the Internet.
This is not about what could theoretically be done managing security risks but what you are actually doing when bringing a commercial Web app to market.
If you think that you have good procedures in place to manage security risks, then please share your knowledge!
The answer should ideally outline the steps taken at various points in the development cycle. Example only, not exhaustive:
- Before we opt to install a package we assess trustworthyness. We [also review][do not review] secondary dependencies.
- We have selected developments tools [React][Angular][etc.] because [any security considerations][just developer preference]
- We [disable][do not disable] scripts when installing packages and we do this [...]
- Before production or development packages are accepted for wider use we do [...]
- For installed packages we monitor for vulnerabilities [by running
npm auditevery x days][by subscribing to monitoring service x][by using tool y]
- For any vulnerability found we do this [...]
- We [accept][do not accept] these vulnerabilities in dev packages [...]
- We [accept][do not accept] these vulnerabilities in production packages [...]
- When testing we [do][do not] monitor for network activity, CPU usage, and we also test [...]
- For release, vulnerabilites [are][are not] acceptable if [...]
- Also [...]
The sections below elaborate a bit more on the subject and specific concerns.
webpack, React and Jest, then you may be able to select a few "must have" and a few "wanted" NPM top level packages. But even when these are carefully chosen, there will usually be hundreds if not thousands of secondary, tertiary, etc., dependencies dragged in that fall outside of the "carefully chosen" realm and it is impossible to keep track of security and quality for all of them.
npm audit will show vulnerabilities and it may be possible to get these to zero at least for the production code. But often interdependencies prevent an outright update of all packages, even when prepared to adapt for breaking changes. That means that, at least for the dev dependencies, vulnerabilities may remain and each vulnerability should be carefully considered before allowing development to continue. This could become a time consuming task as changes can be frequent.
I'm aware that there are commercial offerings that may assist in managing vulnerabilities but I have no experience with those.
Within the current software landscape of 2022, and with cybersecurity on everybody's mind:
If you are developing web applications commercially using NPM packages, what do you do to reduce risks?
In other words:
How do you setup your tool chain and manage the development cycle securely in a commercial setting where there are constraints on time and money?
Following the comment by @Flater, I'd like to elaborate on what I consider 'risks'.
My concern would not be breaking the build or breaking functionality due to altered behavior (i.e. unintended bugs in the package). The former is obvious and the latter should be caught during product testing.
Firstly, there is a risk of infecting the developer machine with malware; this could be ransomware or some other destructive software, i.e. software that deletes files randomly and spreads across the network. Would you install each NPM update onto an isolated machine and observe for x hours or x days before the update can be considered secure for deployment on developer machines? That's probably not workable. Use some third party tool that must flag the NPM package as secure? Which tool and how would that work? Update first onto a virtual machine then run the tool for a scan? Or trust that someone else would have discovered any misbehavior of NPM packages and simply run the update? Any other approach?
Secondly, there is the risk of delivering malware to the customer, i.e. hidden bitcoin miners, adware, spyware, possibly even Web apps that attempt to exploit browser vulnerabilities. Do you monitor the Web app for a while as part of the testing regime, for example running in the browser while monitoring network activity or looking out for "unusual behavior"? Do you monitor browser CPU usage as part of your testing?
Thirdly, less severe, there may be unwanted 'pings' (i.e. downloading an icon via CDN rather than locally) or other 'phoning home' incidents (i.e. usage monitoring) originating from packages that you may otherwise consider trustworthy. These could be something simply forgotten by the author or it is documented "somewhere" that this is expected behavior unless this or that configuration parameter is set. Web apps that are deployed onto Intranets of security conscious customers would question these incidents flagged by their firewalls. Although this may not turn out to be a security risk per se, random attempts to contact the Internet may be a risk to your reputation. Again, do you monitor network activity in a browser to ensure that no unwanted Internet contact is established? If there is contact from what you consider a trustworthy package, would you halt the release? Or add it to the release notes to explain it away and prepare to answer awkward questions asked by customers? Any other steps taken?
I realize that businesses and budgets for software testing and quality assurance vary greatly. So assuming you are not NASA and must remain competitive, what steps does your business take to minimize the above risks? Is there a "best practice" when it comes to NPM with it's unique authoring and delivery mechanisms, fit for 2022?
If you are downvoting then please comment why so that I can learn from it.