What signing actually verifies
Code signing cryptographically signs a software release so anything running or installing it can verify both who produced it and that it hasn't been altered since it was signed. A system checking a code-signing signature before executing or installing something refuses anything that fails verification, regardless of how legitimate it otherwise appears — which is exactly the point: the check doesn't rely on the release looking trustworthy, it relies on the signature actually being valid.
This guarantee is only as strong as the key that produces the signature. A code-signing key that leaks lets an attacker produce releases that pass verification as if they genuinely came from the organization, which makes that key one of the highest-value targets in the entire release pipeline — a compromise there doesn't expose one release, it lets an attacker convincingly impersonate every future release until the compromise is discovered and the key revoked.
Protecting the key deserves the same rigor as protecting the code
Because the key's compromise is so disproportionately consequential relative to almost any other single credential in the pipeline, it deserves protection commensurate with that risk — hardware-backed storage, tightly restricted access to who can invoke a signing operation, and separation between whoever can propose a release and whoever can actually sign it. A pipeline that reviews code changes carefully but protects the signing key casually has built rigorous review on top of a foundation that a single compromised credential can bypass entirely.