>If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area?

This would be where different security advice would apply: don't pull in a package that has 400 dependencies.

Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."

Things like this are suppose to be provenance of an organizations security engineering teams. Helping to ensure you don't ship something like this. It's also hard for them too because no one wants to force developers to re-implement already solved functionality.

I also have never met a security engineer that was eager to do that.

> never met a security engineer that was eager to do that

Of course not. We do the fun parts, and write tickets to make the dev team do the boring parts that we will later complain are not implemented to the quality standard we would have reached, had we done the work. That's the deal.

Late to reply, but yeah no one is eager to do it. Unfortunately being good at security means being really good at work that is boring, tedious, and not glamorous, which also measures poorly into OKRs and other facets of shipping culture. Unless the team has really strong leadership that can get the security engineer ladders divested from the SWE/SRE ladders.

I literally just finished up writing up something that does supply chain provenance checking across 9 languages and still have a lot of edge cases to handle. It's not fun, but it's honest work.

Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.

I believe he might be a distant cousin. I've done some family tree searching myself and haven't found many things, since the Rainbolt side has mostly been scoundrels and vagabonds there aren't many details, but we do have a mountain that we named after ourselves after we stole it from natives.

Wait how in the world does a React carousel component have over 400 deps…

History of "micro dependencies" where many flexible utilities are split up into separate packages, such that many npm dependencies are a single function (ie rather than a package exporting ten methods, its ten separate dependencies).

Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.

/giphy "first time?" meme

Because Javascript is a drug that makes developers stupid.

It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.

Nearly all of these look like demo projects. You're making inferences about an entire group of developers based on a meme plus a search over the very 'worst' offenders.

Did you think the meme about node_modules having more gravity than a star was just a meme?

It's very much based on reality. The npm ecosystem is just absolutely fucked.

Do you mean https://www.npmjs.com/package/carousel-react? By the looks of it, this was published by someone 7 years ago as part of a personal project. Nothing uses it.

Going through that list... they all look like personal projects, with no dependents, and a single release by a single person.

Ok now that I’ve actually looked at the package.json, it seems like this must be a joke or something. It’s got packages for CLI arg parsing, math expression evaluation, hashing, etc.

When I’m back on my computer I may look at the source and confirm my suspicion that none of those are required for the carousel functionality lol

This is really where SELinux had the right idea overall: preclassifying files with data about their sensitivity, and denying access based on that, does adequately solve this problem (i.e. keeping npm installations away from id_rsa).

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone.

im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.

I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do.

So before running any code you'd hash it and ask your peers: "what do we think this does?"

If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised.

I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens.

It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.

This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions).

This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works).

AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?).

Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?

As far as I'm aware it's missing the consensus part. If I run a program that's not supposed to touch the filesystem in any way, and it does, SELinux doesn't suggest a way for me to circulate this new knowledge among other users of this program--except through its maintainer or that of my Linux distro. And maintainer diligence is over-relied-on as it is.

Ideally this sort of thing would work just as well on bits for which there was no clear maintainer. Like if SETI turned up a signal which we can chmod +x and run, we could use such a thing to crowd source an understanding of what it does.

A way to hash a file and ask:

> What is known about these bits?

If it's a popular program and yet none of your peers have seen that hash, maybe you should subject it to more scrutiny than if there's widespread consensus about it.

> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area?

At my place of work we use this great security too called Snyk. Definitely check it out

/s