The vast majority of breaches are caused by credential theft, phishing, and exploiting vulnerabilities.
It doesn't matter that you can cryptographically verify that a package came from a given commit if that commit has accidentally-vulnerable code, or someone just gets phished.
https://www.wired.com/story/notpetya-cyberattack-ukraine-rus...
https://krebsonsecurity.com/2020/12/u-s-treasury-commerce-de...
Software supply chain attacks are rare, but when they happen, they're usually high-impact ordeals.
Where I work (highly regulated financial utility), we would absolutely love to have signed attestations for the provenance of python packages.
I also have personal experience of NotPetya; I produced the forensic analysis of how it compromised the whole of Maersk. Took less than 30 minutes to take out their entire global IT infrastructure, with a cost of about $400 million.
We are not there as long as Jenkins and most build infrastructure is basically Remote exploit as a service it is also going to take a long time. While Petya like in Ukraine is harder the more attestations you add there is always a hole, especially when all of your infrastructure needs to run things from some proprietary vendor.
They could instead use a cloud-based trusted execution environment on Azure, and get an attestation from some combination of Intel and Microsoft.
Or they could use a TPM and get an attestation from Infineon that the Microsoft-signed shim loaded a kernel blessed by a Microsoft-approved Linux vendor such as Canonical.
Seems to me that just trades one corporate attestation for another.
What would work better is if _everybody_ could run the same CI action to produce a release tarball, and it produced identical builds, and everyone doing this could publish their findings - we can federate a heterogenous network of verifiers, rather than trust a single source's attestation
Source: I wrote the contract for it.
Working on stuff outside of the top 99%+ of effective solutions deserves to be questioned.
As an alternative, they could have been investing time in a form of capabilities-based security for packages like Deno has where not every pip package can spawn info stealer processes at install time or runtime. That would address both the build compromise attacks and actually-common attacks like vulnerability exploitation.
Because it's a tractable problem that these devs can solve - and just because they're working on this doesn't meant they (or others) aren't also working on the other things.
> It doesn't matter that you can cryptographically verify that a package came from a given commit if ...
Sure, but just because it doesn't solve every single problem doesn't mean it's not worthwhile
This is just another step in increasing security. And of cause that is something you want to preferably do prior to breaches not only as a reaction.
So you get suit-compatible catch phrases like "SBOM" (notice how free software has been deliberately degraded to "materials" in that acronym!).
The corporations want to control open source, milk it, feed it to their LLMs, plagiarize it and so forth. And they pay enough "open" source developers who sell out the valuable parts that are usually written by other people.
As you say, it's partly security theater because of the other attack vectors that are especially relevant in an organization that has no stringent procedures, no open discussion culture or commitment to correctness like e.g. FreeBSD.
If that commit has accidentally-vulnerable code, or someone just gets phished and attacker added some malicious code to the repository with his creds, it is visible.
However, if the supply chain was secretly compromised and the VCS repo was always clean, only the release contains malware, then good luck finding it out.
We've all witnessed this earlier this year, in the xz accident, while the (encrypted) malicious code was presented in the source code repo as part of test data, the code to load and decrypt it only ever existed in release tarballs.