This advisory has been withdrawn because the stylus npm package is not malware.
NPM stylus package contained malicious code and was removed from the registry
41–45 of 45 posts
Re: NPM stylus package contained malicious code and was removed from the registry
#42Earlier quoted context omitted.
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…
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 conc…
Which is a wrong conclusion if I understand you correctly.
You can just host your own package repo and run your own verification to confirm if a package is indeed vulnerable or not. If it's not, you can just continue your operations as usual, regardless of what NPM (the company, the host provider, not the CLI tool) does in the background.
Re: NPM stylus package contained malicious code and was removed from the registry
#43Does anyone know what the malicious code was and what it did?
The malicious code had nothing to do with the stylus package. One of the maintainers of stylus published malicious code in another package, and GitHub / npmjs response was to nuke ALL packages that he was a maintainer of, including stylus.
The sensible action would be to remove only the malicious packages and suspend that account.
Re: NPM stylus package contained malicious code and was removed from the registry
#44Earlier quoted context omitted.
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…
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 conc…
The fix command just upgrades or downgrades the package to the first-known-unaffected-version. Meaning if “audit” api is unaware of a modern version for the fix (due to cache or human latency), then you can be downgraded to when the version before the bug was introduced, for ex. 25 major versions prior or something.
Re: NPM stylus package contained malicious code and was removed from the registry
#45Earlier quoted context omitted.
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 conc…
Which is a wrong conclusion if I understand you correctly. You can just host your own package repo and run your own verification to confirm if a package is indeed vulnerable or not. If it's not, you can just continue your operations as usual, regardless of what NPM (the company, the host provider, not the CLI tool) does in the background.
Not if your IT dept is lazy and has to meet some sort of security compliance, then they force the task on you to develop this “own package repo” or just use Dependabot and force your team to create a quarterly ticket to rake the security bugs out of the code.