GitHub シークレット スキャンの今回のアップデートは、見た目以上に運用へ効く変更です。2026年4月8日に GitHub が公開した改善で、アラート一覧の絞り込み、検出箇所への直接リンク、委任ワークフローのコメント情報が REST API と Webhook に入り、通知・起票・承認追跡を一気通貫で自動化しやすくなりました。(The GitHub Blog)
ただし、GitHub が漏えいした資格情報を自動でローテーションしてくれるようになったわけではありません。強くなったのは「検知後に必要な文脈を API と Webhook で取り出す部分」で、実際の失効や更新は外部サービスや社内 Runbook とつないで行う設計が前提です。GitHub も、アラートを受けたらまず影響を受けた資格情報をローテーションするよう案内しています。(The GitHub Blog)
シークレット スキャン自体は public repository では無料で自動実行され、Organization 所有の private/internal repository では GitHub Secret Protection を有効にした GitHub Team または GitHub Enterprise Cloud で利用できます。今回の closure_request_* 系の改善が特に効くのは、delegated alert dismissal を使っている組織で、この仕組みは GitHub.com と GitHub Enterprise Server 3.17 以降で利用できます。(GitHub Docs)
GitHub シークレット スキャンの今回の改善で変わること
exclude_secret_types が入り、一覧 API の運用がかなりラクになった
今回いちばん実務で効くのは、一覧 API に exclude_secret_types が加わったことです。GitHub は新しい secret type を継続的に追加しており、従来の「拾いたい種類を列挙する」運用だと、集計スクリプトや修復バッチのメンテナンス負荷が高くなりがちでした。これからは組織・リポジトリ・Enterprise の一覧取得 API で「除外したい種類だけ」を指定でき、secret_type と同時指定すると 422 になる点も明示されています。(The GitHub Blog)
「基本は全部拾いたいが、一部のノイズだけ外したい」運用なら exclude_secret_types が向いています。逆に、社内で Runbook が整っている数種類だけを厳密に自動処理したいなら、従来どおり secret_type の明示指定のほうが安全です。前者は監視の取りこぼしを減らしやすく、後者は誤自動化を防ぎやすい、という違いがあります。(The GitHub Blog)
alert location の html_url で通知と起票が一段ラクになった
アラート location の details オブジェクトに html_url が追加されたのも大きな改善です。以前は API URL しか返らず、Slack や Jira に人がクリックできるリンクを載せるには追加 API 呼び出しが必要でした。今後は GET /repos/{owner}/{repo}/secret-scanning/alerts/{number}/locations と Webhook の両方で、コミット、Issue、Pull Request、レビュー系の場所に直接飛べる URL をそのまま扱えます。しかも既存の URL フィールドは残り、html_url は加算的な追加です。(The GitHub Blog)
この差は小さく見えて、通知実装ではかなり効きます。たとえば、これまでは「Webhook受信 → API URL を人向け URL に変換 → 通知送信」という一手間が必要でした。これからは html_url をそのまま本文に埋め込めるので、Slack、Teams、ServiceNow、Jira のどれに流す場合でも実装が素直になります。
委任ワークフローのコメントとメール通知が強化された
委任ワークフロー周りでは、通知と監査証跡の両方が強化されました。バイパスや却下依頼のメールには期限が表示されるようになり、アラート却下依頼を出した開発者にも確認メールが届きます。さらに、委任された却下では closure_request_comment、closure_request_reviewer_comment、closure_request_reviewer がアラート payload に含まれ、承認経由で閉じたアラートでも resolution_comment が null にならないよう修正されました。(The GitHub Blog)
これで「なぜ閉じたのか」「誰がどう判断したのか」を、外部チケットや監査ログへそのまま残しやすくなります。とくにこれまで resolution_comment を証跡の起点にしていた運用では、承認経路だけコメント欠落が混ざる問題を避けやすくなった点が実務上かなり大きいです。
GitHub シークレット スキャンのアラート API 改善が自動修復に効く理由
GitHub の secret scanning は Git 履歴全体に加え、Issue、Pull Request、Discussion、Wiki、secret gist までスキャンし、新しい secret type が追加されると再スキャンも行います。つまり検知対象はもともと広く、運用のボトルネックは「見つけること」よりも「誰に、どの URL と理由を添えて、どう修復させるか」にありました。今回の更新は、まさにそこを薄くしています。(GitHub Docs)
特に、Webhook で新規アラートの作成・解決・再オープンを取り込み、html_url で人が見える場所へ飛ばし、closure 系コメントをチケットへ写す構成はかなり組みやすくなりました。GitHub のドキュメントでも、Webhook を Slack、Teams、Splunk、メールなどに連携し、大規模運用ではこのフォローアップ自体を自動化する方向が案内されています。(GitHub Docs)
GitHub シークレット スキャン Webhook 改善を実装に落とす方法
通知の起点は secret_scanning_alert と secret_scanning_alert_location が基本です。これらを購読する GitHub App には Secret scanning alerts の read 権限が必要です。また、一覧取得 API は fine-grained token で Secret scanning alerts の read、アラート更新 API は write 権限が必要で、更新 API では state の変更だけでなく assignee の付け外しもできます。(GitHub Docs)
実装は、次の流れにすると無理がありません。
- Webhook 受信時に
secret_type、validity、html_url、repo、org を取り出す secret_typeごとの Runbook にひも付けて、失効手順・担当チーム・SLA を決める- Slack、Teams、Jira、ServiceNow には API URL ではなく
html_urlを載せる - 夜間または定期ジョブで list API を再取得し、Webhook 処理漏れを補正する
exclude_secret_types を選ぶべきケース
「基本は全部拾い、ノイズだけ外したい」なら exclude_secret_types が向いています。GitHub 側で secret type が増えても、監視対象へ自動で乗りやすいからです。逆に、社内で失効自動化や担当者振り分けが整っている数種類だけを厳密に扱うなら、secret_type を残したほうが事故を防げます。(The GitHub Blog)
委任却下まで API で回すなら、権限設計も見直す
委任アラート却下のレビュー API を使うなら、delegated alert dismissal を有効にしたうえで、approve または deny とメッセージを送る設計になります。GitHub Docs では、fine-grained token に Secret scanning alerts read だけでなく Contents read と dismissal requests の write 権限が必要です。ここを見落とすと、「アラート一覧は取れるのに却下レビューだけ失敗する」状態になりやすいです。(GitHub Docs)
実装前に決めるべき役割分担
今回の改善で自動化の幅は広がりましたが、全部を自動化すると運用事故になります。目安は次の分け方です。
| 自動化してよい処理 | 人手判断を残す処理 |
|---|---|
| Slack / Teams 通知 | false positive 判定 |
| Jira / ServiceNow 起票 | wont_fix や恒久例外の判断 |
secret_type ごとの Runbook 選択 | 委任却下の最終承認 |
| 期限リマインド | 履歴書き換えの要否判断 |
| 担当者アサイン | 失効済みかどうかの最終確認 |
この切り分けを先に決めておくと、「通知は速いが判断が雑」「自動却下が先に走って証跡が薄い」といった失敗を防ぎやすくなります。
失敗しやすいポイント
secret_typeとexclude_secret_typesは同時指定できません。両方入れると 422 になります。(The GitHub Blog)html_urlは既存の URL を置き換える変更ではありません。既存フィールドは残り、追加で人向けリンクが入る理解が正確です。(The GitHub Blog)resolution_commentを下流の監査やチケット同期で使っているなら、委任却下の承認経路でも値が入る前提にロジックを見直す価値があります。(The GitHub Blog)- 修復は履歴改変から始めるのではなく、まず資格情報のローテーションや失効を優先するのが基本です。(GitHub Docs)
- 今回の改善は「GitHub 単体で自動ローテーションする機能追加」ではありません。外部サービスや社内 Runbook とつないで初めて、自動修復の効果が出ます。(The GitHub Blog)
まずやるべきこと
最初にやるべきことは4つです。今の集計・修復スクリプトで secret_type の allowlist を使っている場所を洗い出すこと、Webhook 消費側で details.html_url と closure 系フィールドを受け取れるようにすること、delegated alert dismissal を使っているなら reviewer comment を外部チケットへ残すこと、そして Webhook だけに頼らず list API の再同期ジョブを足すことです。ここまでやれば、今回の GitHub シークレット スキャン API 改善を単なるニュースで終わらせず、実際の修復自動化へつなげられます。(The GitHub Blog)
コメント