GitHubはSecret Scanningとpublic monitoringを同時に拡張した。新しい検出器だけの変更ではない。push時のブロック対象、webhookの分類情報、enterprise向け監視画面まで変わるため、検出後の自動処理と人の対応手順を一緒に更新する必要がある。

何が変わったか

APIclubのapiclub_api_keyとResendのresend_api_keyが検出対象へ追加され、ResendはGitHubのsecret scanning partnerになった。VolcEngine secretsはpush protectionで既定ブロックされる。secret_scanning_alert webhookにはsecret_categoryが入り、specificな既定パターンとgeneric secretを区別できる。public monitoringでは、漏えいのattribution、enterprise member数、verified domainなどのinsight cardが表示される。

変更前後の差

従来、受信側がsecret type名だけから分類を推測していた場合、generic detectorとprovider固有detectorを安定して区別しにくかった。新しいsecret_categoryにより、通知優先度や自動割当をpayloadから判断できる。ただし、新フィールドを必須とみなす実装は旧イベントや再送イベントで壊れる可能性がある。

誰に影響するか

GitHub Secret ProtectionやGitHub Code Securityを使う組織、secret scanning webhookをSIEM・SOAR・ticket systemへ送る組織、public repositoryの漏えいをenterprise単位で監視する組織が対象である。ResendやVolcEngineを利用する開発チームは、これまで見逃していたtokenがalertまたはpush blockになる可能性がある。

期限

強制移行期限はない。変更は順次提供されるため、webhook consumerとrunbookは早めに前方互換へする。新しいalertが発生してから分類漏れに気付く運用は避ける。

必要な対応

webhook受信schemaで未知フィールドを許容し、secret_categoryがないイベントにも既定値を持たせる。新しいprovider secretを資産台帳とcredential ownerへ紐付ける。push protection bypassを許す場合は理由、承認者、有効期限を記録する。public monitoringの集計値は、単純なalert件数ではなく、組織外repository・verified domain・attribution別に確認する。

実装・移行手順

  1. webhookのfixtureへsecret_categoryあり・なしを追加する
  2. defaultとgenericのrouting ruleを定義する
  3. APIclub、Resend、VolcEngineのcredential ownerを登録する
  4. test repositoryで検出・通知・ticket作成を確認する
  5. revocation、rotation、再発行、deployまでのrunbookを更新する
  6. public monitoringのinsight cardと既存SIEM集計を照合する
  7. false positiveとbypassの週次レビューを設定する

失敗しやすい点

新しいフィールドを必須にして過去イベントの再処理を失敗させる、generic secretを低優先度へ一律分類する、alert closeをcredential失効と同一視する、push protectionでブロックされたため漏えいが存在しないと判断する、といった誤りが起きやすい。credentialはcommit前に別経路へコピーされている可能性もある。

リスク

通知量の増加によるalert fatigue、誤分類による初動遅延、webhook parserのschema不整合、public monitoringの集計と社内資産台帳の差異が主なリスクである。secret type追加時にownerが不明だと、失効判断が遅れる。

評価方法

  • provider別の検出件数と有効secret率
  • alert受信からowner特定までの時間
  • 失効・rotation完了までの時間
  • webhook処理失敗率
  • generic secretのfalse positive率
  • push protection bypass件数と再発率
  • public monitoringとSIEMの件数差

ロールバック

webhook連携に問題がある場合は、新フィールドを無視する旧routingへ戻し、raw eventを保存して再処理できるようにする。検出自体を停止するのではなく、自動ticket化だけを段階的に止める。誤ったrouting ruleは設定のrevertで戻し、発生済みalertを再分類する。

編集部分析

今回の重要点は検出器の増加より、secretの性質を機械判定しやすくなったことにある。漏えい対応は検出精度だけで決まらない。owner特定、失効、再発行、deploy、再検査が一つのSLAでつながっているかが実効性を左右する。

実務チェックリスト

  • [ ] webhook consumerが未知フィールドを許容する
  • [ ] secret_categoryなしのイベントも処理できる
  • [ ] 新しいproviderのcredential ownerを登録した
  • [ ] rotationと再deployまでをrunbook化した
  • [ ] bypass理由と承認を記録する
  • [ ] public monitoringとSIEMを照合する
  • [ ] raw eventを再処理できる

一次情報