16 ms·

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate you

• petcat 1y ago
  Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.
  • koakuma-chan 1y ago
    Until you need to write JavaScript?
    • baq 1y ago
      Which should be much less than what’s customary?
    • ehnto 1y ago
      But that's the neat part, you don't!
      • koakuma-chan 1y ago
        Until you have to.
        • speed_spread 1y ago
          The only way to win is not to play.
          • koakuma-chan 1y ago
            Let me quit my job real quick. The endgame is probably becoming a monk, no kidding.
            • joquarky 1y ago
              I considered becoming a Zen monk, but then I gave up the desire.
    • bdcravens 1y ago
      Then write it. Javascript itself isn't the problem, naive third-party dependencies are.
      • pixl97 1y ago
        Developers are perfectly fine with writing insecure JS all by themselves.
        • yawaramin 1y ago
          But developers don't typically write malware to deploy on their production systems.
• EMM_386 1y ago
  > The HTMX folks convinced me that I can get REALLY far without any JavaScript HTMX is JavaScript. Unless you meant your own JavaScript.
  • yawaramin 1y ago
    When we say 'htmx allows us to avoid JavaScript', we mean two things: (1) we typically don't need to rely on the npm ecosystem, because we need very few (if any) third-party JavaScript libraries; and (2) htmx and HTML-first allow us to avoid writing a lot of custom JavaScript that we would have otherwise written.
• philipwhiuk 1y ago
  HTMX is full of JavaScript. Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you.
  • bdcravens 1y ago
    I don't think the point is to avoid Javascript, but to avoid depending on a random number of third-parties. > Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you. As well as Ruby, Python, Go, etc.
  • hosh 1y ago
    Do you count LiveView (Elixir) in that assessment?
  • norman784 1y ago
    HTMX does not have external dependencies, only dev dependencies, reducing the attack surface.
• jddj 1y ago
  Is the difference between the number of dev dependencies for eg. VueJs (a JavaScript library for marshalling Json Ajax responses into UI) and Htmx (a JavaScript library for marshalling html Ajax responses into UI) meaningful? There is a difference, but it's not an order of magnitude and neither is a true island. Granted, deciding not to use JS on the server is reasonable in the context of this article, but for the client htmx is as much a js lib with (dev) dependencies as any other. https://github.com/bigskysoftware/htmx/blob/master/package.json https://github.com/bigskysoftware/htmx/blob/master/package.j... https://github.com/vuejs/core/blob/main/package.json https://github.com/vuejs/core/blob/main/package.json
  • yawaramin 1y ago
    Except that htmx's recommended usage is as a single <script> injected directly into your HTML page, not as an npm dependency. So unless you are an htmx contributor you are not going to be installing the dev dependencies.
    • jddj 1y ago
      That script still gets built somewhere using those deps
• tarruda 1y ago
  AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies. Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.
  • hsbauauvhabzb 1y ago
    JavaScript does have some pretty insane dependency trees. Most other languages don’t have anywhere near that level of nestedness.
    • staminade 1y ago
      Don't they? I just went to crates.io and picked a random newly updated crate, which happened to be pixelfix, which fixes transparent pixels in pngs. It has six dependencies and hundreds of transient dependencies, may of which appear to be small and highly specific a la left-pad. https://crates.io/crates/pixelfix/0.1.1/dependencies https://crates.io/crates/pixelfix/0.1.1/dependencies Maybe this package isn't representative, but it feels pretty identical to the JS ecosystem.
      • koakuma-chan 1y ago
        It depends on `image` which in turn depends on a number of crates to handle different file types. If you disable all `image` features, it only has like 5 dependencies left.
        • staminade 1y ago
          And all those 5 remaining dependencies have lots of dependencies of their own. What's your point?
          • koakuma-chan 1y ago
            > What's your point? Just defending Rust. > 5 remaining dependencies have lots of dependencies of their own. Mostly well-known crates like rayon, crossbeam, tracing, etc.
