GitHub CopilotやCursorで書いたコードを、公開リポジトリやデータセットに置いたことがあるなら、他人事ではない話だ。セキュリティ企業Truffle Securityが公表した調査によると、公開状態で見つかったAWSアクセスキー6万4,024件のうち1万616件を再検証したところ、88%にあたる9,342件がいまも認証に使える状態だった。
単一の流出元として最も多かったのがHugging Face上の公開データセットで、そこだけで8,482件のライブキーが見つかっている。768件は企業のAWSアカウントに対する管理者権限を持つ鍵だった。
何が判明したのか──6万件超のうち9,342件が今も有効
Truffle Securityは、Git履歴やHugging Faceのデータセット、Dockerイメージ、パッケージレジストリ、CIログといった公開ソースを横断的にスキャンし、2022年8月から2026年8月にかけて公開された6万4,024件のユニークなAWSアクセスキーペアを検出した。スキャンで引っかかった公開箇所そのものは43万1,875件にのぼり、そこから重複を除いた数がこの6万4,024件である。このうち完全な資格情報がそろっていた1万616件について実際にAWSへ認証を試み、88%が今も生きていることを確認したという。
生きていた鍵のうち768件は企業のAWSアカウントに対する管理者権限を持っていた。内訳はアカウント全体を掌握できる「rootキー」が526件、管理者権限(AdministratorAccess)を持つIAMユーザーの鍵が242件で、この2つは重複していない。攻撃者の手に渡れば、該当企業のAWS環境をまるごと乗っ取れる状態だったことになる。
もう一段踏み込んだ数字もある。生きていたrootキーのうち130件は、組織の「管理アカウント」のものだった。AWSでは複数のアカウントを組織としてまとめられ、その頂点に立つのが管理アカウントである。ここの鍵が渡るというのは、1つのAWS環境が覗かれるという以上に、その企業がどんなアカウント構成でクラウドを使っているかまで見えるということだ。
最大の流出源がHugging Faceになった理由
流出元の内訳で際立っていたのがHugging Face上の公開データセットだ。3,394件の公開データセットにわたって8,482件のライブキーが見つかっており、単一の流出源としては最大となっている。GitHub上のGit履歴やDockerイメージ、パッケージレジストリ、CIログといった他の経路を抑え、AI関連のプラットフォームが突出する結果になった。
Hugging Faceは、AIモデルや学習用データセットを誰でも公開・共有できる場として広く使われている。データセットを作る過程で使ったノートブックやスクリプトがそのまま同梱され、開発中に一時的に使っていたAWSの認証情報を消し忘れたまま公開される──というのが典型的な経路とみられる。Truffle Securityの分析では、Hugging Face発の鍵は17.9%がrootキーで、他の流出元より権限の重い鍵が混ざりやすい傾向も確認されている。
鍵が漏れたまま放置される理由
今回の調査でもうひとつ目を引くのが、見つかった鍵の「年季」だ。作成日が分かった鍵の年齢は中央値で1,831日、およそ5年。もっとも古いものは17.4年前に作られていた。逆に、直近30日以内に作られた鍵はわずか25件(0.9%)しかない。つまりこれは今週どこかで起きた事故ではなく、5年分の積み残しが一度に見えただけである。
しかも、これらの鍵の86%は一度もローテーション(交代)された形跡がない。新しい鍵が併存していたのは、確認できた2,903件のうち398件(13.7%)だけだった。作られてから一度も更新されず、そのままの姿で公開状態に置かれ続けている。さらに、不審な使われ方に気づくための予算アラートを設定していたのは9.5%にとどまる。仮に誰かが今日から使い始めても、請求が跳ねるまで誰も気づかない構えになっている。
認証情報の漏洩は、誰かが偶然見つけて指摘するか、スキャンツールが検出するまで表に出ない。指摘されなければ、何年でもそのまま残る。
検証用や個人用のスクリプトに認証情報を直接書き込むのは、開発を速く進めるための近道になりやすい。公開する段になって消し忘れるケースが積み重なっている。
Hugging Faceのようにファイルを公開・共有すること自体が目的の場では、埋め込まれた認証情報も一緒に世界中へコピーされていく。
Cursor・Copilotでコードを書く人が確認すべきこと
ここまでの数字は企業のAWSアカウントが中心だが、無関係な話ではない。GitHub CopilotやCursorのようなAIコーディングツールは、書きかけのコードやサンプルをその場で素早く動かすことに向いている。その速さと引き換えに、認証情報を直接コードへ書き込んで、消し忘れたまま公開リポジトリへ上げてしまう経路が生まれやすい。Hugging Faceに限らず、GitHubの公開リポジトリも今回の調査対象に含まれている。
AIコーディングツールが備えるセキュリティ機能そのものにも差がある。Claude Codeが無料の脆弱性スキャナーを備える一方、GitHub Copilotは従量課金、Cursorは対象外という違いは以前の記事で伝えた通りだ。ツール任せにできる範囲と、自分で確認するしかない範囲を分けて考える必要がある。
GitHub Copilot自体も、認証情報の話とは別に単体の脆弱性を繰り返し指摘されてきた。直近ではMicrosoft Copilotの「CoSnitch」のように、ツール側の不具合が原因のケースもある。今回の調査が示しているのはそれとは別の問題で、ツールの欠陥ではなく、使う側が認証情報を書き込んで公開してしまう運用のミスが主因である点には注意したい。
編集部の見立て
この調査でもっとも引っかかるのは、9,342件という数そのものより、その多くが5年以上前に作られたまま放置されているという事実です。AI開発の現場は「まず動かしてみる」ことに価値を置きがちで、検証用のスクリプトに認証情報を直書きする判断は、誰しも一度はしたことがあるはずです。問題は、その一時しのぎが片づけられないまま、Hugging Faceのような公開・共有前提の場に乗って世界中へ広がってしまう構造にあります。
AIツールを選ぶ・使う立場の人にとっての要点は一つです。自分が公開しているリポジトリやデータセットに、認証情報が紛れていないかを一度確認すること。GitHub CopilotやCursorで書いたコードも例外ではありません。便利さの代償を払うのは、ツールを作った会社ではなく、鍵を書き込んだまま公開した本人です。
もう一点、Hugging Face発の鍵ほどroot権限の比率が高かったという事実は見過ごせません。データセットを公開する人ほど、検証環境でも本番と同じ強い権限の鍵を使い回している可能性を示しています。次にノートブックやスクリプトを公開する前に、そこで使っている鍵が本当にrootかどうかを確かめる。今回の数字が示す、もっとも具体的な行動はそれです。
まとめ
Truffle Securityの調査で、公開状態にあったAWSアクセスキー6万4,024件のうち、再検証した1万616件の88%にあたる9,342件が今も有効と判明しました。単一の流出源として最大だったのはHugging Face上の公開データセットで、8,482件のライブキーが見つかっています。
768件は企業のAWSアカウントを丸ごと操作できる管理者権限つきの鍵で、内訳はrootキー526件、AdministratorAccess権限のIAMユーザー242件でした。生きていた鍵の年齢は中央値で1,831日(約5年)、86%は一度もローテーションされていません。
GitHub CopilotやCursorで書いたコードも、公開リポジトリやデータセットに認証情報を書き込んだまま置けば同じ経路をたどります。心当たりのあるリポジトリやデータセットは、確認することから始められます。