ClawdCall

Turn a GitHub secret scanning alert into a phone escalation

Use the GitHub secret_scanning_alert webhook to call a trusted security owner only when a new production alert is open. Verify the signature, suppress redeliveries, and never send the secret value to ClawdCall.

Independent guide; not affiliated with GitHub. Test with your own number first. Calls may use minutes.

01Secret found
02Verify alert
03Call security
04Record action

The event

Verify the secret-scanning event

GitHub sends a new secret_scanning_alert webhook.

The checks

Check the alert before calling

The signature is valid, the alert is open, the repository is approved, and the delivery ID is new.

After the call

Record acknowledgment and ownership

Record who owns the incident and whether rotation or revocation has started.

How do you escalate a GitHub secret scanning alert safely?

Start with GitHub push protection so supported secrets are blocked before they land. For an alert that is created or reopened, verify X-Hub-Signature-256 against the untouched request body, require an approved production repository, and reject repeated X-GitHub-Delivery IDs. The call may name the repository and secret type, but never the detected value, diff, or raw webhook body.

Decision guide

Choose the right response to a GitHub secret

Prevention, routine triage, and urgent escalation are different jobs. Use the least disruptive path that still gets the credential contained in time.

Best for

GitHub Push Protection

Blocking supported secrets before they land. Make prevention the first line of defense and review bypass behavior for protected repositories.

Best for

Security queue or SIEM

Routine alert triage and broad reporting. Send normal findings to GitHub's security queue or your existing security platform for ownership and investigation.

Best for

ClawdCall signed webhook

An open production alert that needs action now. Call one trusted owner with an allowlisted brief, collect acknowledgment, and keep the secret out of the phone workflow.

Call rules

Call only when

  • The signature matches the raw request body
  • The alert is new and still open
  • The repository is on your production allowlist
  • The delivery ID has not been processed

Example message

What they hear

“GitHub found a secret in payments-api. No secret value is included. Say rotating now or need backup.”

Setup

Connect the pieces

  1. 01

    Create a private webhook receiver and store both secrets in its secret manager.

  2. 02

    Subscribe to secret scanning alerts and verify X-Hub-Signature-256.

  3. 03

    Add your repository allowlist and map each repository to a security owner.

  4. 04

    Save X-GitHub-Delivery before making one test call to yourself.

Code

GitHub call rules

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.

First run

Try it without a live event

  1. Send the sample JSON with a valid test signature.
  2. Confirm that the call payload contains no secret or diff.
  3. Replay the delivery ID and confirm that no second call is made.
Test with your own number

Before it goes live

Keep the call focused

  • Never include the secret, raw match, diff, commit, or logs.
  • Use an internal owner map; do not trust the webhook sender field.
  • Verify the signature and allow one call per delivery.

Handling the result

Correlate the acknowledgment without copying the exposed secret

Match the call to the delivery ID and alert number, never to the secret value.

  1. 01

    Save the delivery ID, alert number, and call ID together.

  2. 02

    Authenticate the callback and check its call ID.

  3. 03

    Update the security queue once. Do not change the GitHub alert automatically.

GitHub workflow FAQ

Common setup and handoff questions

What is GitHub secret scanning?

GitHub secret scanning looks for known credential patterns and other supported secrets in repository content and creates alerts that security teams can review. Availability and detection scope depend on repository type and enabled GitHub security features.

Does GitHub secret scanning stop secrets from being pushed?

Secret scanning detects exposed secrets. Push protection is the feature that can block supported secrets during a push. A bypass or a secret found elsewhere can still create an alert that needs triage.

Can GitHub secret scanning send a webhook?

Yes. Repository, organization, and GitHub App webhooks can subscribe to secret_scanning_alert activity when the required permissions and feature access are present. GitHub can send events when alerts are created, resolved, revoked, reopened, or otherwise updated.

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

Send the signed webhook to a private bridge, validate the HMAC before parsing, allowlist the repository and action, deduplicate X-GitHub-Delivery, resolve a trusted owner, and then create a ClawdCall request from safe fields only.

Should the phone call include the exposed secret value?

Never. The recipient needs the repository name, secret type, and requested action, not the credential, raw match, diff, commit content, or complete webhook payload.

Sources

Documentation used for this recipe