Got it, I thought it was a last segment attack (image substition) but now I see you are aiming to a fully supply chain attack.

And if you find an nswer to that, please let me know because this things have virtually not a solution that ticks all boxes

Anyway I was gonna write a rant about it but I'm too tired. But basically the docker ecosystem is kinda fucked in this regard, and trades security in many aspects for convenience of development and distribution. This is one of the most notable examples of this.

It's popular because it's convinient and easy to use in many ways. If these pitfalls are a dealbreaker for you, then there is no trivial way to add the security requirements you are asking for.

You can pay for signed images from someone else, which is a little better, but there are still disadvantages.

Monitoring firewall logs would show calls to suspicious IPs and domains after you pulled the Docker container. A MiTM attack is usually conducted between two communicating parties, rather than inside the server itself. The attacker intercepts traffic as it travels across a network or service path. MiTM are not always done exterior of the server, but usually. Strong ciphers are your friend. Although MiTM and PIC events can overlap, a PIC is usually an attacker gaining unauthorized access to a system. A PIC compromise occurs outside the public facing server, through a stolen administrator password, compromised developer workstation, exposed API key, or hijacked cloud account. Securing API, devices, frequent password rotation are good practices. Again, not always exterior of the server, but usually.

How do you verify that nobody is holding the original developer at gunpoint making them sign their compromised software with their real key?

The point I'm trying to make: At some point, you have to trust something which you can not feasibly verify.

For most cases the github repo and an occasional look on a relevant newsfeed is good enough. If it's not good enough for yours, the first question still stands.