GitHub secret scanningの検知種類と運用情報が拡張された。webhookにsecret_categoryが加わり、既知provider・custom patternのdefaultと、generic pattern・AI検知のgenericを連携先で区別できる。新detectorやpush protectionの既定も増えたため、fieldを読み捨てるのではなく、alert確度、確認方法、対応時間をcategory・provider別に設計し直す必要がある。
何が変わったか
secret_scanning_alert webhook payloadにsecret_categoryが追加され、値はdefaultまたはgenericとなる。APIclubとResendの認証情報が新たに検知対象となり、Resendはsecret scanning partnerとして公開repositoryで見つかった情報の通知flowに参加する。VolcEngine Ark認証情報はpush protectionの既定対象となった。public monitoring一覧にはattribution、Enterprise member数、verified domainのinsight cardsが追加された。
変更前後の差
従来の連携ではsecret type名を独自mappingし、provider固有検知とgeneric検知を推測する必要があった。新fieldで分類を直接取得できる。一方、genericが低riskという意味ではなく、defaultが必ず有効情報という意味でもない。新detectorと既定blockの追加により、同じpipelineでもalert数やpush rejectionが変わる可能性がある。
誰に影響するか
webhookをSIEM、SOAR、Slack、ticketingへ接続している組織が影響を受ける。public repositoryを監視するEnterprise security teamはinsight cardsを調査の入口にできる。VolcEngine、Resend、APIclubを使う開発者はpush時のblockと公開後の通知を確認する必要がある。
対応期限
強制移行期限はないが、schemaを厳格にvalidateするparserでは未知fieldで失敗する可能性があるため、受信を早期に確認する。新detectorは既にrollout対象で、VolcEngine情報は既定push protection対象である。運用runbookと例外申請を事前に更新する。
必要な対応
webhook sampleを保存し、secret_categoryがない過去payloadと新payloadの両方を処理できるようにする。defaultはprovider確認可否を調べ、genericはcontext、file type、commit historyを加えてtriageする。push protection bypassには理由・承認・期限を要求する。public monitoringのattributionを所有権の断定へ使わない。
実装・移行手順
- 現行webhook schemaとunknown-field挙動を確認する。
- secret_categoryをnullable enumとして保存する。
- provider、secret type、visibility、categoryでrouting ruleを作る。
- 検証用patternでalert・push block・ticketを確認する。
- 外部通知と社内対応の役割を整理する。
- category別のMTTA、確認率、false positiveを集計する。
失敗しやすい点
genericを一律低優先度へ落とすと、AI検知された重要情報を見逃す。defaultを自動処理へ直結すると、検証用情報や更新済み情報で不要な障害を起こす可能性がある。webhook consumerがenumを固定し、新しい値やfield欠落で停止することもある。public monitoringのattributionを法的な所有証明として扱うのも避ける。
リスク
alert数増加によるfatigue、誤った自動対応によるservice outage、bypass常態化が主なriskである。webhook payloadやticketへ検知内容そのものを再保存すると二次漏えいになる。外部通知と社内対応が同時進行し、原因調査が難しくなる場合もある。monitoring dashboardへのaccessを最小化する。
評価方法
新旧parserで同じpayload corpusを再生し、取りこぼし、重複ticket、routing、processing latencyを比較する。category別に確認率、false positive、平均確認時間、対応完了時間、再発を測る。push protectionはblock率だけでなく正当な開発を妨げた件数、bypass理由、教育効果も確認する。
ロールバック
新field利用で連携障害が起きた場合は、secret_categoryがない場合と同じ既存routingへfallbackする。自動対応はfeature flagで止め、人手確認へ戻す。新detector自体を無効化して問題を隠すのではなく、特定typeのautomationだけを停止する。parserとruleをversion管理し、過去payloadを再処理できるようにする。
編集部の見解
secret_categoryは小さなschema追加だが、generic detectionを本番運用へ組み込むための重要な境界になる。分類を優先度の代用品にせず、公開範囲、provider、使用履歴と組み合わせるべきだ。insight cardsも調査範囲を絞る補助情報として使うのが適切である。
実務チェックリスト
- unknown-field耐性を確認した
- secret_categoryをnullableで保存する
- defaultとgenericのrunbookを分けた
- 検知内容をticketへ再保存しない
- push protection bypassを承認制にした
- 外部通知と社内対応を整理した
- public monitoringのaccessを制限した
- category別のMTTAと確認率を測る