You said that the lockfile is not shared when published. Do you refer to publishing to npm, or GitHub (which would be pushing to be entirely correct)? Either I think you misunderstood the idea of a lockfile (the GitHub case), or I learned something new (npm case)! I assume it's the npm case, I just want to explicitly ask for confirmation about it. :)
Actually I think devDependencies can have quite big security implications. Of course if you manage your local permissions for files and what-not correctly and without mistakes, you shouldn't have any issues. But one mistake and a bunch of bad luck, and one might get their hands on SSH keys, or other keys that are stored on the device (or just other files containing sensitive data, like that ID scan you did to send in some document to the government or whatever). While devDependency security might not be relevant for the end-user (could be, if it reveals some important password/key) it can be relevant to you directly.
During install Yarn will only use the top-level yarn.lock file and will ignore any yarn.lock files that exist within dependencies. The top-level yarn.lock file includes everything Yarn needs to lock the versions of all packages in the entire dependency tree.
Indeed, lock-file is necessary for a final project but not for a dependency,
I mentioned it in For npm package maintainers section. Let's say nuxt if has a vulnerable dependency (locked by lock file in nuxt repo) they should explicitly bump it. Updating the lock file is not effective for end-users. Also, end-users can bump all dependencies up to the specified range by using yarn upgrade. This means it is not necessary to nuxt (but recommended) to even publish a new version. Your NPM dependency tree is self-healing thanks to semver ranges and lock file for nuxt is just for nuxt development.
About (2), we can categorize vulnerabilities into two categories:
a. Security bugs like a DDOS or Memory leak which can be possibly abused by hackers
b. Intentional malicious code published by one of the dependencies
Actually, you are certainly right about the case (b) but the fact is that GitHub security alerts are mainly for (a) and for case (a) devDependencies are not used for production but internal stuff or building project. If webpack uses lodash which is potentially vulnerable to a DDOS attack it is not a security concern.
For case (b) which is rather rare but really bad, it is the responsibility of NPM security team to unpublish them from registry as soon as possible! GitHub alerts are for public disclosures. Not even this is not GitHub's job when they make us aware is probably too late and they can almost do nothing. Such a vulnerable package should be removed from NPM CDN as soon as possible before anyone downloads it.
Chiming here again since the nuance of yarn upgrade or npm upgrade wouldn't impact your nested dependencies. So for example, if nuxt brings in a vulnerable version of say debug module, doing a yarn upgrade will not upgrade debug. Only if nuxt is up to date with its package.json manifest to bring in a fixed version of debug, then upgrading nuxt will fix the issue.
Thanks for this post!
I have two things that I want to talk about:
Just my thoughts. :)😇
About (1), Referring to Yarn docs:
Indeed, lock-file is necessary for a final project but not for a dependency,
I mentioned it in
For npm package maintainerssection. Let's saynuxtif has a vulnerable dependency (locked by lock file in nuxt repo) they should explicitly bump it. Updating the lock file is not effective for end-users. Also, end-users can bump all dependencies up to the specified range by usingyarn upgrade. This means it is not necessary to nuxt (but recommended) to even publish a new version. Your NPM dependency tree is self-healing thanks to semver ranges and lock file for nuxt is just for nuxt development.About (2), we can categorize
vulnerabilitiesinto two categories:a. Security bugs like a DDOS or Memory leak which can be possibly abused by hackers
b. Intentional malicious code published by one of the dependencies
Actually, you are certainly right about the case (b) but the fact is that GitHub security alerts are mainly for (a) and for case (a) devDependencies are not used for production but internal stuff or building project. If webpack uses lodash which is potentially vulnerable to a DDOS attack it is not a security concern.
For case (b) which is rather rare but really bad, it is the responsibility of NPM security team to unpublish them from registry as soon as possible! GitHub alerts are for public disclosures. Not even this is not GitHub's job when they make us aware is probably too late and they can almost do nothing. Such a vulnerable package should be removed from NPM CDN as soon as possible before anyone downloads it.
Chiming here again since the nuance of
yarn upgradeornpm upgradewouldn't impact your nested dependencies. So for example, if nuxt brings in a vulnerable version of say debug module, doing a yarn upgrade will not upgrade debug. Only if nuxt is up to date with its package.json manifest to bring in a fixed version of debug, then upgrading nuxt will fix the issue.I wrote in the past a more elaborate post about making sense of package lockfiles if it helps: snyk.io/blog/making-sense-of-packa...