GitHubは10月5日、シークレットスキャン（secret scanning）に新しい種類を5つ加えた。シークレットスキャンは、リポジトリにコミットされたAPIキーなどの資格情報を見つける機能だ。
追加された種類はlovable_api_key、logfire_token、pydantic_ai_gateway_api_key、supabase_oauth_access_token、supabase_scoped_personal_access_tokenだ。
Lovable Labsはシークレットスキャンのパートナープログラムにも参加した。公開リポジトリでlovable_api_keyが見つかると、GitHubがLovableに転送し、資格情報の失効やローテーションができるようにする。
資格情報を識別することと、対応できる相手に知らせることはつながっているが同じ変化ではない。すべてのトークンに同じ保護が適用されるという意味でもない。
リポジトリのアラート、パートナーアラート、パターンごとの機能
GitHubはアラートを二つの経路に分けている。Userの種類は公開・非公開リポジトリで見つかるとリポジトリの利用者向けにアラートを作り、Partnerの種類は公開リポジトリで見つかると発行元に自動で報告される。
ドキュメントによれば、パートナーアラートはプロバイダーに直接送られ、リポジトリのSecurity and qualityタブには報告されない。
対応表はプッシュ保護と有効性チェックをパターンごとに分けて示している。今回の5種はいずれもプッシュ保護も有効性チェックもなしと示されている。
対応表では、logfire_tokenとpydantic_ai_gateway_api_keyは公開リポジトリの項目に表示されず、GitHub Advanced Securityを使う非公開リポジトリの項目にだけ表示される。
パートナーへの転送は発行元に対応の機会を与える経路だ。自動での失効を保証するものではない。
トークンの種類と対応経路の組み合わせ
検出の種類の数では答えられない運用上の問いが残る。誰がインシデントを見て、誰が漏れた資格情報を無効にできるのか。
リポジトリ管理者がコードの整理を担い、サービスアカウントは別のチームが管理していることはよくある。プロバイダーへの通知は役に立つが、組織のインシデント記録の代わりにはならない。
逆に、リポジトリの画面が静かだからといって、プロバイダーに通知が行かなかったとは判断できない。レビューの単位は製品名ではなく、トークンの種類と対応経路の組み合わせだ。
実際に使う資格情報の一覧から始める点検
点検は、アプリケーションが実際に使う資格情報の種類の一覧から始めるのが効率的だ。その識別子を現在の対応表と、リポジトリで有効にした機能に突き合わせる。
アラートの調査、漏れた資格情報の失効やローテーション、依存サービスの更新を担う人やチームを記録しておく。
これは推奨する運用点検であり、顧客アカウントで検証した手順ではない。責任の割り当てを確かめるために本物の資格情報をコミットする理由はない。
許可された範囲での統制された検証
統制された検証が必要なら、プロバイダーが認めたダミーやテスト用の資格情報と、明示的に許可されたテスト用リポジトリだけを使うのが原則だ。
期待する観測を先に決める。ローカルでのブロック、リポジトリのアラート、発行元の対応はそれぞれ別の結果で、一つを証明した試験がほかまで証明するわけではない。
証拠に使えるシークレットを残さない。試験のコミットを消しても、本物の資格情報が公開された事実は取り消せない。
注意点：認識範囲の拡大と検証していない部分
今回のリリースの直接の利点は認識範囲の拡大であり、インシデント対応の手順が完成したという意味ではない。
この記事は発表とドキュメントを確認しただけで、検出、非公開リポジトリでの利用資格、プロバイダーの対応は試していない。5種それぞれの機能も実際に動かして検証していない。
新しい検出の種類が教えてくれるのはシークレットを見つけられるという事実までで、そのアラートを誰が受け取り何をするかは、依然として組織が決めることだ。