Why
There have been a number security incidents with regard to the security of dependencies, to cite a few:
It's often recommended to use a package-lock.json for mitigation. However this approach is limited:
- While a
package-lock.json file 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 in package.json. A shrinkwrap.json file can help to resolve the former, as well as bundling the dependencies using bundleDependencies. However then there is the case that dependencies should be deduplicated, and that shrinkwrap.json file would no-longer be relevant.
- A
package-lock.json and shrinkwrap.json do 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 a package-lock.json can 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
sha1 for 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
Why
There have been a number security incidents with regard to the security of dependencies, to cite a few:
It's often recommended to use a
package-lock.jsonfor mitigation. However this approach is limited: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.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.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