Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators.

"Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.

You only need to rewrite what you use, which for many (probably most) libraries will be 1% or less of it

I always tried to keep the dependencies to a minimum.

Another thing you can do is lock versions to a year ago (this is what linux distros do) and wait for multiple audits of something, or lack of reports in the wild, before updating.

No need to. But also no need to pull in a dependency that could be just a few lines of own (LLM generated) code.

... and now you've switched the attack vector to a hostile LLM.

In both cases, the solution is similar: try to restrict access to vital systems only to those you trust,so that you have less need to audit their every move.

Your system administrators can access the server room, but the on-site barista can't. Your HTTP server is trusted enough to run in prod, but a color-formatting library isn't.

(Big fan of version pinning in basically every context, too)

This is an eco system that has taken code reuse to the (unreasonable) extreme.

When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

Another 20% or more is https://pypi.org/project/requests/ and its dependencies — this is an extremely popular project despite that the standard library already provides the ability to make HTTPS connections (people just hate the API that much). One of requests' dependencies is certifi, which is basically just a .pem file in Python package form. The vendored requests has not seen any tree-shaking as far as I can tell.

This sort of thing is a big part of why I'll be able to make PAPER much smaller.

Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.

Just because dependencies do a lot more than you need, doesn't mean you should automatically reach for the smallest dependency that fits your needs.

If you need 5 of the dozens of Lodash functions, for instance, it might be best to just install Lodash and let your build step shake out any unused code, rather than importing 5 new dependencies, each with far fewer eyes and release-management best practices than the Lodash maintainers have.

Creating two problems, where there was one.

The true threat here isn't the immediate dependency though, it's the recursive supply chain of dependencies. "trustworthy" doesn't make any sese either when the root cause is almost always someone trustworthy getting phished. Finally if I'm not capable of auditing the dependencies it's unlikely I can replace them with my own code. That's like telling a vibe coder the solution to their brittle creations is to not use AI and write the code themselves.

When you code in a high-security environment, where bad code can cost the company millions of dollars in fines, somehow you find a way.

The sibling commenter is correct. You write what you can. You only import from trusted, vetted sources.

Whether to take a dependency is a tricky thing that really comes down to engineering judgement- the thing that you (the developer) are paid to make the calls on.

a lor of these dependencies are higher order function definitions, which never change, and could be copy/pasted around just fine. they're never gonna change

Or At the time of adding you can add a NOTE or FIXME comment stating where you copied it from. A quick grep for such keyword can give you a nice overview of nice to have stuff. You can also add a ticket with all the details if you're using a project management tool and resuscitate it when that hypothetical moment happens.

I wonder to which extent is the extreme dependency count a symptom of a standard library that is too minimalistic for the ecosystem's needs.

Perhaps this issue could be addressed by a "version set" approach to bundling stable npm packages.

There is no need to rewrite dependencies. Sometimes it just so happens that a project can live without outputting fancy colorful text to stdout, or doesn't need to spread transitive dependencies on debug utilities. Perhaps these concerns should be a part of the standard library, perhaps these concerns are useless.

And don't get me started on bullshit polyfill packages. That's an attack vector waiting to be exploited.

There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

Your employees are carefully vetted before hiring. You've got their names, addresses, and social security numbers. There's someone you're able to hold accountable if they steal from you or start breaking everything in the office.

This seems more like having several random contractors who you've never met coming into your business in the middle of night. Contractors that were hired by multiple anonymous agencies you just found online somewhere with company names like gkz00d or 420_C0der69 who you've also never even spoken to and who have made it clear that they can't be held accountable for anything bad that happens. Agencies that routinely swap workers into or out of various roles at your company without asking or telling you, so you don't have any idea who the person working in the office is, what they're doing, or even if they're supposed to be there.

"To make thing easier for us we want your stuff to require the use of a bunch of code (much of which does things you don't even need) that we haven't bothered looking at because that'd be too much work for us. Oh, and third parties we have no relationship with control a whole bunch of that code which means it can be changed at any moment introducing bugs and security issues we might not hear about for months/years" seems like it should be a hard sell to a boss or a client, but it's sadly the norm.

Assuming that something is going to go wrong and trying to limit the inevitable damage is smart, but limiting the amount of untrustworthy code maintained by the whims of random strangers is even better. Especially when the reasons for including something that carries so much risk is to add something trivial or something you could have just written yourself in the first place.

