API、Webhook、委任ワークフロー向けシークレットスキャン改善

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

What’s changing

Secret scanning has new API filters, richer webhook payloads, and improvements to delegated alert workflows:

New exclude_secret_types filter: Exclusion filtering already available in the GitHub UI (-secret-type:) is now available in the REST API.

html_url on alert locations: Alert location details now include a direct link to the content on GitHub, in both the REST API and webhooks.

Delegated bypass email improvements: Reviewers now see expiry deadlines in request emails, and developers get a confirmation email when they submit a dismissal request.

Closure request comments in API/webhooks: The requester’s comment, reviewer’s comment, and reviewer’s username are now surfaced on alert payloads for delegated closures.

Bug fix: resolution_comment is no longer null when an alert is closed through delegated closure approval.

New exclude_secret_types API filter

New secret types are frequently added to GitHub, which means organizations using inclusion-based filters in their reporting and remediation scripts have to manually check for and add new patterns on a regular basis. With exclusion filters, you can simply filter out the types you don’t care about and automatically pick up new ones as they’re added.

The secret scanning alerts API now supports an exclude_secret_types query parameter, allowing you to exclude specific secret types from results rather than having to enumerate every type. This is available on all three list endpoints:

GET /repos/{owner}/{repo}/secret-scanning/alerts

GET /orgs/{org}/secret-scanning/alerts

GET /enterprises/{enterprise}/secret-scanning/alerts

You can pass a comma-separated list of secret type slugs to exclude them from results. Using both secret_type and exclude_secret_types in the same request returns a 422 error.

Alert location html_url field

Secret scanning alert locations in the REST API and webhook payloads now include an html_url field in the details object. Previously, location details only returned API URLs (e.g., /repos/{owner}/{repo}/issues/comments/{id}), so if you were processing webhook events or building automation on top of the locations API, you had to make additional API calls just to get a link you could actually click on or include in a notification. Now the user-facing URL is included directly.

The field covers commit, issue, pull request, and review locations:

Location type

Example html_url

commit

/{owner}/{repo}/blob/{sha}/{path}#L5-L5

issue_title / issue_body

/{owner}/{repo}/issues/{number}

issue_comment

/{owner}/{repo}/issues/{number}#issuecomment-{id}

pull_request_title / pull_request_body

/{owner}/{repo}/pull/{number}

pull_request_comment

/{owner}/{repo}/pull/{number}#issuecomment-{id}

pull_request_review

/{owner}/{repo}/pull/{number}#pullrequestreview-{id}

pull_request_review_comment

/{owner}/{repo}/pull/{number}#discussion_r{id}

All existing URL fields are preserved; html_url is additive only. This field is available in both the REST API (i.e., GET /repos/{owner}/{repo}/secret-scanning/alerts/{number}/locations) and webhook payloads.

Email notifications for delegated bypass requests

We’ve added two improvements to the email notifications sent during delegated bypass workflows:

Expiry notice: Email notifications for bypass and dismissal requests now include the request’s expiration period (7 days, 30 days, or 1 year depending on the request type), so reviewers know how long they have to act before the request is automatically closed. Different request types have different expiration periods (e.g., push protection bypasses expire in 7 days, while code scanning dismissals last a year). Previously there was no way to tell from the email alone.

Developer confirmation email: Developers now receive an email when they submit an alert dismissal request, letting them know it’s pending review. Previously, only reviewers were notified when a request was created—the developer who submitted it received no feedback at all until it was approved or denied.

Closure request comments in alert API and webhooks

Three new fields are now available on secret scanning alert payloads for alerts with a delegated closure (dismissal) request:

closure_request_comment: The requester’s comment explaining why they want to close the alert.

closure_request_reviewer_comment: The reviewer’s response comment.

closure_request_reviewer: The reviewer user object.

These fields follow the same model as the existing push protection bypass fields (i.e., push_protection_bypass_request_comment, push_protection_bypass_request_reviewer_comment). If you’re building automation around delegated alert closures—such as tracking why alerts were dismissed, auditing reviewer decisions, or syncing with external ticketing systems—this data is now available directly in the API and webhook payloads without needing to look it up separately.

Bug fix: resolution_comment for delegated closures

Fixed a bug where resolution_comment was null on alerts closed through the delegated alert closure approval flow. The requester’s comment was being stored on the exemption request but was not forwarded to the alert when the request was approved. The comment is now correctly passed through to the alert’s resolution_comment field, matching the behavior of direct dismissals via the REST API.

Learn more

Learn more about secret scanning and the secret scanning REST API in our documentation. These improvements were shaped by your feedback. Let us know what you think in the community discussion.

The post Secret scanning improvements to alert APIs, webhooks, and delegated workflows appeared first on The GitHub Blog.