8 ms·

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 w

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.

dec0dedab0de 6mo ago
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.
- bluGill 6mo ago
  What user is going to check dependencies like that?
  - dec0dedab0de 6mo ago
    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.
    - bluGill 6mo ago
      If someone detects it is asking a lot.
  - kibwen 6mo ago
    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.
    - bluGill 6mo ago
      That cannot work. Nor should it work. However can we make things so that users don't need to care in the first place? Note that the above probably isn't 100% answerable. However it needs to be the goal. A few people need to care and take care of this for everyone. Few needs to be a large enough to not get overwhelmed by the side of the job.
alex1138 6mo ago
[flagged]
- alex1138 6mo ago
  [flagged]
  - JumpCrisscross 6mo ago
    The entire comment is complaining about being downvoted. That’s not just going be downvoted, but also flagged due for violating HN’s guidelines.
- urbandw311er 6mo ago
  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.
- egeozcan 6mo ago
  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?
iugtmkbdfil834 6mo ago
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.
- bayindirh 6mo ago
  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".
  - thefounder 6mo ago
    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.
    - bayindirh 6mo ago
      I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software. Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care. Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.
      - thefounder 6mo ago
        In reality you are always on a time budget that is correlated with the output of the software you develop.(I.e is it worth it your time?) I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you develop a small effort piece of software you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly. Other stuff competes for your time(I.e family, other hobbies etc).
bastardoperator 6mo ago
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.
tarkin2 6mo ago
Isn't this the same for maven, python, ruby projects too? I don't see this as a web only problem
- Kaliboy 6mo ago
  Node is on another level though. It's cause they have no standard library.
  - leptons 6mo ago
    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.
  - postalrat 6mo ago
    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.
- epistasis 6mo ago
  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.
- izacus 6mo ago
  No, it's absolutely not the same.
- therealdrag0 6mo ago
leptons 6mo ago
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.
burnt-resistor 6mo ago
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.
Animats 6mo ago
Or worse sudo curl URL | bash
- chii 6mo ago
  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.
  - boomlinde 6mo ago
    > 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.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://web.archive.org/web/20250622061208/https://www.idont...
alfiedotwtf 6mo ago
> 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.
Esophagus4 6mo ago
Most of which can be managed with good SAST tooling and process.
MarsIronPI 6mo ago
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.
- petcat 6mo ago
  > Compared to traditional C or C++ projects it's madness. Those projects typically rely on an external package manager to handle their dependencies for them. Apt, yum, etc. Otherwise you end up in dependency hell trying to get ./configure to find the development headers of whatever it needs. I don't miss those days. Rust/Cargo is a godsend.
  - MarsIronPI 6mo ago
    It may be better from a DX perspective, but it's pure pain for distros like Debian who don't want to use cargo at build time to fetch arbitrary dependencies and instead use vetted system versions.
tmoertel 6mo ago
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 https://github.com/tmoertel/tempest-personal-weather [2] https://pypi.org/project/requests/ https://pypi.org/project/requests/
- LtWorf 6mo ago
  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.
  - K0IN 6mo ago
    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.
- dnnddidiej 6mo ago
  Is this a win for .NET where the mothership provides almost all what you need?
  - raincole 6mo ago
    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.
Witty0Gore 6mo ago
[dead]
thrance 6mo ago
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.
- xmcqdpt2 6mo ago
  Java has Security Managers. I've never seen anyone use it in practice though, so it probably doesn't work very well. I think it would be hard to get any kind of usable capability system without algebraic effects like those of Koka or Scala libraries. EDIT: Apparently Security Managers are deprecated and slated for removal.
nulltrace 6mo ago
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.
- baby_souffle 6mo ago
  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
- chii 6mo ago
  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).
  - computerfriend 6mo ago
    No need to hunt it down, there's a URL in the PR / commit message that links to the full diff.
vachina 6mo ago
I’ve avoided anything that requires “npm install”, and life is still quite good.
cookiengineer 6mo ago
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.
brikym 6mo ago
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.
neurostimulant 6mo ago
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 :)
- lobsterthief 6mo ago
  And Django is still great!
