Fifty Years of Open Source Software Supply Chain Security

Good article for what it covers, but sadly does not cover isolation/sandboxing/least privilege.

Yes. The crucial issue to me is the increasing frequency of attacks where some piece of open source gets an update - leading to endless hidden supply chain attacks.

I don't see anything that is going to block this from getting worse and worse. It became a pretty common issue that I first heard about with npm or node.js and their variants, maybe because people update software so much there and have lots of dependencies. I don't see a solution. A single program can have huge numbers of dependencies, even c++ or java programs now.

It's not new, here's one from 6 years ago on c++ - https://www.trendmicro.com/en_us/research/19/d/analyzing-c-c...

Don't forget log4j - https://www.infoworld.com/article/3850718/developers-apply-t..., points to this recent paper https://arxiv.org/pdf/2503.12192

Indeed. In 2020s, if you're not sandboxing each thing, and then sandboxing each library the thing depends on, you're running with way too many opportunities for vulnerability.

Well said! How?

I have no freaking idea. Needless to say I don't think our current operating systems are up to the task of actually being secure. You have to be able to somehow dynamic-link in a library whilst only giving calls into that library certain permissions/capabilities... which I don't think even Windows can do.

Didn’t Jess Frazelle have most of her dependencies running inside lots of Docker containers for a while? She went pretty far and also kept it up for a long time. E.g., https://blog.jessfraz.com/post/docker-containers-on-the-desk...

Ignorant reply here, but would openbsd's `pledge` and `unveil` sorta cover what you're talking about?

At the library level? Not as far as I know…

Forget OS support, is that something that modern CPUs can support efficiently? As far as I can tell, enforcing a security boundary across libraries would require changing the page table twice for every library call, which seems like a big performance hit.

I don't really know because I haven't put work in to investigate, but some things in that direction seem to be, possibly in order of some combination of maturity and comprehensiveness.

  - CHERI compartmentalisation
  - LavaMoat (js)
  - Scala "capture checking"
  - Java "integrity by default"

I have some ideas about operating system design (and stuff relating to the CPU design, too) to help with this and other issues (e.g. network transparency, resisting fingerprinting, better user programmability and interoperability, etc). This means that it is fully deterministic except I/O, and all I/O uses capabilities which may be proxied etc. Libraries may run in separate processes if desired (but this is not always required). However, other differences compared with existing systems is also necessary for improved security (and other improvements); merely doing other things like existing systems do has some problems. For example, USB will not be used, and Unicode also will not be used. Atomic locking/transactions of multiple objects at once will be necessary, too (this can avoid many kind of race conditions with existing systems, as well as other problems). File access is not done by names (files do not have names). And then, a specific implementation and distribution may have requirements and checking for the packages provided in the package manager and in the default installation (and the specification will include recommendations). These things alone still will not solve everything, but it is a start.

Then maybe your notion of security is useless in the real world and needs a rethink.

Security, when practiced, is a fundamentally practical discipline that needs to work with the world as is, not with dreams of putting people in basements in chains.

I haven't really understood how lavamoat works (if it works).

How would that protect you from a library?