シークレットスキャン検出パターンの更新と製品改善

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.

The post Secret scanning pattern updates and product improvements appeared first on The GitHub Blog.