| ▲ | nine_k 5 hours ago |
| Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable. |
|
| ▲ | ljm 5 hours ago | parent | next [-] |
| The community decided it's too much effort to vet code before publishing it so here we are. (I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies) I landed on the 'yes, you should know what code you are getting involved with' side. |
|
| ▲ | devttyeu 5 hours ago | parent | prev | next [-] |
| Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc. |
| |
| ▲ | nine_k 4 hours ago | parent | next [-] | | > comes out to ~$200 in tokens every time BTW a curated mirror of <whatever ecosystem> packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org. Docker does something vaguely similar for Docker images, for free though. | | |
| ▲ | AgentME 4 hours ago | parent [-] | | People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within). | | |
| ▲ | nine_k 4 hours ago | parent [-] | | Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit. |
|
| |
| ▲ | voxl 4 hours ago | parent | prev | next [-] | | It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security. | | |
| ▲ | devttyeu 4 hours ago | parent [-] | | If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level. I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea. Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent. Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call. | | |
| ▲ | crab_galaxy 3 hours ago | parent [-] | | > running few years old JS deps What do you when a critical vulnerability gets discovered and you have to update a package? How many critical/high severity vulnerabilities are you running with in production every day to avoid supply chain attacks? | | |
| ▲ | devttyeu an hour ago | parent | next [-] | | For the stuff in more sensitive deployments it's really quite simple, just setup CORS etc properly and don't do anything overly fancy on the frontend. Worst case the user may force some internal function to eval some JS by pasting scripts into the browsers debug console. Critical severity vulnerabilities are only critical when they are reachable, but are completely meaningless if your application doesn't touch that code at all. It's objectively more risky to "patch" those by updating dependencies than just let them be there. | |
| ▲ | throawayonthe 2 hours ago | parent | prev [-] | | they said internal dashboards | | |
| ▲ | nine_k 2 hours ago | parent [-] | | Anyone who gets into the security perimeter may be in for a feast then. |
|
|
|
| |
| ▲ | n_e 4 hours ago | parent | prev [-] | | > Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. How is it not the default in npm? | | |
| ▲ | chuckadams 3 hours ago | parent [-] | | It is the default in both cargo and npm, but "npm install" stupidly enough still updates the lockfile, and you need "npm ci" to actually respect it. I think there's some flag to make install work sanely, but long-term I find the best approach is to use anything other than npm. I ditched npm for yarn years ago because it had saner dependency resolution (npm's peer dependency algorithm was a constantly moving target), and now I've switched from yarn to bun because it doesn't run hooks in dependencies by default. It also helps that it installs dependencies 10x faster. | | |
| ▲ | cluckindan 3 hours ago | parent [-] | | ”npm install” does not update the lockfile in any current major version. At least not if you haven’t edited your package.json manually. |
|
|
|
|
| ▲ | chuckadams 4 hours ago | parent | prev | next [-] |
| > Abandon NPM in exchange for what? Cargo? Go get? Pip install? pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed. |
|
| ▲ | vsgherzi 5 hours ago | parent | prev | next [-] |
| Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this. |
| |
| ▲ | nine_k 5 hours ago | parent | next [-] | | There's no silver bullet, but getting an exploit into xz took extraordinary effort, a long time, and bespoke code, because it needed to slip under the radar of actual humans reading the code. A shai hulud-style attack won't work with any reasonable Linux distro, like it does with npm. | |
| ▲ | kelvinjps10 2 hours ago | parent | prev [-] | | but it was caught with the existing release model, where first it goes to testing where many people before reaching the production systems in the stable release. for example debian |
|
|
| ▲ | TZubiri 4 hours ago | parent | prev | next [-] |
| Just writing the actual code that you are being paid to write |
| |
|
| ▲ | jadbox 5 hours ago | parent | prev | next [-] |
| Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib. |
| |
| ▲ | spartanatreyu 3 hours ago | parent [-] | | This is exactly why I love Deno so much, it has a standard lib AND a security model that's secure by default. |
|
|
| ▲ | slopinthebag 4 hours ago | parent | prev | next [-] |
| Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years? Idk about Python, I refuse to use that language for other reasons. |
| |
| ▲ | pier25 4 hours ago | parent [-] | | It makes more sense to attack packages in NPM since it's by far the most popular package manager. |
|
|
| ▲ | hans-l 4 hours ago | parent | prev [-] |
| [dead] |