In both cases, actually doing the work and writing a function instead of adding a dependency or asking an AI to write it for you will probably make you a better coder and one who is better able to audit code you want to blindly trust in the future.

NPM is good for building your own stack but it's a bad idea (usually) to download the Internet. No dep system is 100% safe (including AI, generating new security vulns yay).

I'd like to think that we'll all stop grabbing code we don't understand and thrusting it into places we don't belong, or at least, do it more slowly, however, I also don't have much faith in the average (especially frontend web) dev. They are often the same idiots doing XYZ in the street.

I predict more hilarious (scary even) kerfuffles, probably even major militaries losing control of things ala Terminator style.

It’s not even a judgement call at this point. It’s more aligned with buckling your seatbelt, pointing your car off the road, closing your eyes, flooring it and hoping for a happy ending.

In fact, when we did have Java in the browser it was loaded with security issues primarily because of the much greater complexity of the Java language.

If you’re gonna reimplement only thr code you need from a dependency, it’s hard to know of the stuff you’re leaving out how much is just extra stuff you don’t need and how much might be security fixes that may not be apparent to you but the dependency by virtue of being worked upon and used by many people has fixed.

What kind of code does this developer write?

The issue here is not Java or it's complexity. The point is also not Java, it's incidental that it was popular at the time. It's people acting irrationally about things and jumping ship for an even-worse system.

Like, yes, if that really were the whole attack surface of JS, sure nobody would care. They also wouldn't use it...and nothing we cared about would use it either...

Anyways, I think you are missing the forest for the trees if you think this is a Java vs JavaScript comparison, don't worry it's also possible to produce junk enterprise code too...

Just amusing watching people be irrationally scared of one language/ecosystem vs another without stopping to think why or where the problems are coming from.

A few lines of code can be audited.

Sounds very similar to how global SIs staff enterprise IT contracts.

   npm install stdlib 

Let me assure you, devs were skeptical about all this well before AI.

A lot of the culture is built by certain people who make a living out of package maximalism.

More packages == more eyballs == more donations.

They have an agenda that small packages are good and made PRs into popular packages to inject their junk into the supply chain.

The customer “ooh”s and “aah”s at said fancy animations running on the salesman’s top of the line macbook pro and is lured in, only realising too late that they’ve been bitten in the ass by the enormous amount of bloat that makes it run like a potato on any computer that costs less than four thousand dollars.

And US/EU laws are written by clueless bureaucrats whose most recent experience with technology is not even an electric typewriter.

What’s your point?

We once had the rule HTML should be purely semantic and all styling should be in CSS. It was brilliant, even though not everything looked as fancy as today.

The designer, in my experience, is totally fine with just using a normal select element, they don't demand that I reinvent the drop-down with divs just to put rounded corners on the options.

Nobody cares about that stuff. These are minor details, we can change it later if someone really wants it. As long as we're not just sitting on our hands for lack of work I'm not putting effort into reinventing things the browser has already solved.

But the reason Java is more secure than JavaScript in the context of supply chain attacks is fourfold:

1. Maven packages don't have install scripts. "Installing" a package from a Maven repository just means downloading it to a local cache, and that's it.

2. Java code is loaded lazily on demand, class at a time. Even adding classes to a JAR doesn't guarantee they'll run.

3. Java uses fewer, larger, more curated libraries in which upgrades are a more manual affair involving reading the release notes and the like. This does have its downsides: apps can ship with old libraries that have unfixed bugs. Corporate users tend to have scanners looking for such problems. But it also has an upside, in that pushing bad code doesn't immediately affect anything and there's plenty of time for the author to notice.

4. Corporate Java users often run internal mirrors of Maven rather than having every developer fetch from upstream.

The gap isn't huge: Java frameworks sometimes come with build system plugins that could inject malware as they compile the code, and of course if you can modify a JAR you can always inject code into a class that's very likely to be used on any reasonable codepath.

But for all the ragging people like to do on Java security, it was ahead of its time. A reasonable fix for these kind of supply chain attacks looks a lot like the SecurityManager! The SecurityManager didn't get enough adoption to justify its maintenance costs and was removed, partly because of those factors above that mean supply chain attacks haven't had a significant impact on the JVM ecosystem yet, and partly due to its complexity.

