ClawdCall
Signed webhook recipeU0 · act immediatelyTemplate checks passed 2026-09-06

Build a GitHub secret scanning phone alert for exposed credentials

Verify the signed webhook, confirm the alert is open in a protected production repository, and place one acknowledged call—without sending the detected credential to ClawdCall.

Give the security owner enough safe context to acknowledge the incident and start rotation—without repeating or forwarding the credential.

Independent workflow recipe; not endorsed by or affiliated with GitHub. Automated checks verify route data, downloadable assets, fail-closed policy gates, secret scans, and the production build. This is not a live vendor-account certification. Complete one supervised call to yourself before production use; live calls can consume calling minutes.

Quick Answer

How can a GitHub secret scanning alert trigger a phone call?

Subscribe a repository, organization, or GitHub App webhook to secret_scanning_alert events. Verify X-Hub-Signature-256 before parsing, allow only current open alerts from protected repositories, and deduplicate X-GitHub-Delivery. Then call the configured security owner with the repository, secret type, and required action—never the detected value.

01GitHub secret alert
02Signed policy gate
03Security-owner phone call
04Acknowledgment + owner

Why Phone?

Use a phone call only when someone can rotate or revoke now.

Routine security findings belong in the normal queue. An open credential exposure in a protected production repository warrants a stronger interruption when a named owner can immediately acknowledge and begin remediation.

Verified trigger

Verify the secret-scanning event

A GitHub secret_scanning_alert webhook with action created, optionally narrowed to alerts where push protection was bypassed.

Policy gate

Allow one safe owner call

Verify the webhook signature, require the alert to be open and current, match an allowlisted production repository, resolve a known owner, and reject duplicate delivery IDs.

Returned outcome

Record acknowledgment and ownership

Store the call ID, collect acknowledgment and remediation ownership, then update the incident or security workflow—never the secret value itself.

Before You Start

Requirements

  • GitHub secret scanning enabled for the repository or organization
  • A repository, organization, or GitHub App webhook subscribed to secret_scanning_alert
  • A private bridge that validates X-Hub-Signature-256 before calling ClawdCall
  • An allowlist of production repositories and one pre-authorized security owner
  • A durable store for X-GitHub-Delivery idempotency

When It Calls

All filters must pass

  • X-GitHub-Event equals secret_scanning_alert
  • action equals created and alert state is open
  • repository full name is in the protected-production allowlist
  • Optional: push_protection_bypassed equals true for the narrowest urgent path
  • A security owner is assigned and no acknowledgment exists
  • X-GitHub-Delivery has not already been processed

Spoken Preview

What the expected recipient hears

GitHub detected a synthetic secret-scanning alert for the example payments repository. No secret value is included. Please acknowledge and say whether you will start rotation now or need backup.

Field Map

Build the call from safe, explicit fields.

SourceDestinationTreatment
X-GitHub-Deliverydedupe keyPersist before calling; ignore a repeated delivery.
repository.full_nametasksAllowlist first, then speak the repository label only.
alert.secret_type_display_nametasksSpeak the secret type, never the secret or raw match.
alert.push_protection_bypassedtasksUse only as risk context; do not infer intent.
configured security ownertargetResolve from an internal map, not the webhook sender.

Copyable Gate

Fail-closed GitHub policy gate

import { createHmac, timingSafeEqual } from "node:crypto";

export function verifyGitHubSignature(rawBody, signature, webhookSecret) {
  if (!signature?.startsWith("sha256=") || !webhookSecret) return false;
  const expected = createHmac("sha256", webhookSecret).update(rawBody).digest();
  const received = Buffer.from(signature.slice(7), "hex");
  return expected.length === received.length && timingSafeEqual(expected, received);
}

export function shouldEscalate(headers, payload, productionRepos) {
  const event = headers.get("x-github-event");
  const delivery = headers.get("x-github-delivery");
  const repo = payload.repository?.full_name;
  const alert = payload.alert;

  return Boolean(
    delivery &&
    event === "secret_scanning_alert" &&
    payload.action === "created" &&
    alert?.state === "open" &&
    repo && productionRepos.has(repo)
  );
}

