Closing the gap on trusted code changes

Release branches on GitHub are the source of truth for code deployed to production at Figma, making them an attractive target for attackers. As the company scales and more engineers ship code daily, the attack surface grows. Figma’s security engineering team built a solution to ensure code changes merged into release branches originate from trusted, company-managed devices.

Access to GitHub sits behind Single Sign-On (SSO) with Okta, which requires WebAuthn 2FA. That reduces risk significantly, but the organization remains vulnerable to malicious changes made with leaked session credentials, personal access tokens, OAuth tokens, and SSH keys. Figma already enforces “dual-control” on pull requests, requiring both the PR author and another engineer to approve changes.

The obvious mitigation—requiring GitHub’s commit signature verification—comes up short. Git commit signatures get the green “Verified” stamp on GitHub, but Figma has no visibility into the personal GPG keys engineers register, and no way to tie those keys to a specific device. GitHub’s verification criteria are also looser than Figma wanted: commits made through the GitHub UI and API are “Verified” because they’re signed with GitHub’s web flow GPG key. If an OAuth app, GitHub session, personal access token, or SSH key were compromised, an attacker would have multiple paths to get malicious commits marked “Verified” by GitHub.

Rather than monitoring long-lived access tokens for suspicious usage, Figma built its own verification system.

Device trust certificates as signing keys

Figma’s Endpoint Security Baseline requires up-to-date browser versions, the latest macOS, and active malware protection. In late 2022, the team built a custom solution issuing X.509 Okta Device Trust certificates to company MacBooks via an Amazon Private Certificate Authority (CA). These certificates are distributed through JAMF, renew every 15 days, and attest that a laptop met the Endpoint Security Baseline criteria at issuance time.

The team uses Okta Identity Engine to enforce device trust for AWS, Stripe, Snowflake, and other sensitive platforms, but the certificates aren’t limited to Okta. They can sign any data that uses X.509 certificates, including Git commits via S/MIME.

GitHub’s smimesign utility is an S/MIME signing tool for macOS and Windows compatible with Git, using keys and certificates already stored in the macOS Keychain or Windows Certificate Store. Standard setup lets developers sign commits with X.509 certificates from public CAs or an organization’s internal CA.

That standard setup wouldn’t work for Figma because signing keys change every 15 days when device trust certificates renew. Git calls the configured signing program with arguments that include a static key ID passed via -u <your_x509_key_id>. Figma needed Git to dynamically fetch the latest key ID at commit time. To solve this, the team built smimesign-figma, a modified version of GitHub’s utility, and added a --get-figmate-key-id flag that looks through the macOS Keychain and returns the user’s device trust certificate key ID.

They then wrote a one-line bash wrapper, smimesign-figma-wrapper, that ignores any arguments Git passes and instead executes smimesign-figma --get-figmate-key-id to fetch the current key. Git is configured to use this wrapper as the signing program. The value of user.signingkey is left blank; it never gets used in the signing process. Every commit is now signed with the device trust certificate on the engineer’s laptop, attesting the change originates from a trusted, company-managed MacBook.

Verifying signatures with Lambda and GitHub Apps

To verify signatures on the server side, Figma built a system that cryptographically confirms whether commits are signed with device trust certificates and reports results back to GitHub. The components:

  • A GitHub App in the Figma GitHub organization
  • A Lambda function using smimesign/ietf-cms to verify S/MIME commit signatures
  • A Lambda Function URL so GitHub can trigger the function
  • A GitHub webhook notifying Lambda when code is pushed to the monorepo
  • A webhook secret to verify requests are from GitHub

The “Commit Signature Verification” GitHub App has permissions to read code and write commit status checks. It’s installed in the monorepo with credentials stored in AWS Secrets Manager for Lambda authentication.

The end-to-end flow:

  1. An engineer pushes a signed commit to a feature branch on the monorepo.
  2. GitHub sends a webhook payload to the Lambda Function URL.
  3. Lambda authenticates as the GitHub App, verifies the webhook secret, and cryptographically verifies the HEAD commit was signed with a device trust certificate.
  4. Lambda posts a commit status called commit-integrity-verification back to GitHub indicating pass or fail.

With this in place, Figma requires a passing commit-integrity-verification status check on the most recent commit before a PR can merge into a release branch, ensuring changes shipping to production come from trusted devices.

Keeping bot commits on a short leash

Figma engineers author most commits in the monorepo, but internally and externally developed bots also contribute code, including GitHub’s Dependabot. These bots commit through the GitHub API and are signed with the same GitHub web flow GPG key mentioned previously.

Because the team now controls exactly which commits pass the commit-integrity-verification check, those bot commits can be validated against a trusted allowlist of authors. This reduces the risk of an untrusted bot—such as an externally developed GitHub App—submitting a malicious commit.

Beyond author checks, the system is able to inspect the actual code changes bots make and apply heuristics to flag unsafe modifications. For example, a change from Dependabot that is clearly unrelated to dependencies triggers a failed commit-integrity-verification status check.

Security without the operational drag

The resulting system is a significant security win for Figma. It enables GitHub’s security guarantees by default for repository history as long as integrity verification is enforced, and it lays groundwork for future security improvements to build and deploy pipelines. Best of all, the design requires almost no day-to-day maintenance from engineers.

Rather than accepting unnecessary risk or layering on cumbersome processes, the team built a safer posture by default. This focus on minimizing toil is a core value for the team, allowing it to move quickly on other initiatives that strengthen Figma’s overall security.