This week, we’re rolling out several improvements to our detection coverage, APIs, and workflows. These improvements strengthen our continued investment in the developer experience of our secret scanning features. Built by developers, for developers.

Detection coverage

  • New Cloudflare detectors: Cloudflare is now a secret scanning partner.

Push protection

  • Forks for enterprise-managed users: User-owned forks in EMU enterprises now inherit push protection from their nearest licensed ancestor repository.
  • Push protection defaults expanded: Figma, GCP, Langchain, OpenVSX, and PostHog patterns now block commits containing matching secrets by default.

Secret metadata

  • Set validity on custom pattern alerts via API: You can now mark custom pattern alerts as active or inactive directly through the PATCH endpoint.
  • Team and Topic filters for secret scanning campaigns: Campaigns now support the same team and topic filter options as code scanning campaigns.
  • Provider field and filtering in the alerts API: Alert responses now include provider and provider_slug, with new providers and exclude_providers query parameters on all three list endpoints.

Scan history and delegation lists

  • AI-detected secrets in scan history API: AI-detected (generic secrets) backfill scans now appear in the scan history API response.
  • Enterprise API for listing dismissal requests: A new endpoint lets enterprise owners and security managers list secret scanning dismissal requests across all orgs in an enterprise.

Detectors added

Secret scanning now automatically detects the following new secret types in your repositories.

Provider Secret type Partner User Push protection
Cloudflare cloudflare_account_api_token ✓ ✓ ✓ (default)
Cloudflare cloudflare_global_user_api_key ✓ ✓ ✓ (default)
Cloudflare cloudflare_user_api_token ✓ ✓ ✓ (default)

Partner secrets are automatically reported to the secret issuer when found in public repositories through the secret scanning partnership program. User secrets generate secret scanning alerts when found in public or private repositories. Learn more in our documentation about secret scanning.

Push protection improvements

EMU user-owned forks

In EMU enterprises, developers often fork organization repositories into their personal namespaces. Previously, push protection only applied to those forks if the fork itself had an active GHAS license, meaning the same secrets blocked in the org repository could slip through in a fork.

Push protection now walks the ancestor chain. When any repository in the fork hierarchy has push protection enabled, all forks beneath it automatically inherit that protection.

Push protection defaults expanded

The following detectors are now included in push protection by default. Repositories with secret scanning enabled, including free public repositories, will have commits containing these secrets automatically blocked.

Provider Secret type
Cloudflare cloudflare_account_api_token
Cloudflare cloudflare_global_user_api_key
Cloudflare cloudflare_user_api_token
Figma figma_scim_token
Google google_gcp_api_key_bound_service_account
Langchain langsmith_license_key
Langchain langsmith_scim_bearer_token
OpenVSX openvsx_access_token
PostHog posthog_personal_api_key

Patterns that are not yet enabled by default remain configurable in your push protection settings for GitHub Secret Protection and GitHub Advanced Security customers.

Secret metadata improvements

Set validity on custom pattern alerts via API

When you create custom patterns to detect proprietary or internal secrets, you often have context that automated validity checks don’t: you know whether a flagged token is real or already rotated. Previously there was no way to record that judgment in the API. You could resolve or dismiss an alert, but validity was read-only.

You can now manually set the validity field on custom pattern secret scanning alerts using the existing PATCH endpoint:

PATCH /repos/{owner}/{repo}/secret-scanning/alerts/{alert_number}

Set an alert to active (confirmed live secret), inactive (confirmed not a threat), or clear your override by sending null. The value you set is reflected immediately in:

  • GET alert responses
  • The alert detail UI (header and timeline entry)
  • Webhook payloads
  • Audit logs

This is scoped to custom pattern alerts only. Standard validity (for GitHub-supported patterns) continues to be automatically set by our validators and is not overridable via this endpoint.

Team and Topic filters for secret scanning campaigns

When creating a secret scanning campaign, you can now filter the alert set by GitHub Team and Topic, the same filter options already available in code scanning campaigns and in the standard (non-campaign) secret scanning alert view. Previously, the campaign alert filter bar was missing these two options, making it harder to scope a campaign to repositories owned by a specific team.

Provider field and filtering in the alerts API

If you’re building automation on top of secret scanning alerts (e.g., routing them to different teams by provider, or reporting on alerts from a specific set of integrations) you previously had no way to filter by provider through the API, and the provider name wasn’t in the response payload.

The alert response now includes two new fields:

  • provider: The provider display name (e.g., "Stripe")
  • provider_slug: A machine-friendly identifier (e.g., "stripe") following the same slug convention as secret_type

Two new query parameters are available on all three list endpoints (/repos, /orgs, /enterprises):

  • providers: Include only alerts from these providers (comma-separated slugs).
  • exclude_providers: Exclude alerts from these providers (comma-separated slugs).

providers and exclude_providers are mutually exclusive—using both returns a 422. The provider field is also included in webhook payloads.

Scan history and delegation list improvements

AI detection in scan history API

GitHub’s AI-powered generic secret detection runs backfill scans across your repositories, but until now those scans didn’t show up in the scan history API.

The scan history API response now includes a generic_secrets_backfill_scans array, following the same structure as existing scan types (backfill_scans, pattern_update_scans, etc.).

Enterprise API: List secret scanning alert dismissal requests

Enterprise security teams that use delegated alert closures needed a way to audit and report on dismissal requests across their entire enterprise, not just one organization at a time. Previously, the only available endpoint was org-level.

A new endpoint is now available:

GET /enterprises/{enterprise}/dismissal-requests/secret-scanning

It lists secret scanning alert dismissal requests across all organizations in the enterprise, with support for filtering by organization_name, reviewer, requester, time_period, and request_status, plus pagination. Access requires enterprise owner or enterprise security manager (ESM) permissions.

Learn more

Learn more about secret scanning and see the full list of supported secrets in our documentation. These improvements were shaped by your feedback. Let us know what you think in the community discussion.