https://slsa.dev/spec/v1.0/levels
Here's the full spec from its beginning:
For those saying we should have verified reproducible builds: yes, that'd be great! This effort does not conflict with reproducible builds. However, some builds are hard to reproduce. Making sure you protect the build process itself is a great first step.
Well, we can hope, anyway. "Provenance" necessarily involves injecting secret data into the build process so that it can't be reproduced by third parties.
It's mostly a question of how careful you are to keep the keys / signatures completely separate from all of the other build inputs and outputs. Some code signing systems make that pretty difficult.
in-toto is a great way to describe provenance. I talk about it in the CNCF blog article: https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-a...
Disclaimer, I am a member if the in-toto steering committee and the CEO of a software supply chain startup, Testifysec. https://github.com/in-toto/witness is our project
You're right that provenance itself doesn't require this, but that is principally because it punts on the problem of authenticity. Whether or not authenticity matters probably depends on the value and scope of the provenance's use :-)