Code Signing Infrastructure Breach Response

A compromised signing key is the quietest crisis in security. The signatures keep validating. The customers keep trusting. Nothing visibly breaks. Somewhere an attacker is using your key to sign payloads that your customers will install because they trust the publisher name. The incident has a fuse that may already have burned for weeks before anyone in your organisation notices. When you do notice, the response window is short, the stakes are high, and the sequence of correct actions is specific enough that teams who haven't rehearsed it usually get at least one step wrong.

This is the playbook I walk customers through in IR retainer engagements. It assumes a code signing key compromise, but the shape applies to any high-privilege signing infrastructure — release signing, artifact signing, SBOM signing, software bill of materials attestation.

The first twenty minutes

Three actions, in order:

1. Contain further exposure. Revoke the key's access from the signing infrastructure so no more signatures can be produced. For HSM-backed keys this means disabling the key or the authenticating identity. For KMS-backed keys, revoke the IAM role that invokes the signing operation. Do this first, before investigation. The cost of a false alarm is small; the cost of continued signing is catastrophic.

2. Preserve forensic state. Snapshot logs, HSM audit trails, KMS CloudTrail events, CI runner memory if feasible, the signing server disk if on-prem. The investigation that follows depends on this data; most organisations discover too late that their log retention covers a shorter window than the attack has been ongoing.

3. Call CA and issuing authority. If the key is backed by a publicly-trusted certificate (DigiCert, Sectigo, Entrust, let's-encrypt-for-code-signing has been sunset, so most enterprise signing uses one of the commercial CAs), notify them and initiate the revocation process. CA response times vary; starting this clock early matters.

This is the twenty-minute window. Everything else waits until these three are done.

Hours 1 to 8: scope determination

Who had access to the signing infrastructure during the compromise window? What did they produce? Four concrete queries:

• HSM/KMS signing operation log for the relevant time window. Every signed artifact should have a corresponding log entry. Gaps or unexpected entries are the bread and butter of the investigation.
• CI pipeline history for release jobs that invoked signing. Cross-reference against expected release cadence. An unexplained signing event is the highest-priority finding.
• Artifact repository publish events — every release that went to your public distribution points. Each one needs to be verified as legitimate.
• Git history in the signing-related repositories (release tooling, deployment scripts). Look for recent changes to signing logic or credentials.

The output of this hour is a table: every signed artifact produced during the compromise window, with its provenance verified or flagged.

Revocation decisions are nuanced

Revoking a code signing certificate has immediate customer impact: every installed copy of every release signed with that key may start failing signature verification, depending on the trust model in use.

• Strict timestamp-respecting verification (what most modern OS code signing trust stores use): revocation invalidates signatures that don't have a trusted timestamp predating the revocation time. Timestamped signatures from before compromise continue to validate.
• Strict any-revoked-invalidates verification (older models, some enterprise deployments): any revocation invalidates all signatures using that cert.

Determining which model your customers use, per-product per-platform, is the work of the next few hours. For Windows Authenticode signatures, the ruling model is timestamped verification. For SignTool-verified signatures on signed binaries, revocation with --reason=key_compromise and a specific revocation date preserves pre-compromise signatures.

The decision matrix:

• If you have trusted timestamps and a confident compromise window → revoke with a dated reason; pre-compromise signatures survive.
• If you don't have trusted timestamps → revocation breaks everything; plan for mass re-signing and customer notification.
• If the key was used for unsigned-timestamp artifacts (older practice) → prepare for broader impact.

The customer notification question

Most signing-key compromises eventually become public. The question is whether you control the disclosure or the disclosure controls you.

Factors favouring proactive disclosure:

• Customer installations may currently be running attacker-signed binaries.
• Regulatory notification obligations (EU CRA, financial services regs, NIS2) may apply.
• Security community trust compounds over years; disclosure builds it, hiding erodes it.

Factors favouring delayed disclosure:

• Active investigation might be tipped off to the attacker.
• Coordinated disclosure with other affected parties (if this is part of a broader campaign) may be in progress.

The usual right answer is disclose early with ranges and caveats rather than delay for perfect information. The template: acknowledge an investigation into a potential issue with a specific named component, commit to updating on a specific timeline, and provide guidance for customers in the interim.

Re-keying is the longest part

Issuing a new key, getting certificates issued, updating every part of the signing pipeline, producing and publishing re-signed artifacts — this is typically two to four weeks of work even for well-prepared organisations. Customers installing new releases need to trust the new key, which may require publishing the new cert's fingerprint through authoritative channels.

This is also the moment where many organisations realise the "one signing key for everything" pattern is poor hygiene. Splitting signing keys by product, by audience (consumer vs enterprise), or by signing purpose (release vs attestation) reduces future blast radius.

Post-incident review must be rigorous

The review asks four questions:

1. Detection latency: how long between compromise and detection? If weeks or months, the detection controls need work.
2. Response cleanliness: did any step go wrong? Was revocation too early (breaking customers) or too late?
3. Attack path: how did the attacker reach the signing infrastructure? This is usually a credential theft or a CI pipeline compromise that bridged to signing.
4. Cascading risk: what else did the same attack path expose? Signing infrastructure is rarely the only thing protected by the credentials that were compromised.

Preventive controls that actually help

Four that consistently reduce the likelihood of a signing incident:

• Signing operations only from HSM/KMS, never local keys. Eliminates the entire class of "key file on a server" attacks.
• Signing privilege requires in-person or MFA authentication at invocation. Not just "CI has the role" but "a human approves each signing event" for production releases.
• Signing events automatically produce a transparency log entry (Sigstore Rekor, internal log). Unexpected signatures become visible quickly.
• Separate signing identities per product/environment, with scoped permissions. Reduces blast radius of any single compromise.

How Safeguard Helps

Safeguard monitors signing infrastructure across the portfolio and flags unexpected signing events, credential access patterns, and drift in the signing pipeline. In an active incident, Griffin AI compiles the forensic timeline from HSM/KMS logs, artifact repository events, and CI pipeline history into a single narrative an IR lead can use to scope the incident. Policy gates can enforce MFA-gated signing for production releases and require transparency-log attestation for every signed artifact. For organisations whose code signing is load-bearing to customer trust, Safeguard compresses the incident-response preparation work that most teams only discover the cost of after the incident has started.