• reactordev 1y ago
  Until you go get malware Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code. What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This has to be baked into packages and package management.
  • lycopodiopsida 1y ago
    > Until you go get malware While technically true, I have yet to see Go projects importing thousands of dependencies. They may certainly exist, but are absolutely not the rule. JS projects, however... We have to realize, that while supply chain attacks can happen everywhere, the best mitigations are development culture and solid standard library - looking at you, cargo. I am a JS developer by trade and I think that this ecosystem is doomed. I absolutely avoid even installing node on my private machine.
    • homebrewer 1y ago
      Here's an example off the top of my mind: https://github.com/go-gitea/gitea/blob/main/go.sum https://github.com/go-gitea/gitea/blob/main/go.sum
      • mayama 1y ago
        Half of go.sum dependencies generally are multiple versions of same package. 400 still a lot, but a huge project like gitea might need them I guess. > cat go.sum |awk '{print $1}' | sort |uniq |wc -l 431 > wc -l go.sum 1156 go.sum
      • EdiX 1y ago
        I think you are reading that wrong, go.sum isn't a list of dependencies it's a list of checksums for modules that were, at some point, used by this module. All those different versions of the same module listed there, they aren't all dependencies, at most one of them is. Assuming 'go mod tidy' is periodically run go.mod should contain all dependencies (which in this case seems to be shy of 300, still a lot).
• lucideer 1y ago
  > I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to target e.g. NPM, but are then completely absent for PyPi or Crates. It's bizarre not only because it leaves those ecosystems wide open, but also because the mitigation measures would be very similar (so it would be a minimal amount of additional effort for a large benefit).
  • woodruffw 1y ago
    Could you say more about what mitigations you’re thinking of? I ask because think the directionality is backwards here: I’ve been involved in packaging ecosystem security for the last few years, and I’m generally of the opinion that PyPI has been ahead of the curve on implementing mitigations. Specifically, I think widespread trusted publishing adoption would have made this attack less effective since there would be fewer credentials to steal, but npm only implemented trusted publishing recently[1]. Crates also implemented exactly this kind of self-scoping, self-expiring credential exchange ahead of npm. (This isn’t to malign any ecosystem; I think people are also overcorrect in treating this like a uniquely JavaScript-shaped problem.) [1]: https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ https://github.blog/changelog/2025-07-31-npm-trusted-publish...
    • kibwen 1y ago
      > PyPI has been ahead of the curve on implementing mitigations Indeed, crates.io implemented PyPI's trusted publishing and explicitly called out PyPI as their inspiration: https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/ https://blog.rust-lang.org/2025/07/11/crates-io-development-...
  • kees99 1y ago
    I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages). But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.
• everdrive 1y ago
  Javascript is badly over-used and over-depended on. So many websites just display text and images, but have extremely heavy javascript libraries because that's what people know and that is part of the default, and because it enables all the tracking that powers the modern web. There's no benefit to the user, and we'd be better off without these sites existing if there were really no other choice but to use javascript.
  • mrweasel 1y ago
    NPM does seem vastly over represented in these type of compromises, but I don't necessarily think that e.g. pypi is much better in terms of security. So you could very well be correct that NPM is just a nicer, perhaps bigger, target. If you can sneak malware into a JavaScript application that runs in millions of browsers, that's a lot more useful that getting a some number servers running a module as part of a script, who's environment is a bit unknown. Javascript really could do with a standard library.
  • spoiler 1y ago
    > So many websites just display text and images Eh... This over-generalises a bit. That can be said of anything really, including native desktop applications.
    • achierius 1y ago
      Is that true? The things people use native desktop applications for nowadays tend to be exactly those which aren't just neat content displays. Spreadsheets, terminals, text-editors, CAD software, compilers, video games, photo-editing software. The only things I can think of that I use as just text/image displays are the file-explorer and image/media-viewer apps, of which there are really only a handful on any given OS.
      • spoiler 1y ago
        You could argue that spreadsheets and terminals are just text with extra features! I'm joking though, but web apps usually are more than just text and images too.
• Aeolun 1y ago
  Why is this inevitable? If you use only easily verifyable packages you’ve lost nothing. The whole concept of npm automatically executing postinstall scripts was fixed when my pnpm started asking me every time a new package wanted to do that.
