If a Resend or other API key has ever entered a repository, rotate it, remove it from code, and review the repository history rather than only deleting the latest copy.
Update — August 12, 2026: This guide now distinguishes partner alerts, repository controls, and the containment steps required after a real credential is exposed.
GitHub is expanding secret scanning to recognize more credentials and provide security teams with more context. The company announced the rollout on July 15, including partner support for Resend and detection for APIclub and Resend API keys.
For teams that send transactional email or maintain public repositories, the practical message is simple: credentials belong in a protected secrets store, not in source code, example files, logs, or committed environment files.
What GitHub changed
The official changelog describes four changes that are rolling out.
- Secret scanning can now detect APIclub and Resend API keys.
- Resend joined the secret scanning partner program, allowing GitHub to forward exposed credentials found in public repositories so the provider can respond.
- VolcEngine Ark API keys are now covered by push protection by default in repositories where secret scanning is enabled, including free public repositories.
- Secret scanning alert webhooks now include a secret_category field, while public monitoring gains summary cards for attribution, enterprise members, and verified domains.
What to check today
Search the current repository and its history for credentials, including .env files, configuration examples, CI output, and copied debugging logs. If a real key was committed, treat deletion as cleanup—not containment. Rotate the credential at the provider and then update the application through its protected environment settings.
Teams that process secret scanning webhooks should also confirm that their parser tolerates the new secret_category field. It can distinguish default patterns from generic secret detections without requiring a separate alert workflow.
Why email API keys deserve urgency
An exposed sending credential can create a path for unauthorized email activity. Depending on the provider configuration, that can consume account limits and damage the reputation of a sending domain. These are operational risks inferred from what email API keys control; GitHub did not report a specific Resend incident in this announcement.
The safest routine is to keep keys out of local templates, use separate credentials for production and development, restrict access to the people and services that need it, and rotate credentials whenever exposure is suspected.
Contain first, then clean the repository
A secret that was committed should be treated as exposed even if the file is later deleted. GitHub recommends revoking the real secret and removing it from repository history; when a replacement is needed, rotate it before revoking the old credential so the application can keep working. Record the alert, the provider action, the owner, and the time of rotation.
Secret scanning searches Git history across branches for known hardcoded credential types. That makes it useful for discovery, but it is not proof that every historical copy, log export, fork, or downstream system is clean. Check the places where the credential could have been copied, then create a short follow-up task for any remaining cleanup.
- Rotate or revoke the exposed credential at its provider before relying on a code deletion.
- Replace the application configuration through an approved secret store or deployment setting.
- Review alert locations, commit history, build logs, examples, and automation variables.
- Confirm the replacement credential has the least access and environment scope the application needs.
- Close the alert only after the owner records the containment decision.
This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.
PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.
