Closed
Description
Why
There have been a number security incidents with regard to the security of dependencies, to cite a few:
- https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes
- https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
It's often recommended to use a package-lock.json for mitigation. However this approach is limited:
- While a
package-lock.jsonfile ensures integrity it only applies to cases in which the dependencies are installed from the root of a package, and not when that dependency is added to an existing package as a dependency inpackage.json. Ashrinkwrap.jsonfile can help to resolve the former, as well as bundling the dependencies usingbundleDependencies. However then there is the case that dependencies should be deduplicated, and thatshrinkwrap.jsonfile would no-longer be relevant. - A
package-lock.jsonandshrinkwrap.jsondo not apply to upgrading a dependency, to which is another opportunity for a dependency to underhandedly include some malicious code. And considering that many changes to apackage-lock.jsoncan be fairly large, it's very likely that those changes actually do not get the review that is necessary. - There is still a fair amount of use of standard
sha1for integrity, which has been considered insecure for quite some time. These risks can be mitigated with using sha1 collision detection as being used with git.
To mitigate risks with dependencies, supporting signed releases can reduce the surface area of attack and that a dependency has been released by the intended release maintainer of a dependency. Given that many releases are already being signed with git, this is already part of a release maintenance process and could be supported with minimal changes.
How
I've researched a solution that will work today using existing signed git tags. To illustrate this, I've implemented that functionality at: https://github.com/braydonf/gpk