GitHubのsecret scanning更新：11月12日の監査ログ変更に備えよう

GitHubの監査ログを、企業の表示名で絞り込んでいないかな？ GitHubは10月20日、secret scanningの更新を発表し、一部の監査ログでbusinessフィールドの値を変更する予定を案内したよ。切り替え日は11月12日とされている。

secret scanningは、リポジトリなどに含まれる秘密情報を検出する機能。監査ログは、その操作やイベントを後から確認するための記録だよ。今回の注意点は、検出するトークンの種類だけでなく、そのログを取り込む連携にもある。

businessは、表示名からslugへ変わる予定

対象は、影響を受けるsecret_scanning_alert.*とsecret_scanning_push_protection.bypassの監査ログイベント。businessの値が、Enterpriseの表示名からslugへ変わると発表されている。

slugは、URLなどでも使われる識別用の名前。人が読む表示名と同じ文字列とは限らない。たとえば、架空の表示名がExample Studio、slugがexample-studioなら、表示名との完全一致で抽出している処理は、切り替え後のログを拾えなくなる可能性があるよ。

この二つの名前は説明用の例で、実際の監査ログではない。手元のEnterpriseで使われている値を確認しよう。

文字列の型チェックだけでは、この違いに気付けない。ログの形式が読めることと、期待する対象を抽出できることを分けて見る必要があるね。

11月12日より前に、取り込み側を確認する

GitHubは、表示名でフィルタリングする連携について、両方の形式を受け入れるか、business_idを使うよう更新することを勧めている。

ここからは編集部の確認順。監査ログを使っていない個人開発者が、急いで設定を変更する必要があるという話ではないよ。

1. ログ収集、アラート、集計、保存後の検索でbusinessを参照している場所を探す。
2. 表示名との完全一致や、表示名を前提にした結合処理がないか調べる。
3. 実データを公開せず、架空の表示名・slug・数値IDを使う小さな入力例で抽出を試す。
4. 移行期間に両方を認識するか、数値IDを照合するかを担当者と決める。
5. 切り替え後も、対象件数の急減や取り込み漏れを確認する。

business_idへ変える場合も、比較する値や型が既存処理と合うか確認しよう。ログを外部へ貼り付けると、組織情報や操作記録まで共有してしまうため、検証用の架空データに置き換えてね。

今回は検出・失効・APIにも改善がある

同じ発表では、次の更新も案内されている。

• カスタムパターンを編集して再走査しても一致する既存アラートは、閉じて再作成するのではなく、開いたまま維持する。
• github.comのsecret scanningを有効にしたprivate・internalリポジトリで、公開プレビュー中の失効操作がBase64形式のGitHubトークンにも対応する。
• 解除申請のWebhookにexemption_request.numberを追加する。連携では、リポジトリと申請番号を組み合わせて対応付ける。
• カスタムパターンAPIで無効な引数が拒否された場合、500ではなく422を返す。

Base64はデータの表し方で、秘密を守る暗号化とは違う。対応する失効操作で自動的にデコードすると説明されているけれど、すべてのトークンが無条件で自動失効するという意味には広げないでね。

依存関係アラートの取得では、Dependabot REST APIの依存バージョン追加も最近の変更。監査ログとアラートAPIを混同せず、それぞれの連携が参照するフィールドを整理しよう。