GitHub Secret Scanning Adds Resend, VolcEngine Blocks, and Webhook Categories

GitHub rolled out a batch of secret scanning improvements on 15 July 2026. Resend is now an official scanning partner, meaning any Resend API key found in a public repository is reported directly to Resend for action. Two new secret types are automatically detected across repositories (from APIclub and Resend), VolcEngine push protection is enabled by default, and a new webhook field lets teams categorise alerts without maintaining their own lookup tables.

What happened

Change	Detail
New partner	Resend joined GitHub’s secret scanning partnership program
New detectors	apiclub_api_key (APIclub), resend_api_key (Resend)
Push protection default	volcengine_ark_api_key (VolcEngine) now blocked on commit
Webhook field	secret_category added to secret_scanning_alert payload
Dashboard	Insight cards added to public monitoring alert list

Breaking down each change

Resend partnership and new detectors

GitHub’s secret scanning partnership program works by scanning public repositories for known token formats and forwarding any matches to the issuing company. Resend, an email API provider, is the latest to join. When GitHub finds a resend_api_key in a public repo, it sends that finding to Resend, who can then revoke the key or alert affected admins.

APIclub is also getting coverage with a new apiclub_api_key detector. Unlike partner secrets, which are reported to the issuer, user secrets generate alerts directly in your GitHub repository for both public and private repos.

VolcEngine push protection is now on by default

Push protection (the feature that blocks a git push before a secret reaches the remote) now covers volcengine_ark_api_key by default. This applies to every repository with secret scanning enabled, including free public repos. Previously, teams had to opt in to push protection for this secret type. Now it is enforced automatically.

New secret_category field in the webhook payload

The secret_scanning_alert webhook payload now includes a secret_category field. It takes one of two values:

• default: covers provider-specific patterns and any custom patterns you have defined.
• generic: covers broad generic patterns and AI-detected secrets.

Before this change, teams routing or filtering webhook alerts had to maintain their own mapping of secret types to categories. The new field mirrors the Default and Generic tabs already visible in the GitHub UI, so your automation can filter without that manual lookup.

Insight cards on the public monitoring alert list

Enterprise users on the public monitoring alert list now see three summary cards at the top of the page before scrolling through individual alerts:

1. Associated leaks by attribution: splits alert counts into “member activity” (commits authored by an enterprise member) and “verified domain” (committer email matching a verified domain).
2. Enterprise members: shows the total member count, matching what appears in the enterprise People tab.
3. Verified domains: lists all verified domains tied to your enterprise, covering both enterprise-owned and organisation-owned domains.

Why it matters

Leaked API keys are one of the most common causes of account takeovers and unexpected API bills. Push protection catching VolcEngine keys before they land in a repository is a meaningful default change, especially for teams without a dedicated security review step in their workflow.

The webhook secret_category field is the kind of small detail that saves real engineering time. If you route alerts into a SIEM (security information and event management system) or a Slack bot, you no longer need a lookup table to separate high-confidence provider matches from noisier generic detections.

For enterprise teams using public monitoring, the insight cards bring context that previously required a separate query. Knowing whether a leak came from a verified domain or a member commit changes how you respond. If you are building or maintaining automation around GitHub alerts, our workflow automation services can help you connect these webhooks to your existing incident tools.

Our take

These are incremental but genuinely useful changes. GitHub is good at adding coverage quietly, and most developers only notice secret scanning when it saves them from a real incident. The Resend partnership is straightforward and low-friction for developers. The VolcEngine push protection default is the most impactful item here because it requires no action from teams to benefit.

The secret_category webhook field is the one worth acting on if you have built any custom alerting. It is a small schema change that cleans up a real piece of operational mess. Check the recent GitHub Copilot update coverage on our news feed if you want broader context on how GitHub is layering security tooling across its platform.

One honest caveat: none of this replaces a process for rotating secrets regularly or auditing third-party access. Detection is a safety net, not a substitute for good key hygiene.

What to do about it

1. Check whether your repositories use any of the three new secret types (Resend, APIclub, VolcEngine) and confirm your existing keys are not already exposed.
2. If you have a secret_scanning_alert webhook integration, update your handler to read the new secret_category field and adjust your routing logic.
3. Enterprise admins: open the public monitoring alert list and review the new insight cards to get a baseline of current exposure by attribution type.
4. If your team wants to partner with GitHub’s scanning program, open a support ticket with GitHub to start the process.

The practical takeaway: if you route GitHub security webhooks into any automation, add secret_category to your filter logic now before alert volume grows.

Source: GitHub Changelog