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.
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.
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
- 01
Create a webhook receiver in infrastructure you control and store the GitHub webhook secret and ClawdCall API key in its secret manager.
- 02
Subscribe only to secret scanning alerts and validate every delivery with X-Hub-Signature-256 before parsing or acting.
- 03
Copy the policy gate below, add your protected-repository allowlist, and resolve one fixed security-owner number from internal configuration.
- 04
Persist X-GitHub-Delivery as the idempotency key before the outbound request.
- 05
Send the synthetic fixture through a local or staging receiver and inspect the generated ClawdCall request without placing a call.
- 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
- Use the provided synthetic JSON; it contains no credential, token, customer name, or real repository.
- Generate a test HMAC with a staging webhook secret and verify that a modified payload is rejected.
- Run the policy gate in dry-run mode and confirm the output never contains a secret value or raw diff.
- Route the first live call only to yourself and warn that it may consume calling minutes.
- Replay the same delivery ID and confirm the bridge refuses a second 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.
- 01
Persist X-GitHub-Delivery, repository full name, alert number, and returned call ID before calling.
- 02
Authenticate the completion callback and compare its call ID with the stored record before accepting an acknowledgment.
- 03
Write the named remediation owner and bounded action to the incident, issue, or security queue without changing the GitHub alert automatically.
- 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
- GitHub webhook eventsDocumented event availability, delivery headers, and payload actions.
- GitHub security-alert webhooksCreated/resolved/reopened behavior and the push-protection-bypass property.
- ClawdCall Agent APILive API contract for outbound calls and transcript retrieval.
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