シークレットスキャン承認リクエストのソート順とバイパスステータスによるフィルタリング機能の追加
GitHub は、デレゲートワークフローにおけるシークレットスキャンの承認リクエスト管理を改善し、UI での昇降順選択と REST API へのバイパス状態フィルタ機能を導入した。
今週、シークレットスキャンの委任ワークフローに対して2つの改善点をリリースします。
何が変わるか
UI でのバイパスおよび却下リクエストのソート: UI の承認リクエストリストにおいて、昇順と降順の切り替えが可能になりました。
新しい is_bypassed REST API フィルター: アラートをリストする際に、is_bypassed クエリパラメータによるフィルタリングが可能になり、UI で既に利用可能なフィルタリング機能とのギャップが埋まりました。
これらの変更により、組織はより大規模なリクエスト管理を容易に行えるようになります。
バイパスおよび却下リクエストのソート
以前、プッシュ保護バイパスリクエストとアラート却下リクエストは固定された順序（最新順）で表示されていました。大規模な組織では、ソート制御の欠如により、大量のリクエストを管理することが困難でした。現在は、フィルタ UI バー内で「最新」「最古」「最近更新されたもの」「最も長く更新されていないもの」の順にリクエストを並べ替えることができ、セキュリティアナリストや開発者は期限が迫っているリクエストに集中できるようになりました。
プッシュ保護バイパスリクエストとアラート却下リクエストの両方において、リポジトリレベル、組織レベル、エンタープライズレベルでソート機能が利用可能です。この改善により、UI リストビューから大規模なリクエスト管理が劇的に容易になります。
新しい is_bypassed REST API フィルター
以前、プッシュ保護バイパスリクエストについては UI リストビューから bypassed:true,false Qualifier がサポートされていましたが、REST API には同等のフィルターオプションがありませんでした。この改善により、追加処理を行わずにプログラムでプッシュ保護によるバイパスを基準にアラートをフィルタリングしやすくなりました。
シークレットスキャンアラートAPIは、すべての3つのリストエンドポイントにおいて、is_bypassed ブール値クエリパラメータを受け付けるようになりました:
GET /repos/{owner}/{repo}/secret-scanning/alerts
GET /orgs/{org}/secret-scanning/alerts
GET /enterprises/{enterprise}/secret-scanning/alerts
プッシュ保護がバイパスされたアラートのみを返すには is_bypassed=true を、除外する場合は is_bypassed=false を指定してください。
詳細情報
ドキュメントでシークレットスキャンおよびシークレットスキャン REST API について詳しく学ぶことができます。これらの改善は、皆様からのフィードバックに基づいて実現されました。コミュニティディスカッションでのご意見をお聞かせください。
「ソート順とバイパスステータスでシークレットスキャン承認リクエストをフィルタリング」という記事は、最初に The GitHub Blog で公開されました。
原文を表示
This week, we’re rolling out two improvements to our delegated workflows for secret scanning.
What’s changing
Sort bypass and dismissal requests in the UI: You can now choose between ascending and descending order for approval request lists in the UI.
New 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.
Sort bypass and dismissal requests
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.
New is_bypassed REST API filter
Previously, 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/alerts
GET /orgs/{org}/secret-scanning/alerts
GET /enterprises/{enterprise}/secret-scanning/alerts
Pass is_bypassed=true to return only alerts where push protection was bypassed, or is_bypassed=false to exclude them.
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 Filter secret scanning approval requests by sort order and bypass status appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み