Migrate from nsp to snyk

[doug-wade]

We do security auditing as part of our build, which is a good thing! However, most of the time, when the build breaks due to a security issue, the problem is in a transitive dependency, and we have to work with our dependencies to pull the good version up through the stack of dependencies and into our closure. This process takes time, and in the meantime, we publish a manifest of attack vectors that you could use to attack a React Server instance, which has the effect of making React Server less safe, rather than more safe.

Fortunately, the great people at Snyk have provided a better mechanism whereby they produce patches to fix the vulnerability until the good version makes it into our dependency closure. This will make us more secure, while also documenting what work there is still outstanding in the community to remove the patch.

[doug-wade]

I chatted with @drewpc about this a bit, and there are a couple of other problems with our approach to auditing our dependencies. The first one is that it is unclear how this will work with asini hoisting -- both nsp and snyk use the dependencies that are checked out on disk to try to figure out if there are vulnerable packages in the dependency closure, and asini moves them out of their respective node_modules. We may be able to circumvent this by testing the root node_modules, and all the distributed node_modules, but for now it is somewhat unclear.

The second is that security failures appear on unrelated pull requests, which is frustrating for contributors. What happens is that a security issue appears on their pull request, someone else has to commit something, and then they have to rebase.

To resolve these, we'll need to figure out something more than just switching providers; maybe our security auditing should be offline like our dependency upgrades?