























This week, we’re rolling out two improvements to our delegated workflows for secret scanning.
is_bypassed REST API filter: You can now filter by an is_bypassed query parameter when listing alerts, closing a gap with filtering that was already available in the UI.These changes make it easier for organizations to manage requests at scale.
Previously, push protection bypass requests and alert dismissal requests appeared in a fixed order (newest-first). For large organizations, lack of control over sorting made it challenging to manage high volumes of requests. You can now order requests by Newest, Oldest, Recently updated, and Least recently updated directly in the filter UI bar, allowing security analysts and developers to focus on soonest-expiring requests.
Sorting is available at the repository, organization, and enterprise levels for both push protection bypass requests and alert dismissal requests. This improvement makes it substantially easier to manage requests at scale from the UI list view.
is_bypassed REST API filterPreviously, the bypassed:true,false qualifier was supported from the UI list view for push protection bypass requests, without an equivalent filter option in the REST API. This improvement makes it easier to programmatically filter alerts by push protection bypasses without additional processing.
The secret scanning alerts API now accepts an is_bypassed boolean query parameter on all three list endpoints:
GET /repos/{owner}/{repo}/secret-scanning/alertsGET /orgs/{org}/secret-scanning/alertsGET /enterprises/{enterprise}/secret-scanning/alertsPass is_bypassed=true to return only alerts where push protection was bypassed, or is_bypassed=false to exclude them.
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。