5 ms·

I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount o

I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable. It seems like every week there is a new security high sev ticket to fix some webpack dependency. Not to mention that even if you do successfully run “npm audit fix” (—force), Npm may not update to the correct new version and will often downgrade packages many many many versions. The error messages that Npm spits out have always frightened junior devs too. I can’t wait for that whole ecosystem to be replaced.

sensanaty 1y ago
The crazy thing is that `npm audit` doesn't even list `stylus` here, at least not in my repos. Despite them literally overtaking the damn package on the registry for a *security issue*.
- righthand 1y ago
  It gets even better, Dependabot will spam you severities of it’s own that don’t appear in audit. So you probably need to carefully audit the changes from two data sources and the security ticket ends up being 2+ merge requests.
vdupras 1y ago
I have a question. I'm curious. I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn. ... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor. Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere? Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?
- righthand 1y ago
  No the biggest churn involved is now I’m another engineer that prefers to stay away from using, developing on, and recommending javascript platforms. To your point I think you will find most companies stop at the upgrade high sev packages step and do not have any requirements or churn related to checking for fallout from sevs.
  - vdupras 1y ago
    That's what I suspect as well, but this means that we can assume that there's a giganormous amount of development machines being compromised around the world. If you're a gig worker, you might be exposing your other customers, including those with okay security practices. It seems crazy to me that there's this ostrich culture about security. I'm guessing the vibecoding fashion doesn't help. Supply chain attacks can only grow exponential from there, flee for your lives.
- rester324 1y ago
  I think this would be a fair assessment, if the security advisory would be true. Since it's most probably false, the implications you refer to remain hypothetical, while the cost of cleaning up after npm's decision are measured in real M$s. And I think that's the real issue here. I am not saying that we should give up on security altogether, but now there is so much toil attached to managing security, compliance and such aspects of the development lifecycle, that at some point managing all these aspects will outweigh all productivity a dev can bring to the project. It's admittedly a hyperbole, but at that point the whole development procedure would simply become a pointless exercise without any benefit to anyone.
  - vdupras 1y ago
    So I understand that in NPM world, spurious security advisories are common and that the tooling will constantly have you run "fix" commands without real reasons? That's bad and it would explain this lax security culture oozing from it. So the damage is already done, and real security problems will never be properly addressed. One must come to the conclusion that NPM has to be avoided at all cost if security is a concern at all. Additionally, one must make sure that when onboarding a developer coming from the NPM world into a sane project, they have to be properly de-conditioned with regards to security advisories.

sensanaty 1y ago

The crazy thing is that `npm audit` doesn't even list `stylus` here, at least not in my repos. Despite them literally overtaking the damn package on the registry for a *security issue*.

righthand 1y ago
It gets even better, Dependabot will spam you severities of it’s own that don’t appear in audit. So you probably need to carefully audit the changes from two data sources and the security ticket ends up being 2+ merge requests.

vdupras 1y ago

I have a question. I'm curious. I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn. ... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor. Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere? Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?

righthand 1y ago
No the biggest churn involved is now I’m another engineer that prefers to stay away from using, developing on, and recommending javascript platforms. To your point I think you will find most companies stop at the upgrade high sev packages step and do not have any requirements or churn related to checking for fallout from sevs.
- vdupras 1y ago
  That's what I suspect as well, but this means that we can assume that there's a giganormous amount of development machines being compromised around the world. If you're a gig worker, you might be exposing your other customers, including those with okay security practices. It seems crazy to me that there's this ostrich culture about security. I'm guessing the vibecoding fashion doesn't help. Supply chain attacks can only grow exponential from there, flee for your lives.
rester324 1y ago
I think this would be a fair assessment, if the security advisory would be true. Since it's most probably false, the implications you refer to remain hypothetical, while the cost of cleaning up after npm's decision are measured in real M$s. And I think that's the real issue here. I am not saying that we should give up on security altogether, but now there is so much toil attached to managing security, compliance and such aspects of the development lifecycle, that at some point managing all these aspects will outweigh all productivity a dev can bring to the project. It's admittedly a hyperbole, but at that point the whole development procedure would simply become a pointless exercise without any benefit to anyone.
- vdupras 1y ago
  So I understand that in NPM world, spurious security advisories are common and that the tooling will constantly have you run "fix" commands without real reasons? That's bad and it would explain this lax security culture oozing from it. So the damage is already done, and real security problems will never be properly addressed. One must come to the conclusion that NPM has to be avoided at all cost if security is a concern at all. Additionally, one must make sure that when onboarding a developer coming from the NPM world into a sane project, they have to be properly de-conditioned with regards to security advisories.