It's not clear yet what securing the supply chain in the Java world will look like. In-process sandboxing might come back or it might be better to adopt a Chrome-style microservice architecture; GraalVM has got a coarser-grained form of sandboxing that supports both in-process and out-of-process isolation already. I wrote about the tradeoffs involved in different approaches here:

https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

[1] https://medium.com/graalvm/writing-truly-memory-safe-jit-com...

If they are not, something is bad and the dependency should be "reduced" if at all possible.

We "in the know" might agree, but we're not going to get it sold.

https://www.w3.org/WAI/WCAG22/Techniques/#client-side-script

Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

If you're using HTML/CSS sensibly then it's accessible from the get-go by dint of the browser being accessible.

> Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

HTML5 added a million new tags, but HTML4 had plenty of semantic tags that people regularly ignored and replaced with <div>, for example <p>, <em>, <blockquote>...

I'm not saying the ideal frontend dev writes no JS. I'm saying they write as little as possible. Some times you need JS, nothing wrong with that. The vast majority of the time you don't. And if you do I'd say it's a self-imposed requirement (or a direct/indirect result of a self imposed requirement) most of the time.

https://www.webstandards.org/about/index.html

It's still neither realistic nor helpful advice.

But the middle management might actually praise the developer, because they "get the job done" with the minimal effort (so "efficient"!).

For me as a mostly backend dev, this was actually quite easy to achieve. Tiny modification of the backend API, some work in the frontend using JS to remove hints that should not show when JS is running, and voila, it works. Of course my pages are very simple in nature, but the same principles can be applied to larger pages. One could even link/direct to different pages, depending on the user running JS or not, and then have a workflow without JS and one with JS. It is all possible and only a matter of wanting to make an effort. Of course, modern JS frameworks do not really encourage this kind of design. Though server side rendering becomes more popular these days, I don't think we are quite there yet.

A page that is blank when not running JS has exactly zero accessibility.

But again, if the discussion is going to be that specific, then you would need to provide actual examples, so that we could judge, whether we would implement that ourselves or it would be difficult to do so. Note, that often it is also not required for ones use-case, to have a 100% matching behavior either. The goal is not to duplicate lodash. The purpose of the extracted or reimplemented function would still be ones own project, where the job of that function might be much more limited.

Yes, I remember thinking at the time "how are people not ashamed to install this?"

https://github.com/lodash/lodash/blob/main/dist/lodash.js#L7...

So you also need to copy isArrayLikeObject, baseDifference and baseFlatten.

For baseDifference, you also need to copy arrayMap and baseUnary.

For baseFlatten, you also need to copy arrayPush.

For isArrayLikeObject, you also need to copy isArrayLike and isObjectLike.

For isArrayLike, you also need to copy isLength and isFunction.

For isFunction, you also need to copy isObject and baseGetTag.

For baseGetTag, you also need to copy getRawTag and objectToString.

I don’t have time to dig any deeper, just use tree-shaking ffs.

Tree shaking however, will not help you, if you have to first install a library using NPM. It will only help you reduce overhead in the code served to a browser. Malicious code can run much earlier, and would be avoided, if you rewrite or extract relevant code from a library, avoiding to install the library using NPM. Or is there some pre-installation tree shaking, that I am unaware of? That would actually be interesting.

For ca. ten years, the advice was to pointlessly "replace <i> with <em> and <b> with <strong>" and it utterly screwed over most new web developers' understanding of semantic tags. There are many reasons to use italics (and they vary between languages) but "emphasis" is just one of them, and none of the others ever materialized as tags.

It would have been far better to have recommended <i class="emphasis"> and <i class="media-title"> and <i class="snarky-aside"> etc. than to have added the <em> tag and said "just use it instead of <i>".

That is straight up untrue. Some ARIA patterns require developers to implement focus management and keyboard access from scratch.

For example, ”Correct implementation of the tree role requires implementation of complex functionality that is not needed for typical site navigation that is styled to look like a tree with expandable sections.”

But sometimes you do need that kind of widget for something else.

https://www.w3.org/WAI/ARIA/apg/patterns/treeview/

Or are you talking about a situation where the developer has implemented a custom component (aka "done something") which doesn't use the native focus system and therefore requires additional work to make accessible?

The native focus system typically works just fine, but JS is needed for keyboard interactions and to set things like aria-activedescendant.