先に結論
今回の更新は地味ですが、secret scanning を本気で回しているチームには効きます。
GitHub は 2026-05-26 に delegated workflow を改善し、approval request の一覧を並び替えられるようにしました。さらに secret scanning alerts API に is_bypassed が加わり、push protection bypass 済み alert を直接絞り込めるようになりました。
要するに、UI では捌く順番を決めやすくなり、API では監査用の後処理が減ります。比較を増やすより、まずこの運用差分を押さえるほうが実務向きです。
何が変わったか
変化は 2 つだけです。
1 つ目は approval request の並び替えです。push protection bypass request と alert dismissal request を、Newest、Oldest、Recently updated、Least recently updated で切り替えられるようになりました。
2 つ目は is_bypassed の追加です。secret scanning alerts API で、push protection を bypass して作られた alert だけを抽出できます。
この 2 つは別々に見えて、実際は同じ方向を向いています。大量の request と alert を抱える組織で、優先順位付けと監査を少しでも機械化しやすくする更新です。
まず効くのは UI 側の triage
approval request の並び替えは、repo、organization、enterprise の 3 レベルで使えます。
今までは fixed order だったので、件数が増えると「どれから見るべきか」が人頼みになりやすい状態でした。今回の変更で、期限が近い request や最近動いた request を先に追いやすくなります。
特に効くのは、security analyst が朝に一気に捌く運用や、platform team が複数 repo をまとめて見ている運用です。Newest 固定より、Recently updated や Least recently updated を使い分けたほうが、滞留を見つけやすくなります。
API 連携では is_bypassed が本命
is_bypassed は次の 3 endpoint で使えます。
GET /repos/{owner}/{repo}/secret-scanning/alertsGET /orgs/{org}/secret-scanning/alertsGET /enterprises/{enterprise}/secret-scanning/alerts
is_bypassed=true を付けると、push protection を bypass して作られた alert だけを返します。false を付けると、その alert を除外できます。
今までも UI では bypassed qualifier がありましたが、REST API 側では同じ絞り込みをそのまま使えませんでした。そのため、一覧を取ってから別の条件でふるい直す実装が残りがちでした。
今回の変更で、その後処理をかなり減らせます。SIEM 連携、週次レポート、Slack 通知、監査ダッシュボードのどれでも効く改善です。
どのチームが見直すべきか
まず見直したいのは、delegated workflow を repo 単位ではなく org や enterprise 単位で回しているチームです。件数が増えるほど、並び替えの差がそのまま運用負荷の差になります。
次に、secret scanning alerts API を既に使っているチームです。bypass 済み alert を別集計しているなら、クエリに is_bypassed を足すだけでスクリプトが少し短くなります。
逆に、secret scanning をまだ有効化していないチームなら、今回の更新だけ先に追っても優先度は高くありません。その場合は、まず GitHub Advanced Security や push protection をどこまで有効化するかを先に決めるほうが先です。全体像から見たいなら GitHub Actions security roadmap 2026 で何が変わるか や Codex Security vs Snyk vs Semgrep vs GitHub Advanced Security【2026年版】 もつながります。
今すぐ確認したい 3 点
1. approval queue を何順で捌くか
Newest 固定のまま運用しているなら、Least recently updated や Recently updated を試す価値があります。滞留を拾う運用なら、古い request を意図的に浮かせるほうが合います。
2. bypass 監査を後処理でやっていないか
API レスポンスを取ってから push_protection_bypassed を別に見ているなら、is_bypassed を使う形へ寄せたほうが早いです。クエリ側で絞るほうが dashboard と通知の条件も読みやすくなります。
3. repo、org、enterprise のどこで delegated workflow を見ているか
今回の改善は 3 レベルで効きます。現場の repo triage だけでなく、central security team が org や enterprise でまとめて見ているなら、効果はそちらのほうが大きいはずです。
小さい変更でも、運用差ははっきり出る
この更新だけで secret scanning の制度が別物になるわけではありません。検出精度が上がる話でも、GHAS の価格が変わる話でもありません。
ただ、日々の approval queue と bypass 監査は地味に時間を食います。今回の改善は、その手作業を少し削る更新です。GitHub ネイティブで security workflow を回したい組織なら、見逃さないほうがいい変更でした。
より広い運用設計まで見たいなら、GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も合わせて読むと、GitHub 上で security と automation をどう寄せるかを整理しやすくなります。