But somebody has access to the signing keys/signing process. And somebody has access to the production machines. Etc.

Yes, but that changes the scenario from a "small handful of engineers" that can all do it unilaterally, to needing at least one person from N different teams to collaborate.

And in my specific case, the group with the singing keys is also the group paid to tell us "no" whenever a release is blocked by process reasons.

My guess is that most people with access to signing keys or prod environments would have enough skills to code in some sabotage bugs before deployment or siphon off some data, so a lone devops person with (physical) access could probably a lot of harm just by themself.

Sure, I’m just saying our commitment to process is strong enough that the technical systems are a funnel into following a reasonable process.

I got dragged into defending my technical solution, but my point was that if the ability isn’t needed, don’t have it. You can break the glass when when you need to. Good process make deviation from it more visible. Our code signing keys belong to a team we already need wet ink signatures from to release software.

I can go into the biohazard labs with shorts on easier than I can leverage our technical disaster recovery. I’ve only ever had to do the latter.

If a single person holds the keys, that's a different problem altogether. https://en.wikipedia.org/wiki/Bus_factor

Heh Heh Heh

You know that backup system your production servers have?

That also has perfect _write access_ to everything, and it's needed so _restoring_ after something goes wrong works.