Well, this: https://www.npmjs.com/package/npm-audit-resolver
I’d like to contribute this interactive tool as an extension or alternative to npm audit fix.
Background (feel free to skip)
I’m a leader / solutions guy in a team that frantically churns out new integrations written in Node.js and various front-end stacks. There’s 21 of them already. We tend to have to focus on new apps but we revisit most of them every X months, so it’s best that we keep them all well maintained. I’m at the point where I write tools to automate making configuration changes to all projects at once.
These apps tend to have diverse sets of dependencies, with quite a few being shared across the board. Recently, when some new vulnerabilities got published, all builds went red and we didn’t have obvious fixes for some of the issues. We considered the option to ignore advisory numbers, but some of the issues in our test dependencies (which we don’t ship to production servers at all) were the kinds that we’d never allow in our production dependencies. So that option’s out.
At first, when using nsp check, I used to spend a day to go through all of the apps and apply all the fixes. With scripts iterating over repositories it got a bit better, but I badly needed the tool I want to discuss here.
My case is on the extreme side, but it makes it easier for me to identify the needs.
What I’d like to suggest/contribute is:
- interactive CLI tool to speed up making and applying decisions
- audit-resolv.json (or a section in package.json) to store the decisions
- ability to postpone, ignore, remember fixed - all recorded for specific paths and issues, so the same issue found elsewhere would not get ignored
- tools to help out when a fix is not yet known (action:review cases)
As for the action:review, take a look at the “investigate” option in the resolver. Currently, while the implementation is still quite naive, it’s capable of finding the package which would have to bump their dependency to fix the issue. It can also identify when a newer version of a package doesn’t have the vulnerable dependency anymore, which npm audit doesn’t seem to notice as a possible fix.
Performance and future-proofing of this tool would be better if it was built into npm, so here I am.
- I might need someone to help me get started and suggest where this code would go based on your conventions.
- I’m hoping to discuss this and I’m looking forward to confronting this with your WIP features and ideas, also sharing my perspective on security maintenance at a team where the apps count is 5 times higher than developer count.