90日。GitHub Actionsのワークフローのログが、設定を変えなければ残る日数です。その間にログへ出てしまったキーを、これまでGitHubは拾っていませんでした。
GitHubは米国時間の11月9日、シークレットスキャンの対象にActionsのワークフローのログを加えました。これまではコードのほか、Issue、Wiki、Discussions、プルリクエストが対象でした。今回は公開プレビューです。対象はGitHub Enterprise Cloud（GHEC）の企業のうち、GitHub Secret ProtectionかGitHub Advanced Security（GHAS）を使うところです。
ただし、見つけても知らせてはくれません。
Alerts from Actions workflow logs don't generate notifications during the preview, so check your repository's secret scanning alert list directly.
出典: GitHub Changelog「Secret scanning detects secrets in GitHub Actions workflow logs」
プレビューの間、ログで見つかったアラートは通知を出さず、リポジトリのアラートの一覧に並ぶだけです。だれかが一覧を開かない限り、見つかったキーは見つかっていないのと変わりません。
ログは、リポジトリを読める人なら開ける
そもそも、ログに出たキーはなぜ困るのでしょうか。GitHubのドキュメントによると、ワークフローのログは、リポジトリの読み取り権限があれば見ることもダウンロードすることもできます。公開リポジトリなら、GitHubにログインした人はだれでも開けます。
Actionsは登録したシークレットの値をログで伏せます。ただ、伏せきれない場合があるとドキュメントは注意しています。Base64やURLエンコードで形を変えた値、JSONやYAMLにまとめた値、秘密鍵から作ったJWTのような値は、そのままログに出ることがあります。
ログの保存期間は、公開リポジトリなら1日から90日、非公開のリポジトリなら1日から400日の間で変えられます。
つまり、一度ログに出たキーは、長ければ400日、読める人の目にふれ続けるかもしれません。しかもログが消えても、キーそのものは使えるままです。GitHubも、伏せられずに出たシークレットは、ログの削除とシークレットの入れ替えの両方が要るとしています。
コードの検出と比べて見える、3つの穴
では、ログの検出はコードの検出と何が違うのか。同じ項目でそろえると、プレビューの穴が見えてきます。
| 見る所 |
コードとGitの履歴 |
Actionsのログ（プレビュー） |
| 有効にする前の分 |
全ブランチの履歴を調べる |
有効にする前に終わった実行のログは調べない |
| 通知 |
管理者などに設定に応じて届く。新しくコミットした分は本人にも必ず届く（履歴の調べでは届かない） |
出ない |
| 汎用パターン、カスタムパターン、AIによる検出 |
有効にすれば使える |
検出しない |
| まだ使えるキーかの確認 |
対応する種類で使える |
対応する種類で使える |
| 使える契約 |
公開リポジトリは無料、非公開はTeamかGHECでSecret Protection |
GHECでSecret ProtectionかGHAS |
| 既定の状態 |
公開リポジトリは自動、非公開は有効にして使う |
エンタープライズのポリシーで無効 |
出典: GitHub Changelog（2026年11月9日）とGitHubのドキュメント（2026年11月10日に確認）。
まず見たいのは通知の行です。コードなら、新しくコミットしたキーは、本人に必ず知らせが届きます。履歴をさかのぼった調べでは本人に届きませんが、管理者などには設定に応じて届きます。ログでは、キーを出した人も、管理者も、何も受け取りません。
次は、有効にする前に終わった実行のログ。保存期間が既定のままなら、有効にした時点で最大90日分のログが、調べられないまま残ります。保存期間を延ばした非公開のリポジトリなら、もっと長い期間です。
3つ目は汎用パターンでした。ドキュメントでは、秘密鍵や接続文字列、特定のサービスに結びつかないAPIキーが汎用パターンの例で、パスワードはAIによる検出の対象です。ログの検出はどれも拾いません。社内のデータベースのパスワードのように、特定のサービスの形を持たない値は、ログに出てもアラートにならないわけです。
3つを合わせると、今回の機能は、伏せ損ねたクラウドやSaaSのキーを、有効にした日から拾う網と言えそうです。Actionsが伏せた値を拾わないのは、もともとログに値が残らないからでしょう。
地味ですが、ログを消してもアラートは残る点は助かります。キーを替えたらすぐにログを消しても、何が出ていたかの記録は一覧に残るからです。
GitHubのチェンジログ。プレビュー中は通知が出ないと書いている出典: 出典: GitHub Changelog（2026年11月9日）(引用)
対象になる会社と、待つことになる会社
- GHECでSecret ProtectionかGHASを契約している企業は、エンタープライズのオーナーがポリシーで有効にできます。効くのは、シークレットスキャンを有効にしたリポジトリだけです。
- GHE.comでデータの保存先を選んだ企業も対象です。GitHubのドキュメントでは、保存先の地域に日本も入っています。
- GitHub TeamでSecret Protectionを使う組織、エンタープライズに入っていない組織、GitHub Enterprise Serverは、今は使えないと読めます。チェンジログが提供先を「GHECのエンタープライズ」とし、エンタープライズのポリシーの説明でも、有効にできるのはエンタープライズのオーナーだけだからです。
正式提供の時期と、ログ由来のアラートが監査ログやWebhookに流れるかどうかは、発表に書かれていません。シークレットスキャンの監査ログを外へ送っている会社は、監査ログの企業を表す欄（business）の形式が11月12日に変わる件と合わせて、受け側で確かめておくとよいでしょう。
有効にする前の段取り
- エンタープライズのオーナーが、Secret ProtectionかGHASの契約と、シークレットスキャンを有効にしたリポジトリの範囲を確認します。設定はエンタープライズの「Policies」の「Advanced Security」にあり、既定では無効です。
- アラートの一覧を見る人と、見る間隔を決めます。通知が来ない間は、たとえば週に1度、デプロイ用のワークフローがあるリポジトリから順に見ると、漏れが減るでしょう。
- 見つかったときの順番を決めます。まずキーを無効にして作り直し、次にその実行のログを消し、最後にアラートを閉じます。キーを先に止めるのは、GitHubがアラートを受けたら認証情報をすぐ替えるよう求めていて、ログを消してもアラートは残るからです。ログを消すには、リポジトリの書き込み権限が要ります。
- 有効にする前のログをどうするかを決めます。クラウドの認証情報を扱うワークフローだけでも、残っているログを見るか消すかを選びます。保存期間を短くしても、すでにあるログには効きません。
- 伏せ損ねを減らす設定も見直します。形を変えた値は
::add-mask::で伏せる対象に加え、JSONにまとめたシークレットは1つずつに分けます。クラウドに入るためだけのキーなら、OIDCに替えて長く使うキーを持たない手もあります。
3の順番で手間取るのは、キーを止めたときに何が止まるかが分からない場面です。だれが作り、どの処理で使うキーか。漏れたAPIキー140万件の失効計画の記事にあるキーの台帳があれば、通知の来ないアラートにも、その日のうちに手を打てるはずです。
