I have two thoughts to share about this from what you've said:
> we must stop expecting [Open Source] devs to have any responsibility for code they produce.
Yes, I agree with this. And something that's been in my head for a while, which often discussed, is how people often "magically think" something along the lines of:
"If we just paid these devs for support, then we'd solve the support problem!"
Unfortunately, I don't think is reality. If you're a dev working at Google and you toss a library on NPM, you probably can't be paid to support it because your employer forbids it.
The type of person writing libraries Open Source is not always going to be motivated by money!
> Some of my clients actually do (or pay others for) security review of every single NPM dependency they use in prod. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. Find a leaner path.
There was a post a few months ago[0] that has been talking about a way to "democratize" this review process. It's been sitting in my head and it's actually a part of a project that I'm working on now[1]. (My apologies for that not being documented anywhere yet though!)
Essentially, if every company on this planet has to review every Open Source dependency, that's a massive waste of human effort because there is a ton of overlap between that work.
Instead, what if you could have one person/entity do that work to review the dependencies and then you "buy" that dataset for a fraction of the price? If it takes 10 humans a year to review every dependency you have, then it's cheaper to pay 1 human salary to buy that data. (And we do the work once but then sell it 100+ times.)
That's the core principle that's been in my head for a while and that's how we're trying to build a company right now.
Unsexy problems aren't very "shiny" (like Stable Diffusion or NFTs) but they are important!
I also am spinning up some projects and tooling to have standardized, cryptographically signed, language agnostic, vcs agnostic, and publicly publishable/searchable code reviews for any open source project.
I have been thinking about this deeply for years, built internal tools like this for companies, and been pleading with package manager maintainers for collaboration.
Some of my clients have made said they would strongly consider publishing internal dependency reviews to such a platform if it existed.
Sounds like we have some common goals. Would love to keep in touch on new developments. Contact info on https://lance.dev
I have. I actually worked a few desks down from dpc when he was creating it and we talked about it at length. I felt then and now that it has good goals but a very limiting implementation in that it does not pursue a portable spec and instead anchors a very opinionated format to git, and github, instead of cryptographic keys held in hardware controlled by reviewers. I want to see the same keys that sign git commits also sign reviews, for instance.
I think for broad adoption a review system should ask essentially the same questions as crev, but store them in a format like in-toto including signatures by the reviewers created with a user choice of pgp smartcards, ssh keys, or webauthn devices. These reviews would be anchored to hashes of a particular state of a particular tree of code and not to any type of VCS or distribution system. Important code is distributed via perforce, mercurial, cvs, subversion, and tar files depending if we are talking about big corps, old codebases, or linux distro building blocks. A good OSS review system should be also be usable by teams in their internal proprietary codebases too if we wish to see wide adoption. Even for OSS we may wish to share some reviews as standalone objects privately while security embargos are in place, etc. Proofs should also be verified standalone easily from local cache, when github is down, when original repos vanish, etc.
Something that meets these broader needs will make it easy for large orgs with very different internal setups to participate and play nice with other supply chain security tooling efforts by the OpenSSF using in-toto for Sigstore, Witness, etc.
My experience and visibility into internal review tooling of multiple companies tells me many need something very different than crev, but crev proved to me many people have real interest in this problem which I really thank dpc for.
Like crev I feel cargo-vet is solving the right problem, and I am glad it exists as a stopgap today to encourage more review, but both designs lack portability and cryptographic signing.
They fail to address a major problem in supply chain security which is that malicious actors often get write access to repos, or their mirrors, allowing for fake commits or reviews.
Cargo itself, like most language package managers, shows complete disregard for supply chain security from the unsigned curl/bash recommended installation process. When I have needed trusted reproducible builds of cargo in my supply chains, I have had no choice but to build it myself, only to find you need a recent version of cargo to build cargo. It is a circular nightmare.
Debian at least does mostly best effort reproducible builds and signs them, so it seems like the least bad option today for security critical rust projects to build with. Linux/BSD package managers that rely on web of trust signing and reproducible builds often feel like the only responsible adults in the whole industry wide software supply chain story.
I have talked to multiple package manager teams and there is almost universal hate of the very concept of author/distributor/reviewer cryptographic signing citing that it is so hard for participants to learn that it even being offered as optional would put people off.
IMO if someone lacks will to tap a blinking Yubikey, TouchID, or similar to sign their security reviews and commits, they likely should not be doing security reviews or distributing security critical tooling.
My hope is to make signed review tooling easy enough that people will run out of excuses not to use or emulate it.
Thats incredible what you say about packaging people hating signing, I come from the Linux distro space (Debian) where support for it is almost universal. I OpenPGP sign all my git pushes, commits, tags, tarballs and uploads to Debian.
BTW, you might want to look into the Bootstrappable Builds project. They are working on starting from ~512 bytes of machine code plus a ton of source all the way up to a full distro. Started by Guix folks, hopefully it will eventually trickle down to more mainstream distros. Apparently rustc is bootstrappable via mrustc, which only requires a C/C++ toolchain. There is some discussion of that in the comments on an LWN article about the Rust/GCC projects.
> we must stop expecting [Open Source] devs to have any responsibility for code they produce.
Yes, I agree with this. And something that's been in my head for a while, which often discussed, is how people often "magically think" something along the lines of:
"If we just paid these devs for support, then we'd solve the support problem!"
Unfortunately, I don't think is reality. If you're a dev working at Google and you toss a library on NPM, you probably can't be paid to support it because your employer forbids it.
The type of person writing libraries Open Source is not always going to be motivated by money!
> Some of my clients actually do (or pay others for) security review of every single NPM dependency they use in prod. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. Find a leaner path.
There was a post a few months ago[0] that has been talking about a way to "democratize" this review process. It's been sitting in my head and it's actually a part of a project that I'm working on now[1]. (My apologies for that not being documented anywhere yet though!)
Essentially, if every company on this planet has to review every Open Source dependency, that's a massive waste of human effort because there is a ton of overlap between that work.
Instead, what if you could have one person/entity do that work to review the dependencies and then you "buy" that dataset for a fraction of the price? If it takes 10 humans a year to review every dependency you have, then it's cheaper to pay 1 human salary to buy that data. (And we do the work once but then sell it 100+ times.)
That's the core principle that's been in my head for a while and that's how we're trying to build a company right now.
Unsexy problems aren't very "shiny" (like Stable Diffusion or NFTs) but they are important!
0: https://news.ycombinator.com/item?id=32037562
1: https://github.com/lunasec-io/lunasec