And then combine hardened git techniques with an air-gapped environment and a process of synchronising /pushing the git history from your source of truth into your airgapped repository (git or oci)

The airgapped repos (or otherwise separate production repos) model makes a lot of sense to me, but some are worried about the overhead of managing sync processes and additional repo services in multiple environments. Regardless, do you think using pull requests for this might be viable perhaps instead of merge requests on to main branch on the main repo? I had seen the post on OpenGitOps, but the paper from ControlPlane was new to me. Thank you!

If you don't want the overhead of a sync process, you can publish some commits as an OCI image - this gives you the added advantage of being able to promote an image (git commit) to different environments while verifying the process 1. Developer commits with their own key and opens a pull request 2. CI runs tests and prevents merge without the necessary approvals etc 3. On merge CI pushes an OCI image and adds it's own signature (optionally adding annotations around the branch policy/approvers/test results) 4. Dev environment authenticates the CI signature before applying manifests 5. Someone or something adds a production signature (Could use a hardware key, or KMS with conditions that require recent MFA, IP range etc)

Thank you for the insights!