| ▲ | mohsen1 3 days ago |
| npm should take responsibility and up their game here. It’s possible to analyze the code and mark it as suspicious and delay the publish for stuff like this. It should prevent publishing code like this even if I have a gun to my head |
|
| ▲ | azemetre 3 days ago | parent | next [-] |
| Why would npm care? They're basically a monopoly in the JS world and under the stewardship of a company that doesn't even care when its host nation gets hacked when using their software due to their ineptitude. |
|
| ▲ | sesm 3 days ago | parent | prev | next [-] |
| I think malware check should be opt-in for package authors, but provide some kind of 'verified' badge to the package. Edit: typo |
| |
| ▲ | yjftsjthsd-h 3 days ago | parent | next [-] | | > but provide some kind of 'verified' badge to the package I would worry that that results in a false sense of security. Even if the actual badge says "passes some heuristics that catch only the most obvious malicious code", many people will read "totally 100% safe, please use with reckless abandon". | |
| ▲ | madeofpalk 3 days ago | parent | prev | next [-] | | They already have this https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/generating-provenance-statements | |
| ▲ | Cthulhu_ 3 days ago | parent | prev | next [-] | | I always thought this would be the ideal monetization path for NPM; enterprises pay them, NPM only supplies verified package releases, ideally delayed by hours/days after release so that anything that slips through the cracks has a chance to get caught. | | |
| ▲ | chrisweekly 3 days ago | parent | next [-] | | Enterprises today typically use a custom registry, which can include any desired amount of scans and rigorous controls. | |
| ▲ | johannes1234321 3 days ago | parent | prev [-] | | That would put them into liability or be a quite worthless agreement taking no responsibility. |
| |
| ▲ | naugtur 3 days ago | parent | prev [-] | | npm is on life support by msft. But there's socket.dev that can tell you if a package is malicious within hours of it being published. | | |
| ▲ | shreddit 3 days ago | parent [-] | | “within hours” is at least one hour too late, and most likely multiple hours. | | |
| ▲ | naugtur 3 days ago | parent | next [-] | | Absolutely not. you get npm packages by pulling not them pushing them to you as soon as a new version exist. The likelyhood of you updating instantly is close to zero and if not, you should set your stuff up so that it is. Many ways to do that.
Even better if compared to a month or two - which is how long it often takes for a researcher to find a carefully planted malware. Anyway, the case where reactive tools (detections, warnings) don't catch it is why LavaMoat exists. It prevents whole classes of malware from working at runtime.
The article (and repo) demonstrates that. | | |
| ▲ | rs186 3 days ago | parent | next [-] | | Sure, it should never happen in CI environment. But I bet that every second, someone in the world is running "npm install" to bring in a new dependency to a new/existing project, and the impact of a malicious release can be broad very quickly. Vibe coding is not going to slow this down. | | |
| ▲ | naugtur 3 days ago | parent [-] | | Vibe coding brings up the need for even more granular isolation. I'm on it ;) LavaMoat Webpack Plugin will soom have the ability to treat parts of your app same as it currently treats packages - with isolation and policy limiting what they can do. |
| |
| ▲ | bavarianbob 3 days ago | parent | prev [-] | | I've worked in software supply chain security for two years now and this is an extremely optimistic take. Nearly all organizations are not even remotely close to this level of responsiveness. |
| |
| ▲ | Cthulhu_ 3 days ago | parent | prev [-] | | Depends on whether they hold publishing to the main audience until said scan has finished. |
|
|
|
|
| ▲ | untitaker_ 3 days ago | parent | prev | next [-] |
| i can guarantee you npm will externalize the cost of false-positive malware scans to package authors. |
|
| ▲ | 3 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | nodesocket 3 days ago | parent | prev [-] |
| Or at a minimum support yubikey for 2fa. |
| |
| ▲ | mcintyre1994 3 days ago | parent | next [-] | | They do, I use a yubikey and it requires me to authenticate with it whenever I publish. They do support weaker 2fa methods as well, but you can choose. | |
| ▲ | worthless-trash 3 days ago | parent | prev [-] | | Original author could be evil. 2fa does nothing. | | |
| ▲ | jamesnorden 3 days ago | parent [-] | | If my grandma had wheels she'd be a bike. You don't need to attack the problem from only one angle. | | |
| ▲ | worthless-trash 3 days ago | parent [-] | | Your grandma is a bike then. The 2fa is going to solve nothing and any attacker worth their salt knows it. | | |
| ▲ | singulasar 3 days ago | parent [-] | | unphishable 2fa would have prevented this specific case tho... what are you talking about? | | |
|
|
|
|
