Skip to content

PATTERN Cited by 1 source

Webhook-triggered verifier Lambda

Shape

On every event of interest at a SaaS (a Git push, a PR update, a build completion), trigger a stateless verification function that:

  1. Receives the event as a webhook payload at a public HTTPS endpoint (AWS Lambda Function URL, API Gateway route, Cloud Run service, etc.).
  2. Authenticates itself back to the SaaS as a least-privileged integration (GitHub App, OAuth App, API key with narrow scope).
  3. Verifies the webhook secret to confirm the payload is genuinely from the SaaS (not a forged public POST).
  4. Fetches whatever extra context it needs via the SaaS API.
  5. Runs the verification logic — cryptographic, policy, heuristic.
  6. Reports the result back to the SaaS as a status check / commit status / PR review / label / comment that gates the user's workflow.

The event system owns the trigger, the SaaS branch-protection owns the blocking, and the verifier is pure compute with minimal state.

Why it works

  • Stateless compute fits Lambda / Cloud Function economics — charge per invocation, scale to zero when no pushes are happening, no idle capacity.
  • Public HTTPS endpoint + webhook secret is the minimum-surface way to receive events without exposing infrastructure.
  • GitHub-App-style credentials let the verifier be scoped to the exact permissions it needs (concepts/least-privileged-access): typically read code + one narrow write scope (commit status, review state, label).
  • The SaaS's existing branch-protection machinery turns the verifier's output into a merge blocker without the verifier owning any UI.
  • Secrets (GitHub App private key, webhook secret, any API tokens) live in a managed secret store (systems/aws-secrets-manager or equivalent), not in code or env vars.

Trade-offs

  • Cold-start latency can show up in push → status-check pipeline. Not a blocker for async verification (the status check appears seconds later) but rules out synchronous hooks.
  • Webhook retry semantics must be handled — the verifier should be idempotent on (event, commit) pairs because SaaSes re-deliver webhooks on non-2xx.
  • GitHub App rate limits — fetching the diff for every push scales with push volume, not repo count.
  • Single-SaaS coupling — the pattern lives inside the SaaS's event
  • status-check model. Porting to a different SaaS requires swapping the integration shape.
  • Bot commits often can't meet the same cryptographic bar as human commits and need a separate allowlist / diff-heuristic path (see Figma's bot handling).

Canonical instantiation — Figma commit signature verification

  • GitHub App Commit Signature Verification with two permissions: read code, write commit status checks (systems/github-apps).
  • AWS Lambda Function URL as the webhook endpoint.
  • AWS Secrets Manager holds the GitHub App private key + webhook secret.
  • On push:
  • Lambda receives the push-event payload.
  • Authenticates as the GitHub App.
  • Verifies the webhook secret.
  • Fetches the HEAD commit's signature + changeset via GitHub API.
  • Cryptographically verifies via smimesign/ietf-cms against Figma's internal device-trust CA.
  • Posts commit-integrity-verification = pass/fail as a commit status.
  • Release-branch protection requires this status = pass.
  • Bot path: author allowlist + optional diff heuristics (Dependabot touching non-dependency files → fail).
  • See systems/figma-commit-signature-verification for the full pipeline.

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

Other applicable verifications

The same shape fits: secret-scanning, license compliance, Terraform policy, image-signature verification, SBOM checks, custom supply-chain gates — any "on event X, check Y, post status" policy.

Last updated · 200 distilled / 1,178 read