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/

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.

Isn't this the same for maven, python, ruby projects too? I don't see this as a web only problem

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.

Or worse

   sudo curl URL | bash

Off topic, but this is why the whole "a vibe coded app is a security risk" trope is not quite right to me. That "vibe coder" doesn't know what Claude wrote, but the experienced dev also didn't know what all the packages, libraries and frameworks contained either. Is one worse than the other?

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 :)

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.

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.

I’ve avoided anything that requires “npm install”, and life is still quite good.

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.

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.

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]