• hoppp 1y ago
  They are. Any language that depends heavily on package managers and lacks a standard lib is vulnerable to this. At some point people need to realize and go back to writing vanilla js, which will be very hard. The rust ecosystem is also the same. Too much dependence on packages. An example of doing it right is golang.
  • rs186 1y ago
    Python and Rust both have decent std lib, but it is just a matter of time before this happens in thoae ecosystems. There is nothing unique about this specific attack that could only happen in JavaScript.
  • BrouteMinou 1y ago
    C#, Java, and so on.
  • pixl97 1y ago
    >and go back to writing vanilla js Lists of things that won't happen. Companies are filled with node_modules importers these days. Even worse, now you have to check for security flaws in that JS that's been written by node_modules importers. That or there could someone could write a standard library for JS?
  • simiones 1y ago
    The solution is not to go back to vanilla JS, it's for people to form a foundation and build a more complete utilities library for JS that doesn't have 1000 different dependencies, and can be trusted. Something like Boost for C++, or Apache Commons for Java.
    • zahlman 1y ago
      > Something like Boost for C++, or Apache Commons for Java. Honestly I wish Python worked this way too. The reason people use Requests so much is because urllib is so painful. Changes to a first-party standard library have to be very conservative, which ends up leaving stuff in place that nobody wants to use any more because they have higher standards now. It'd be better to keep the standard library to a minimum needed more or less just to make the REPL work, and have all of that be "builtin" the way that `sys` is; then have the rest available from the developers (including a default "full-fat" distribution), but in a few separately-obtainable pieces and independently versioned from the interpreter. And possibly maintained by a third party like Boost, yeah. I don't know how important that is or isn't.
• brazukadev 1y ago
  Not for the frontend. esm modules work great nowadays with import maps.
• jeswin 1y ago
  Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.
  • spankalee 1y ago
    Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.
    • pixl97 1y ago
      I mean, what does do good if your supply chain is attacked? This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it. Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.
      • spankalee 1y ago
        The supply chain infrastructure needs to stop being naive and allowing for insecure publishing. - npm should require 2FA disallow tokens for publishing. This is an option, but it should be a requirement. - npm should require using a trusted publisher and provenance for package with over 100k downloads a week and their dependencies. - Github should require a 2FA step for automated publishing - npm should add a cool down period where if won't install brand new packages without a flag - npm should stop running postinstall scripts. - npm should have an option to not install packages without provenance.
        • raxxorraxor 1y ago
• jmull 1y ago
  Simply avoiding Javascript won't cut it. While npm is a huge and easy target, the general problem exists for all package repositories. Hopefully a supply chain attack mitigation strategy can be better than hoping attackers target package repositories you aren't using. While there's a culture prevalent in Javascript development to ignore the costs of piling abstractions on top of abstractions, you don't have to buy into it. Probably the easiest thing to do is count transitive dependencies.
  • yawaramin 1y ago
    > Simply avoiding Javascript won't cut it. But it will cut a large portion of it.
• qudat 1y ago
  The blast radius is made far worse by npm having the concept of "postinstall" which allows any package the ability to run a command on the host system after it was installed. This works for deps of deps as well, so anything in your node_modules has access to this hook. It's a terrible idea and something that ought to be removed or replaced by something much safer.
  • zarzavat 1y ago
    I agree in principle, but child_process is a thing so I don't think it makes much difference. You are pwned either way if the package can ever execute code.
• rs999gti 1y ago
  > supply chain attacks You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages. Call it something like "free code attacks" or "hobbyist code attacks."
  • __alexs 1y ago
    I know CrowdStrike have a pretty bad reputation but calling them hobbyists is a bit rude.
    • cobbal 1y ago
      I'm sure no offense was intended to hobbyists, but it was indeed rude
  • shermantanktop 1y ago
    “code I picked up off the side of the road” “code I somehow took a dependency on when copying bits of someone’s package.json file” “code which showed up in my lock file and I still don’t know how it got there”
    • orbital-decay 1y ago
      All of which is true for far too many projects
  • pixl97 1y ago
    A supply chain can have hobbyists, there's no particular definition that says everyone involved must be a professional registered business.
• kubafu 1y ago
  Took that route myself and I don't regret it. Now I can at least entirely avoid Node.js ecosystem.
• ZYbCRq22HbJ2y7 1y ago
  > These attacks may just be the final push I needed to take server rendering (without js) more seriously Have fun, seems like a misguided reason to do that though. A. A package hosted somewhere using a language was compromised! B. I am not going to program in the language anymore! I don't see how B follows A.
• junon 1y ago
  This is going to become an issue for a lot of managers, not just npm. Npm is clearly a very viable target right now, though. They're going to get more and more sophisticated.