Ok, I'm gonna try and surf the wave of publicity resulting from Dan Abramov's recent post and its discussions.
It's 10PM and English is not my first language, so... hold on to your grammars.
Let me address the elephant in the room too. Or talk about how I'm working to address it.
I've encountered the npm audit fatigue just days after the audit feature was released. It was on a Node.js project. (ok, 20+ of them at once)
It resulted with the first version of npm-audit-resolver
If you want to know how npm-audit-resolver came to life, I've told the story in this recording:
OpenJS World 2021 pkg vuln talk
apologies for the quality of my webcam
The video introduces Package Vulnerability Management & Reporting Collaboration Space.
Actually, I recommend you stop reading and watch a bit of it now.
What I want to talk about here is the ideas for the future of npm-audit-resolver.
And that future is tightly bound to the Package Vulnerability Management & Reporting Collaboration Space, I hope.
Let me give you a quick summary
- it's an interactive tool that asks you what to do with each vulnerability
- lets you ignore vulnerabilities with surgical precision
- helps maintain a culture of caring about security by reducing annoyance (not enough yet)
- maintains a json file with your decisions
npm auditfor running in CI and applies your ignores
- supports yarn too
- npm7 support on its way (I'm working with npm folks on some details)
I intend to donate the JSONSchema of the
audit-resolve.json file to OpenJS Foundation. When it's ready :)
The format evolved a bit already, but I also need to adapt it to the new usecase of sharing.
The new usecase for
audit-resolve.json is sharing decisions.
Imagine an internal security team publishing a file with recommendations what to safely ignore that shows up as suggestions or can be applied automatically.
How about a central location to manage shared decisions across projects?
Ok, now the best part - security influencers!
Jokes aside, package maintainers could publish ignore lists for the dependencies of their package when they did the research to verify the package is not affected.
Such lists could be aggregated into recommendations maintained by security professionals.
The plan is to make the default
npm audit command take the file into account. I've extracted the core from npm-audit-resolver so that anyone can embed it in their tooling.
It's not much, it's not 100% ready, but it's doing basic work for you.
I hope yarn, pnpm, snyk and so on would eventually understand the format.
These ideas are just my ideas. I'm hoping to see them shaped by real data and feedback and discussions in the Collab Space.
Please participate in the Collab Space.
Please try npm-audit-resolver
Please don't get demotivated - try caring about security at least to the point of ignoring the vulnerabilities one by one ;)
Hey, did you watch the OpenJsWorld video already?