Comment by bradley13
15 hours ago
Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded.
The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond what already comes with Python. I like the peace of mind that comes from not having to worry about a hidden tree of dependencies that could easily some day harbor a Trojan horse.
[1] https://github.com/tmoertel/tempest-personal-weather
[2] https://pypi.org/project/requests/
Is this a win for .NET where the mothership provides almost all what you need?
.NET is great because you use a FOSS library and then a month later the developer changes the licence and forces you to either pay a subscription for future upgrades or swap it out.
C#/.NET is a good example showing no matter how much programmers you have, how much capital you hold, it's still impossible to make a 'batteries-included' ecosystems because the real world is simply too vast.
2 replies →
> I go out of my way to avoid using external packages.
I go out of my way to avoid Javascript. Because in all my years of writing software, it has 100% of the time been the root cause for vulnerabilities. These days I just use LiveView.
HTMX > Live View
1 reply →
I generally limit myself to what's available in my distribution, if the standard library doesn't provide it. But normally I never use requests because it's not worth it I think to have an extra dependency.
This might hold true for easy deps, but (let's be honest who would install is promise) if you have complex or domain specific stuff and you don't have the time to do yourself or the std lib does not have anything then yeh you might still fall into the pit, or you have to trust that the library does not have an supply chain chain issue itself.
There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.
Anecdata from a JS developer who has been in this ecosystem for 14 years.
I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.
Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.
Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.
Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.
Make sure you have a run of govulncheck [1] somewhere in your stack. It works OK as a commit hook, it runs quickly enough, but it can be put anywhere else as well, of course.
Go isn't immune to supply chain attacks, but it has built in a variety of ways of resisting them, including just generally shorter dependency chains that incorporate fewer whacky packages unless you go searching for them. I still recommend a periodic skim over go.mod files just to make sure nothing snuck in that you don't know what it is. If you go up to "Kubernetes" size projects it might be hard to know what every dependency is but for many Go projects it's quite practical to know what most of them are and get a sense they're probably dependable.
[1]: https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck - note this is official from the Go project, not just a 3rd party dependency.
> React happily also has 0 dependencies,
Ok, but it has 112 devDependencies, I'm not really sure "0 dependencies" best describes React.
2 replies →
I'm going almost the same direction, for the same reasons. Golang seems very interesting. Rewriting some hobby projects to get an understanding of the language and ecosystem. I'm on Node/webpack now and don't love where things are going.
Frontend: eh - you could pick something that targets wasm. Definitely a tradeoff with its own headaches.
3 replies →
That won't happen, because time to market is the biggest obstacle between the developers and the monies.
If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret.
Because an app is not built to help you. It's built to make them monies. It's not about the user, never.
Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".
It’s not always about money. It’s also about the time of the developer. Even for a hobby project you may burn out before to actually deliver it.
4 replies →
This is wild shift that AI allows now. I am building stuff, but not all of it is for public consumption. Monies matter, but, so does my peace of mind. Maybe even more so these days.
i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money.
at least, that's my attitude on it :shrugs:
2 replies →
I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff.
I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.
My opinion on "don't re-invent the wheel" has really shifted with these supply chain attacks and the ease of rolling your own with AI.
I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.
> but there must be a healthy middle ground between that and a library that lets you pick font color.
When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.
But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.
I agree.
I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses.
I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately.
I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example.
Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.
Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)
1 reply →
I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.
The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.
Maybe we should go back to kitchen-sink frameworks so most functionality you need is covered by the fat framework. I'm still using django and it keeps my python project's dependency relatively low :)
Lockfiles help more than people realize. If you're pinned and not auto-updating deps, a package getting sold and backdoored won't hit you until you actually update.
The scarier case is Dependabot opening a "patch bump" PR that probably gets merged because everyone ignores minor version bumps.
I wish those PRs made by the bot can have a diff of the source code of those upgraded libraries (right in the PR, because even if in theory you could manually hunt down the diffs in the various tags...in practise nobody does it).
No need to hunt it down, there's a URL in the PR / commit message that links to the full diff.
I mitigate this using a latest -1 policy or minimum age policy depending upon exactly which dependency we're talking about. Combined with explicit hash pins where possible instead of mutable version tags, it's saved me from a few close calls already... Most notably last year's breach of TJ actions
Isn't this the same for maven, python, ruby projects too? I don't see this as a web only problem
Yes, and it isn't the only problem.
I think the continuous churn of versions accelerates this disregard for supply chain. I complained a while back that I couldn't even keep a single version of Python around before end-of-life for many of the projects I work on these days. Not being able to get security updates without changing major versions of a language is a bit problematic, and maybe my use cases are far outside the norm.
But it seems that there's a common view that if there's not continually new things to learn in a programming language, that users will abandon it, or something. The same idea seems to have infected many libraries.
IME there’s a core set of very popular Java libs you can go very far without adopting obscure libraries you’ve never heard of. Eg apache-commons, spring, etc. the bar to adopt a 3p lib seems higher in some ecosystems than others.
Node is on another level though.
It's cause they have no standard library.
How can node scripts write to files, make network requests, etc etc without any standard library? Of course it has a standard library. You could maybe say javascript doesn't have much of a standard library (Array, String, Promise, Error, etc) but js is used with a runtime that will have a standard library.
Node has an extensive "standard library" that does many things, it's known as the "core modules".
Maybe you're referring to Javascript? Javascript lacks many "standard library" things that Nodejs provides.
No, it's absolutely not the same.
I too get worried when I see npm. Luckily I use bun install <everything> so it's all good. In seriousness I do at least have a 7d min age on the packages.
Or worse
made even worse by the fact that it's possible to detect a pipe vs just standard out display of the contents of curl, from the server side.
This means the attack can be "invisible", as a cursory glance at the output of the curl can be misleading.
You _have_ to curl with piping the output into a file (like | cat), and examine that file to detect any anomaly.
> it's possible to detect a pipe vs just standard out display of the contents of curl, from the server side
That sounded really interesting, so I looked it up and found this article from 2016 if anyone else is interested: https://web.archive.org/web/20250622061208/https://www.idont...
I’ve avoided anything that requires “npm install”, and life is still quite good.
The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
This is the best reason for letting users install from npm directly instead of bundling dependencies with the project.
What user is going to check dependencies like that?
I was really saying that if there is a compromised version that gets removed from NPM, then the projects using it do not need to be updated, unless of course they had the compromised version pinned.
Though plenty of orgs centralize dependencies with something like artifactory, and run scans.
1 reply →
Users who don't care about security are screwed no matter what you do. The best you can do is empower those users who do care about security.
1 reply →
Most of which can be managed with good SAST tooling and process.
Nearly every package manager does this. You would never get work done if you had to inspect every package. Services like renovate and dependabot do this lifting at no cost to the js developer, and probably do it better.
Rust is like this too. Every time I open a Rust project I look at Cargo.lock and see hundreds of recursive dependencies. Compared to traditional C or C++ projects it's madness.
I've been toying with the idea of a language whose packages have to declare which "permissions" they require (file io, network access, shell...) and devs have to specify which permissions they give to their dependencies.
This is a key vulnerability of package publication without peer review plus curation. Going to have to have many more automated behavioral code coverage analysis plus human reviewers rather than allowing unlimited, instant publication from anyone and everyone.
> There is zero chance that they have checked those libraries for supply chain attacks.
Even if they did, unless the project locked all underlying dependencies to git hashes, all it takes is a single update to one of those and you’re toast.
That’s why things like Dependabot are great.
When I'm looking for a new NPM module to do some heavy lifting, I always look for modules with zero dependencies first. If I can't find one then I look for modules with the fewest dependencies second. No preinstall or postinstall scripts in package.json, not ever. It isn't perfect, but at least we try. We also don't update modules that frequently. If it isn't broken, don't fix it. That has saved us from some recent problems with module attacks.
And now you've figured out the benefit of a language with a strong set of core libraries and an stdlib that come with it.
Go has its opinions and I don't agree with many of them, but the upstream packages combined with golang.org/x allow you to build pretty much anything. And I really like the community that embraced a trend of getting close to zero dependencies for their projects and libraries.
The only dependency I usually have for my projects are C binding or eBPF related. For most of the other parts I can just choose the stdlib.
[dead]
[flagged]
I'm sorry but does this have anything to do with npm? I just skimmed the article so maybe I missed it. So wordpress doesn't use npm, it doesn't even use composer, therefore this comment feels a bit disconnected. Maybe that's why?
I didn’t downvote it but it doesn’t seem particularly new or insightful. The points are quite shallow. Perhaps people come here for comments that offer an expert opinion or a bit more. As I say I didn’t downvote.
[flagged]
The entire comment is complaining about being downvoted. That’s not just going be downvoted, but also flagged due for violating HN’s guidelines.