The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
npm audit ripple effects
On Feb 16, 2018 jonschlinkert fixed a regexp bug in the then current version of his braces package.
One year later, on Feb 15 2019, someone reported this old bug as a security issue to npm. Advisory 786 was issued which triggered
npm audit warnings across a huge set of packages, including Jest 23, which is used by the latest create-react-app. See their issue. Since upgrading to Jest 24 requires work that takes time to complete, their users have now been seeing the npm audit message (which reports the same vulnerability on no less than 63 paths!) for almost 2 weeks. Since the vulnerability lies in Jest (a testing framework), there appears to be no real vulnerability in the sense that production services could be affected by this ReDoS vulnerability.
However, numerous CI processes are affected, as are - for instance - the students in my class to whom I recommend create-react-app and who now wonder what kind of software has 63 vulnerabilities out of the box.
In my opinion, this state of affairs is unsatisfactory. A low-level vulnerability that has been known for over 1 year and which has not had adverse effects does not need to be displayed to tens of thousands of ordinary developers overnight.
This process should be thought over and changed. As is, it’s just one more example where technical complexity adds (IMO unnecessary) cognitive load. It also has the potential to reduce people’s trust in
npm audit if they perceive it as crying wolf.
I do not have the expertise to make constructive suggestions as to how to address this issue. Perhaps what is needed is some way to get package developers’ attention before the npm audit registry flags low-level issues such as this to the general public. If they haven’t addressed the low-level issue within a grace period, it could still be flagged the way it’s now. I assume that npm advisories have some kind of human review and aren’t added automatically, so judgement could be exercised.
I encountered the same thing on my Create React App project. It really is a pretty awkward combination of dependencies and breaking-change upgrades, such that Create React App can’t resolve it without releasing a breaking-changes upgrade of their own (or getting a semi-dormant sub-sub-dependency to release an update for a no-longer-updated obselete major version).
Because it’s a low-impact bug with a high-effort fix, we’re content to ignore it for now, but
npm audit does not make it easy to ignore. So I suggest there could be some improvements on that front:
- Better de-duping of the
npm auditoutput. It would be more useful if the default output said “1 vulnerability, in the dependencies of 63 packages”, rather than 63 separate redundant messages.
- An “ignore known issue” functionality. On our project we’ve begun using the audit-filter package for this, but it’d be good to have this ability directly in
In the linked Create React App issue, there is a discussion on the merits of using
npm audit as part of your continuous integration.
On the one hand, it’s useful to get notified of security problems. On the other hand it’s not necessarily good to block development because
npm audit fails.
An alternative approach would be something like Symfony Security Monitoring, which will notify you of issues without you having to run your continuous integration pipeline. That way, you can continue developing without being blocked by
npm audit failing.
I wanted to add this because, at the end of the day, what we really care about is having secure software. And monitoring may be a better approach than auditing in continuous integration.
For the “keeping decisions” part there’s