There is so much going on in the world of SBOM that seems so wrong-headed to me, and this is a good example. So much of the effort seems to be going into proces

There is so much going on in the world of SBOM that seems so wrong-headed to me, and this is a good example. So much of the effort seems to be going into processes and systems that do little more than build a chain of trust back to someone or something that says "yeah just trust me". Here, from what I can tell (and I may have got this wrong), the "guarantee" of an un-tamperable build seems to come from some behaviour that some product (GitHub Actions) happens to exhibit. Today. That feature subtly changes tomorrow or someone finds a(nother) hole in GitHub Actions security model, it means nothing. I've generally come to believe that supply chain security comes from reproducible builds - though, more importantly, the build transparency that enables those builds to be performed reproducibly. If I can get two disparate, differently-hosted build machines to generate an identical artifact for me, that gives me far more confidence than relying on any behaviours that GitHub Actions is supposed to have. If I can then decide to ignore the pre-built package and choose to very easily perform the full scratch-build on my own systems and inspect every part of that process, that's even more convincing. A lot of the efforts around SBOM give me the impression that they're trying to solve the problem using lightly-digitized bureaucracy (which, as pointed out by Luis Villa in https://blog.tidelift.com/pay-to-play-dont-expect-maintainers-to-solve-your-supply-chain-issues-for-free https://blog.tidelift.com/pay-to-play-dont-expect-maintainer... is a game that many FOSS maintainers may not want to play), whereas, as a Nix person myself (oh hadn't you guessed by now?) it's always struck me that this is really a build system problem and most of the work should be doable automatically. (I guess the approaches I've been seeing are also related to the fixation we seem to have in ops/ci/cd standard practices these days with the "push" model of many individual build processes & steps "pushing" an opaque artifact to the next in a pipeline. It's an idea baked into most components from Docker to .. really every ci pipeline syntax I've seen. But it's an idea that's strewn with subtle complexities - from stale artifacts of previous failed runs to race conditions with dire consequences. In my experience life becomes a lot simpler when your destination instead understands exactly what it needs, can "pull" in exactly those resources and have them built to their specifications or build them itself..)