漏れたAPIキー140万件の失効計画 止まる前に連絡先と持ち主を決める

ある朝、SMSの送信やメール配信のAPIが認証エラーを返し始める。調べると、数年前に公開の場へ置き忘れたキーが発行元に失効されていた。そんな障害が、これから増えるかもしれません。

米Truffle Securityは11月4日、Secrets Revocation Programを発表しました。公開の場に漏れたAPIキーなどを、発行元に止めてもらう取り組みです。同社が有効と確認した140万件を出発点に、Hugging FaceやNotion、Vercel、Resend、RubyGems、Twilioなど16の発行元が参加しています。

情シスが備えるのは失効そのものではありません。連絡がだれに届くか、キーの持ち主はだれか、止まると何の業務が止まるか。この3つです。

140万件は、一斉に止まる数ではない

数えたのはTruffle自身です。同社のTruffleHogは見つけたキーを発行元のAPIに送り、認証が通ったものを有効と数えます。発表の書き方は「1.4 million since 2022」で、2022年以降にテストを通ったキーの累計と読めます。

第三者が数え直したという記述はなく、発行元ごとの内訳も出ていません。プレスリリースには「verified, live」ともありますが、140万件すべてを発表の直前にテストし直したのかは読み取れません。

しかも、発行元が止められるのは自社のキーだけ。参加16のうち名前が出ているのは6つです。Truffleは未参加の発行元の分として43,699件を保留していると書く一方、これまでに何件失効したかは示していません。

自社で立てたデータベースは、さらに事情が違います。同社が9月に公表した公開GitHubの調査では、2026年7月のテストでPostgresの接続文字列11,465件とMySQLの1,806件が有効でした。止めてくれる発行元がいない接続先は、自社で替えるしかありません。

編集部は、この発表を「ある日140万件が止まる話」とは読んでいません。参加した発行元のキーから順に、利用者の準備と関係なく止まっていく話でしょう。同社は秘密情報の検出製品を売る会社でもあるので、数字は自社調査として受け取ります。

通知だけでは、8割のキーが残った

Truffleが失効にこだわる根拠は、自社で集計した2つの数字です。2025年の調査では、GitLabとBitbucketで見つけた有効なキー21,981件を持ち主と発行元に知らせても、6か月後に81%が有効でした。

もう1つはGoogle Cloudの例です。Googleは2024年6月16日から、漏れたサービスアカウントキーを通知するだけでなく既定で無効化するようになりました。Truffleが2026年7月に調べると、切り替え前の1年に置かれたキーは72%が有効で、切り替え後の1年は11%です。

もっとも、通知が読まれなかったとは言い切れません。Truffleは11月3日の記事で、警告を受けるチームとシステムを動かすチームは別のことが多く、何が止まるか分からないまま放置されると説明しました。キーの持ち主が分からない会社には、思い当たる話でしょう。

14日は、利用者の猶予ではない

参加の形は2つあります。発行元がWebhookでキーを受け取って自分で止めるか、失効用のエンドポイントをTruffleに渡して自動で止めてもらうかです。後者についてTruffleは「Keys die as soon as we verify them」と書いており、有効と分かればその場で止まります。

前者の期限が14日で、公開されている参加契約に次の文があります。

Within fourteen (14) days of delivery, Partner will either revoke the Found Secret or advise Truffle in writing that revocation of that credential is not technically possible. Partner is responsible for notifying its own affected customers.

発行元は受け取ってから14日以内に失効するか、技術的にできないと書面で伝える。利用者への連絡は発行元の責任。読み違えやすいのは前半でしょう。14日は発行元とTruffleの間の期限で、利用者がキーを替えるための猶予ではありません。

利用者への予告や猶予を定めた文は、2ページの契約にも導入の手引きにもありません。いつ何を知らせるかは発行元しだいなので、止まったあとに連絡が届くこともあると考えておくほうが安全です。

手引きには、頼まれれば過去に見つけた分を全部渡すともあります。発行元が参加した直後に、古いキーがまとめて止まる場面もありそうです。

連絡が届く先は、発行元ごとに違う

では、連絡はどこに届くのでしょうか。各社の公式の案内で比べると、次のようになります。

上の2つは計画への参加が公表された発行元、下の2つは参加の公表がない発行元です。どれも各社の一般の案内で、計画を経由した失効でも同じ通知になるとまでは書かれていません。

気がかりなのは、届く先が人に結びついていることです。Hugging Faceなら、トークンの持ち主のメールに届きます。開発者が個人のアカウントで作ったトークンを業務に使っていれば、情シスには届かないでしょう。退職していたら、だれも読まないかもしれません。GoogleもEssential Contactsの説明で、人の異動があると既定の担当者だけでは通知を見落とすおそれがあるとし、個人でなくグループのアドレスを勧めました。

AWSは症状も違うかもしれません。Truffleの調査によると、隔離ポリシーはキーを止めず、一部の操作を拒否するだけです。特定のAPIだけ急に失敗する形になるのでしょう。AWSの説明は、このポリシーを外さず、サポートケースの案内に従うよう求めています。

キーが突然止まった日の手順

