4 ms·
Lock the dependencies: checksums, lock file, “=“ versions, whatever. Even better, store them yourself: cache, mirror, zips in the repo, whatever. This won’t p
by dblotsky 8y ago
Lock the dependencies: checksums, lock file, “=“ versions, whatever.
Even better, store them yourself: cache, mirror, zips in the repo, whatever.
This won’t protect you from an initial hack, but it means that if the dependency was good when you got it, it will stay good.
- eeZah7Ux 8y agoNo. People deploying code must be able to manage vulnerabilities in dependencies by updating them.
- danShumway 8y agoAre you sure you're thinking about this from a Javascript perspective? Vendoring dependencies on a Node project doesn't make it easier or harder for me to update those dependencies later. I run the same commands from the command line either way. It also doesn't make it harder for me to update dependencies of dependencies either -- quite the opposite; I wouldn't advise people to do this, but in an emergency if my dependencies are being tracked via source control rather than fresh-downloaded on every install, I can make security tweaks or change their dependencies, and those changes will actually stick between installs. Even on a website, vendoring my dependencies doesn't mean my dependencies need to be a single blob -- I can still have a dependency deployed as a separately updatable file. Is there a specific scenario you're thinking of where vendoring a JS dependency would prevent someone from updating it?
- dblotsky 8y agoIn the scenario I proposed, nothing stops you from updating your dependencies. It just doesn't happen without your knowledge and consent (unlike the default NPM settings).