// Call verifyGitHubSignature(rawBody, signature, secret) before this gate.
// Build the call from safe allowlisted fields. Never include the secret value.

Implementation

Set up the recipe

  1. 01

    Create a webhook receiver in infrastructure you control and store the GitHub webhook secret and ClawdCall API key in its secret manager.

  2. 02

    Subscribe only to secret scanning alerts and validate every delivery with X-Hub-Signature-256 before parsing or acting.

  3. 03

    Copy the policy gate below, add your protected-repository allowlist, and resolve one fixed security-owner number from internal configuration.

  4. 04

    Persist X-GitHub-Delivery as the idempotency key before the outbound request.

  5. 05

    Send the synthetic fixture through a local or staging receiver and inspect the generated ClawdCall request without placing a call.

  6. 06

    Explicitly approve one self-call, enable the outbound request, and confirm the call returns an ID before connecting a live repository.

Safe Test

Synthetic event to one self-call

  1. Use the provided synthetic JSON; it contains no credential, token, customer name, or real repository.
  2. Generate a test HMAC with a staging webhook secret and verify that a modified payload is rejected.
  3. Run the policy gate in dry-run mode and confirm the output never contains a secret value or raw diff.
  4. Route the first live call only to yourself and warn that it may consume calling minutes.
  5. Replay the same delivery ID and confirm the bridge refuses a second call.
Start a supervised self-call

Expected result shape

  • status: completed
  • acknowledged: true
  • remediation owner: security-on-call
  • action: rotate or revoke now
  • spoken secret value: never included

Treat the live ClawdCall response and transcript as the source of truth. Do not fabricate a call ID, completion state, or human response.

Callback and Correlation

Correlate the acknowledgment without copying the exposed secret

The security workflow should join the completed call to the GitHub delivery and alert number, not to any credential value. That keeps callback handling useful for incident response without moving the secret into another system.

  1. 01

    Persist X-GitHub-Delivery, repository full name, alert number, and returned call ID before calling.

  2. 02

    Authenticate the completion callback and compare its call ID with the stored record before accepting an acknowledgment.

  3. 03

    Write the named remediation owner and bounded action to the incident, issue, or security queue without changing the GitHub alert automatically.

  4. 04

    Mark the delivery complete atomically so a webhook redelivery or callback retry cannot create a second escalation.

Production Guardrails

Keep routine noise and sensitive data off the phone.

  • Never put the detected secret, raw match, diff, commit content, or sensitive log text into tasks or introMessage.
  • Do not trust the sender field as the responsible owner; use an internal allowlisted routing map.
  • Verify the SHA-256 signature against the raw request body before parsing JSON.
  • Call only for current, open alerts in protected production repositories.
  • Use one call per delivery or alert state and stop immediately after acknowledgment.

Troubleshooting

Fail closed, then inspect the gate.

Signature validation fails for every request.

Compute the HMAC over the untouched raw request bytes and compare against X-Hub-Signature-256 using constant-time comparison.

The fixture passes but live alerts stay quiet.

Confirm webhook scope, Secret scanning alerts permission, event subscription, action value, repository allowlist, and alert state.

A redelivery creates a second call.

Persist X-GitHub-Delivery before placing the call and make the write atomic.

The call includes sensitive detail.

Build the spoken task from an explicit safe-field allowlist; never serialize the webhook payload into the prompt.

FAQ

Questions about this workflow

Why does a GitHub secret alert warrant a phone call?

For an open credential exposure in a protected production repository, delay can increase time-to-damage and a security owner can rotate or revoke the credential immediately. Routine code alerts should remain in normal queues.

Should the call read the exposed credential?

Never. Speak only safe context such as the repository label, secret type, exposure class, and requested remediation.

Is this an official GitHub integration?

No. It is an independent signed-webhook recipe that connects GitHub's documented event to the ClawdCall API through infrastructure you control.

Verification Sources

Vendor behavior and API references

Continue Building

Test, verify, and price the complete phone workflow.

First Call

Verify the full path with one call to yourself.

Once the self-call completes and the workflow returns a real outcome, replace the fixture with a narrowly filtered production event.

Start a supervised self-call