Ask HN: How are you stopping supply chain attacks via compromised dev keys?

GitHub and GitLab will verify that a commit is signed by some key on the user's account. They won't let you require that it be signed by a specific key, like a hardware-backed YubiKey your org issued. So if an attacker compromises a developer's laptop or GitHub account, they can add a new signing key, push commits signed with it, and pass every "Require signed commits" protection in place. The malicious commit lands in the repo with a "Verified" badge.

As far as I can tell, neither platform offers:

- An org-level allowlist of approved signing keys

- A way to reject a push based on the signing key itself

- A built-in way to audit who has accessed what (You have to stream and parse the audit logs yourself!)

The workarounds I've seen, like re-verifying signatures in CI, blocking deployments on unapproved keys, self-hosting Git with pre-receive hooks, all share the same problem: the bad commit still lands in the repo. CI catches it after the fact.

Given recent supply chain attacks, this feels like table stakes, and I'm really fucking annoyed at Github for trying to shove Copilot down my throat instead of helping me with basics like this. We're considering issuing hardware keys to every dev, building a custom verification and audit pipeline, streaming audit logs to our own SIEM, and upgrading to enterprise tiers for basic visibility. That's a lot of work for something that should be built in.

So:

- Are any of you solving this cleanly today? Am I missing something?

- Is everyone relying on CI enforcement?

- Are there platforms that do proper key allowlisting + enforcement? - Or is the answer really "self-host everything and write hooks"?

I'm slowly losing my mind over this. We're a small dev shop and I can't believe we're the first ones to want to be able to fully trust our git log and Github history!

Feels like we're one compromised laptop away from "Verified" supply chain attacks.