Skip to content

PATTERN Cited by 1 source

Signed commit as device attestation

Shape

Use the device-trust X.509 certificate already installed on corporate laptops as the Git commit signing key, then verify signatures on push to cryptographically prove each commit originated on a trusted managed endpoint. Make the signature check a required status check on release-branch merges so out-of-policy code cannot ship.

Why it works

  1. The corporate CA already issues X.509 certs to managed devices for identity / mTLS / VPN purposes — no separate signing-key infrastructure needed.
  2. Certs rotate frequently (Figma: every 15 days), so compromised keys time out quickly; PKI lifecycle already handles revocation.
  3. S/MIME (PKCS#7) is a first-class Git signing format (gpg.format=x509), so no Git fork is required.
  4. The verifier runs out-of-band of the developer workflow — a webhook-triggered Lambda (patterns/webhook-triggered-verifier-lambda) posts a commit status check, and branch protection rules make that status a merge blocker. Engineers experience the control only as a green check mark.
  5. Bot commits (which don't have device-trust certs) are routed through a separate author allowlist so the policy doesn't break Dependabot / other trusted automation.

Trade-offs

  • Bound to enterprise PKI — works if you already run device-trust; not a zero-to-one pattern.
  • OS keystore coupling — implementation needs platform-specific keystore plugins (macOS Keychain, Windows Cert Store). Linux engineers typically underserved.
  • Short cert lifetimes break the standard signer interface. Git's S/MIME signer is invoked with a static user.signingkey argument; device-trust certs rotate. Bridged via patterns/wrapper-script-arg-injection.
  • Attests origin, not intent. A signed commit proves the bytes came from a trusted device; it does not prove the authorised developer reviewed them. User-identity signing and this pattern are complementary, not substitutes.
  • Bot commits need a separate policy — without an allowlist layer, all bot-authored commits fail verification.

Canonical instantiation — Figma

  • Every Figma MacBook carries a 15-day-rotated device-trust X.509 cert in the macOS Keychain.
  • Git is configured with gpg.format=x509 + a custom wrapper signer that uses smimesign-figma to sign each commit with the current device-trust cert.
  • On push, GitHub fires a webhook to an AWS Lambda (systems/figma-commit-signature-verification); the Lambda verifies the HEAD commit signature against Figma's internal device-trust CA and posts commit-integrity-verification as a commit status.
  • Release-branch protection requires this status to pass → merges are blocked for commits not signed by a trusted device.
  • Bot commits (signed with GitHub's web-flow GPG key) pass through an allowlist; for Dependabot, an optional diff-heuristics layer fails the status on out-of-scope changes.

Source: sources/2026-04-21-figma-enforcing-device-trust-on-code-changes

Last updated · 200 distilled / 1,178 read