giarc 6mo ago
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?

dec0dedab0de 6mo ago

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.

bluGill 6mo ago
What user is going to check dependencies like that?
- dec0dedab0de 6mo ago
  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.
  - bluGill 6mo ago
    If someone detects it is asking a lot.
- kibwen 6mo ago
  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.
  - bluGill 6mo ago
    That cannot work. Nor should it work. However can we make things so that users don't need to care in the first place? Note that the above probably isn't 100% answerable. However it needs to be the goal. A few people need to care and take care of this for everyone. Few needs to be a large enough to not get overwhelmed by the side of the job.

alex1138 6mo ago

[flagged]

alex1138 6mo ago
[flagged]
- JumpCrisscross 6mo ago
  The entire comment is complaining about being downvoted. That’s not just going be downvoted, but also flagged due for violating HN’s guidelines.
urbandw311er 6mo ago
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.
egeozcan 6mo ago
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?

iugtmkbdfil834 6mo ago

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.

bayindirh 6mo ago
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".
- thefounder 6mo ago
  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.
  - bayindirh 6mo ago
    I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software. Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care. Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.
    - thefounder 6mo ago
      In reality you are always on a time budget that is correlated with the output of the software you develop.(I.e is it worth it your time?) I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you develop a small effort piece of software you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly. Other stuff competes for your time(I.e family, other hobbies etc).

bastardoperator 6mo ago

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.

tarkin2 6mo ago

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

Kaliboy 6mo ago
Node is on another level though. It's cause they have no standard library.
- leptons 6mo ago
  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.
- postalrat 6mo ago
  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.
epistasis 6mo ago
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.
izacus 6mo ago
No, it's absolutely not the same.
therealdrag0 6mo ago

leptons 6mo ago

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.

burnt-resistor 6mo ago

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.

Animats 6mo ago

Or worse sudo curl URL | bash

chii 6mo ago
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.
- boomlinde 6mo ago
  > 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.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://web.archive.org/web/20250622061208/https://www.idont...

alfiedotwtf 6mo ago

> 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.

Esophagus4 6mo ago

Most of which can be managed with good SAST tooling and process.

MarsIronPI 6mo ago

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.

petcat 6mo ago
> Compared to traditional C or C++ projects it's madness. Those projects typically rely on an external package manager to handle their dependencies for them. Apt, yum, etc. Otherwise you end up in dependency hell trying to get ./configure to find the development headers of whatever it needs. I don't miss those days. Rust/Cargo is a godsend.
- MarsIronPI 6mo ago
  It may be better from a DX perspective, but it's pure pain for distros like Debian who don't want to use cargo at build time to fetch arbitrary dependencies and instead use vetted system versions.

tmoertel 6mo ago

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 https://github.com/tmoertel/tempest-personal-weather [2] https://pypi.org/project/requests/ https://pypi.org/project/requests/

LtWorf 6mo ago
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.
- K0IN 6mo ago
  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.
dnnddidiej 6mo ago
Is this a win for .NET where the mothership provides almost all what you need?
- raincole 6mo ago
  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.

Witty0Gore 6mo ago

[dead]

thrance 6mo ago

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.

xmcqdpt2 6mo ago
Java has Security Managers. I've never seen anyone use it in practice though, so it probably doesn't work very well. I think it would be hard to get any kind of usable capability system without algebraic effects like those of Koka or Scala libraries. EDIT: Apparently Security Managers are deprecated and slated for removal.

nulltrace 6mo ago

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.

baby_souffle 6mo ago
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
chii 6mo ago
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).
- computerfriend 6mo ago
  No need to hunt it down, there's a URL in the PR / commit message that links to the full diff.

vachina 6mo ago

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

cookiengineer 6mo ago

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.

brikym 6mo ago

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.

neurostimulant 6mo ago

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

lobsterthief 6mo ago
And Django is still great!

giarc 6mo ago

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?