Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

781–790 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#781

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

Not at all. We simply need M-of-N auditors to sign off on major releases of things. And the package managers need to check this (the set of auditors can be changed, same as browser PKI for https) before pulling things down.

That's the system we have in our Safebox ecosystem

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#784
post #275

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

The other thing that keeps coming up is the github-code-is-fine-but-the-release-artifact-is-a-trojan issue. It really makes me question if "packages" should even exist in JavaScript, or if we could just be importing standard plain source code from a git repo. I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

This is where attestation/sigstore comes into play. Github has a first-party action for it and I wish more projects would use it. Regarding javascript specifically, I believe npm has builtin support for sigstore.

* https://docs.github.com/en/actions/concepts/security/artifac...

* https://www.sigstore.dev/

* https://github.com/actions/attest

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#785

Earlier quoted context omitted.

Like is-even or leftpad?

Like requests and pytest and ruff and so on, yes. Rewriting the world to protect against a specific kind of threat is insane.

It's not there isn't good libraries everywhere. It just the practice around NPM that people are appalled with. It's all about lowering the barrier for developers, even in spite of security and quality.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#787

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

I think stay vigilant is better than trust anything.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#788

Earlier quoted context omitted.

How can you come to that conclusion, given the specific examples I have given, which are tedious to write, but easy to proof-read and test?

Because AI threatens the identity of many programmers.

Lol. My most recent comment before this one is here: https://news.ycombinator.com/item?id=47583593. You judge if AI threatens my identity. But hey, don't let the facts get in the way of a slick narrative.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#789

Earlier quoted context omitted.

An alternative: - copy the dependencies' tests into your own tests - copy the code in to your codebase as a library using the same review process you would for code from your own team - treat updates to the library in the same way you would for updates to your own code Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've be…

I don't know where you've worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I've worked at.

They succeeded in poisoning the whole supply chain and making everyone distrust package management to a degree never seen before, and people who aren't reviewing their dependencies are already getting hit. You seem to suggest that we all accept that.

That attitude might be the reason why the places you've worked would be under threat. The places I've worked would also be under threat, because several of my colleagues had that attitude, and this is why red teaming works.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#790
post #156

Earlier quoted context omitted.

An alternative: - copy the dependencies' tests into your own tests - copy the code in to your codebase as a library using the same review process you would for code from your own team - treat updates to the library in the same way you would for updates to your own code Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've be…

Just going to put features on hold for a month while I review the latest changes to ffmpeg.

As you should. Also, the constant complaint from devs on these very boards is that quality and security are relegated behind new features that are often described as useless but pushed by management.

Are you in management?

Post reply on HN