1. メールのリンクを開かず、いつもの入口から発行元の管理画面に入り、キーの状態を確認します。
2. どの処理がそのキーを使っていたかを調べます。発行元の利用ログに残る送信元と呼び出し先、シークレットマネージャー、CIの変数、デプロイの定義が手がかりです。月に1回だけ動くジョブも忘れずに探します。
3. 新しいキーを必要な権限だけで発行し、処理を切り替えます。急場しのぎに古いキーを有効に戻すのは避けます。公開の場にあったキーは、戻した瞬間にまた使える状態になるからです。
4. 止まる前の利用ログを読みます。Truffleは確認のためにキーを発行元のAPIへ送るので、見慣れないアクセスが1件あるだけでは攻撃と決められません。一方で、契約上のTruffleの確認は有効かどうかとアカウントの特定までなので、データの取得や設定の変更が残っていれば侵害として調べます。
5. キーが置かれていた場所を特定し、公開された原因を直します。同じ手順のままなら、新しいキーも同じ場所に出ます。

失効の連絡を装うメールに備える

偽の失効連絡が出たという話は、発表にも各社の案内にもありません。ただ、失効の知らせは「すぐログインして」「新しいキーを発行して」と誘いやすい文面です。話題になればまねる者が出てもおかしくないと編集部はみています。セキュリティを名目にキーを抜く手口には、偽の監査ワークフローの例もありました。

差出人の名前では見分けにくいでしょう。契約上、利用者に知らせるのは発行元ですが、Truffleも2025年の調査では持ち主に知らせていました。

社内の決まりは3つで足ります。連絡を受けた人はリンクを開かず情シスへ転送する。確認は管理画面の状態で行う。キーの値をメールやフォームに書かない。

うちの会社のキーは止まるのか

• 影響する: 公開の場にキーが残っている会社です。GitHubの公開リポジトリのほか、GitLab、Dockerイメージ、npm、PyPI、Hugging Face、Androidアプリ、Firefoxのアドオンも探す範囲に入ります。
• 影響する: 開発者の公開された個人リポジトリや、委託先が作った配布物に会社のキーが入っている会社です。
• 影響する: Twilio、Vercel、Notion、Resend、Hugging Face、RubyGemsを業務で使う会社です。キーが漏れていれば、止まる側に入るでしょう。
• 影響しない: 公開の場に出ていないキーは対象外です。Truffleが調べるのは公開の場だけだからです。非公開リポジトリに別の危険があることは、Gheistの記事のとおりです。
• 影響しない: 参加が公表された6つ以外のサービスのキーは、今すぐ止まるとは言えません。ただ、残りの10の名前は分からず、Google Cloudのように発行元自身の仕組みで止まる例もあります。

止まる日を自分で選ぶための段取り

1. キーの台帳を作ります。サービス名、キーの名前、作った人、使っている処理、止まると困る業務、連絡先の6列です。値は書きません。
2. 発行元からの通知先を、個人のアドレスから共有のアドレスに替えます。Google Cloudなら組織のEssential ContactsのSecurityです。
3. 公開の場を洗い出します。GitHubだけでは足りず、Dockerイメージや配布物、Hugging Faceも見ます。
4. 見つかった有効なキーは、止められる前に替えます。順番は、新しいキーの発行、処理の切り替え、古いキーの無効化、様子見、削除、古いキーが拒否されることの確認です。
5. 委託先に、納品物や公開物にキーが入っていないかを聞きます。国家サイバー統括室の注意喚起の点検表の質問2が使えます。

いちばん見落としやすいのは3の範囲でしょう。GitHubの提携の仕組みが見るのは、公開リポジトリとnpmです。Truffleによると、同社が届けたResendのキーは4分の3がDockerイメージから見つかり、同社が分析したVercelのキーは半分超がHugging Faceのデータセットからでした。2025年1月以降はAIコーディングツールの設定ファイルからも有効なキーが2,655件見つかったといい、公開のDockerイメージの中の.claude/settings.local.jsonにGitLabのトークンがあった例も挙がっています。

GitHubの中は、TeamかEnterpriseの組織なら、オーナーかセキュリティ管理者がシークレットリスク評価を無料で実行できます。組織のSecurity and qualityタブのAssessmentsから始め、実行は90日に1回までです。

DockerイメージやHugging Faceは、OSSのTruffleHogでも探せます。書式はREADMEの例によるもので、動作は未確認です。

trufflehog github --org=<自社の組織名> --results=verified,unknown
trufflehog docker --image <自社のイメージ名> --results=verified,unknown
trufflehog huggingface --org <自社の組織名> --results=verified,unknown

verifiedは有効と確認できたもの、unknownは通信の失敗などで確認できなかったものです。結果にはキーの値がそのまま出るので、チケットやチャットに貼らないでください。

確認の動作は、見つけた文字列を発行元のAPIに送って認証を試すことです。他人のキーを試すことになるので、委託先や他社の組織名、イメージ名は指定しません。確認の通信を避けたいときは--resultsの指定を外して--no-verificationを付け、候補だけを一覧にします。

自社のキーが140万件に入っているか、利用者が引ける窓口は計画の案内にありません。同社の別製品Foragerには、GitHubとnpmの公開分を会社のドメインに限って調べる無料版の案内があります。

失効は、放置されたキーを片づけてくれる動きです。ただ、止まる日を選べるのは、先に見つけた会社だけです。