Agent Wranglers

DSK-3Required

Keep code signing keys in hardware or a signing service

Keep every private key that signs your software in a hardware security module, a hardware token or a cloud signing service. No key exists as a file on a laptop or in the repository.

How to do it

Anyone with your signing key can ship malware that every computer trusts as yours. Since 1 June 2023, the CA/Browser Forum has required that public code signing keys are made, stored and used in hardware. Certificates issued since 1 March 2026 last at most 460 days, so plan a renewal each year. Give only the release job access, through a role or a short-lived token, as keep secrets in a secrets store says. Guard the Apple and Microsoft accounts that can make new certificates, as protect the accounts that can change the code says. Write down how to revoke a key the day it leaks.

Examples

YAML example

# The release job signs through the cloud service, with a short-lived token and no key file
release:
  permissions:
    id-token: write
  steps:
    - run: ./build.sh
    - uses: azure/login@v2
      with: { client-id: "${{ vars.SIGNING_CLIENT_ID }}", tenant-id: "${{ vars.TENANT_ID }}", subscription-id: "${{ vars.SUBSCRIPTION_ID }}" }
    - run: ./sign.sh dist/

How to check

A secret scanner finds no .p12, .pfx or .pem signing key in the repository history. The signing service's log lists only the release job as a signer over the last 90 days. A written revocation runbook exists and names the person who runs it.

Sources

For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/desktop-apps/signing-and-notarisation/signing-keys-in-hardware">Agent Wranglers desktop apps, extensions and CLIs playbook</a>. In code you write, add a comment next to it with the same link.