alt Hacker NewsSee my other comment.
> when the implementation of these actions at some level live in the repo anyway
This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case. You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do this via build provenance attestation.
With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
Maybe a concrete example would help.
> With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
The way I'm thinking about it, we distinguish instructions from policy. Policy, of course, has to be imposed from outside a package somehow, but the instructions taken within policy seem like things that should evolve with it. For example, "no network access" might be an externally enforced policy. Another might be limitations of dependencies, enforced by making exceptions to the previous policy.
But in the end, you have to do something. Are you suggesting a model in which a project's entire test suite lives in a separate repository with an access control policy that differs from that project's so that the project's authors can't cheat on test coverage or pass rate?
Sure, you can do that, but the instructions for running those tests still have to live somewhere, and a makefile in that test repository seems like as good a place as any.