That other approach is to rely on confidential computing technologies, in particular, the remote attestation capabilities of Intel SGX and AMD SEV. These technologies are often associated with DRM or multi-party computation, but they can be used in a different way. In this alternative use case you statically attach a remote attestation to a piece of data as a signature of computation.
A signature of computation is a proof that a piece of data was derived by running a specific program with a specific input. If that program is deterministic, and has been verified by yourself or a third party, then it means the correctness of the transform can be mechanically verified in such a way that it's much harder to hack. In particular if you use SGX then root exploits on the machine doing the computation won't help the attacker due to the hardware level protections. If you use SEV it's harder but can AFAIK still be done with some specialized OS hacking.
Concretely this means that a shipped software artifact could come with a signature proving not only the identity of the developers, as is the case today, but that those files were produced using a known third party compiler and linker applied to e.g. a source tree at a specific git commit hash. Because those files can be verified by anyone including the developers themselves, it means that a compromised CI system is very limited in what it can do: every file has a cryptographic proof tracing it backwards to the input source tree, which in turn is replicated independently on developer's workstations and laptops so it can be checked by many semi-independent actors. And for extra value the company can hire a third party auditor who verifies that the source code at hash X does in fact meet the vendor's description of what it does.
I've experimented with this sort of approach in the past, but unfortunately CC as a tech gets sort of repeatedly stuck in the domain gap between low level systems programmers and the kind of wideband ecosystem building you need to deliver genuine business value. People aren't aware of what it can do or how to use it.
Also, this approach has a subtle side effect: it means the compiler is now a valid target for attack. For example if source code can corrupt compiler internals sufficiently to inject code, then you could potentially cause a miscompile that invalidates the proof. One solution for that is to use memory-safe compilers but the only one I know of is Graal.