We use https://www.kusari.dev/ which is about securing the building and deployment of software, not about blockchains.

FRSCA: Factory for Repeatable Secure Creation of Artifacts provides a simple-to-install solution that aims to help secure the supply chain by building secure pipelines. It also provides abstractions and definitions with security guardrails ensuring all builds follow supply chain security best practices.

GUAC: Graph for Understanding Artifact Composition leverages metadata to provide deeper visibility and enable users to quickly understand security issues throughout the software supply chain, their blast radius, and how to remediate their root causes. Learn more as we build this out in the open source with our blog article.

https://www.kusari.dev/products/securesupplychain/

See also: https://slsa.dev/

> a trusted party reviewing code & posting content integrity hashes

That sounds like some combination of Crev[0], Sigstore[1], and Trillian[2].

[0] https://github.com/crev-dev/cargo-crev/blob/master/cargo-cre...

[1] https://docs.sigstore.dev/

[2] https://transparency.dev/

I’m not sure if they use blockchains per-se, but there are definitely companies that are trying to provide a secure software supply chain (chainguard is one I’m aware of, but I know nothing about the underlying technology).

CEO here. We use a transparency log (sigstore) instead of a blockchain.

Not sure if you need anything as complex as that: just the Python tools recording the hash of the dependency and storing that in the git repo should be enough to prevent this particular problem. e.g. go.sum contains a hash of the entire source. I believe npm and cargo are similar. This way the user should always get the exact same dependency that I added as a developer, no matter what happens with their settings or connection or whatnot.

Not familiar with Python's ecosystem at all, but judging from this commit[1] it doesn't seem to have anything it(?)

[1]: https://github.com/pytorch/pytorch/commit/bc92444b34dfbe3841...

That protects this one avenue, but the more common one I've seen (npm land) is a compromised downstream dependency that gets automatically upgraded for whatever reason.

Regardless - I want to be protected even when the Author of the package themselves is compromised (either by their tokens being stolen or them manually compromising the project)

it does, but to use hashes you'd have to pin exact versions of every dependency, which is generally undesirable for a library

Plug: I've been building Packj [1] to address exactly this problem. You can _audit_ as well as _sandbox_ installation of PyPI/NPM/Rubygems packages and flags hidden malware or "risky” code behavior such as spawning of shell, use of SSH keys, and mismatch of GitHub code vs packaged code (provenance).

1. https://github.com/ossillate-inc/packj flags malicious/risky packages.

Sigstore does this with a transparency log instead of a Blockchain.

A blockchain doesn't magically create money to pay the "miners". Well perhaps it might by taking money from speculators, but that isn't really a robust basis for security audits.

The money comes from folks who want verified software and are willing to pay for it. The greatest failure of crypto thus far is convincing people it’s a speculators market. This had to happen when the only outcome of a mine was “a hash starting with a lot of 0’s and a couple hundred bytes we can all agree on”. Make mining produce something legitimately valuable and that is no longer necessary.

There's no technical fix for compensating verifiers; it has to be negotiated out of band. This is different from Bitcoin because the Bitcoin protocol is unambiguous, so any well-behaved node that follows it can trust that all other well-behaved nodes will accept its output as valid. By contrast, security review is inherently subjective and reasonable people will disagree, necessitating judgment calls on who to trust.

Engineer the act of querying a trusted party to be a paid operation and the problem is solved. It doesn’t really matter if the verification is subjective, you pay 5 people you trust, only accept it if 4 say it’s good, and stop paying the 5th if they consistently disagree and/or vouch for disagreeable content.

Blockchain consensus only works when there are many more “verifiers” than there are items (blocks) to verify. Good luck with the amount of software updates being published and manual reviews.

Regarding manually reviewing software, it would be very easy to create a malicious majority of verifiers who certify malware, because malicious “verification“ takes much less resources than truthful verification. Rather than verifiers being payed, verifiers would need to themselves pay for the right to verify, in order to throttle malicious “verification”.

But realistically, you need verifiers that you trust in the first place, and if those exist, digital signatures are sufficient.