徳丸浩氏が読み解く、CAMPFIREのGitHub漏洩調査報告 今後は生成AI活用で漏洩リスク増加も

公表した調査結果は「お手本」にできるもの

CAMPFIREが6月2日に公表した調査結果について、所感を伺えますか。

まず、事後にこれだけ詳細を公表している点は評価できます。項目についても不足はなく、一般的なお手本にできる内容といえるでしょう。

一方で、従業員個人の開発環境で、企業用の認証情報をなぜ使用していたかという動機や、また企業としてそれらをどう管理していたかまではわかりません。

認証情報が漏洩した要因は「ありがちなミス」

本事案自体について、GitHubでの流出という点についても聞かせてください。

今回のように、トークンなどの認証情報をソースコードに書き込んだままGitHubに公開することは、ありがちな悪い例といえます。昔から常態化しており、実際にヒヤリハットを経験した、インシデントに発展した企業もあるでしょう。

ただし、最近は開発環境での生成AIの活用が増えつつあります。生成AIを使うとなると、ローカルSLMのような例外を除けば一般的に「Claude Code」などのオープンなネットワーク環境となります。その場合、ソースコード管理もオープン環境のGitHubやGitLabを活用しようとなる可能性が高い。従来はGitHubを使っていなかった開発環境で、生成AIの活用を契機にGitHubを使い始める開発環境が増えるかもしれません。

GitHubに限らず、工程に自動化を導入するCI/CD（Continuous Integration and Continuous Delivery/Deployment）環境での開発、いわゆるモダンな開発が一般化すると、その過程で生成AIが勝手に認証情報などをソースコードに入れてしまうことがあります。本来はそれらの情報が入った部分だけ切り離せばいいのですが、従来はそうした事態を経験していなかった組織が一挙に課題に直面するため、書き込んだまま気づかずに公開してしまうかもしれない。特に何か統計などがあるわけではないですが、生成AIをトリガーにそうなる可能性が高いと感じます。類似事例が増えてくるかもしれません。

GitHub流出対策として進む「短期トークン化」

CAMPFIREが対策として提示している内容はいかがでしょうか。

GitHubや本番サーバーのクラウドにつなぐためのトークン・キーの扱いは、数年前から問題視されています。トークン・キーは数〜数十バイト列の短いデータですが、これが漏れると比較的長いあいだ悪用されてしまいます。典型的には3か月間ぐらい、場合によっては無期限に悪用されてしまい、大変危険です。

従来はこうした情報が漏れないようにしていたわけですが、本件リリースの「2. 漏えいのおそれのある情報について」にもあるように、最近のサプライチェーンへの攻撃を考えると、防ぎきることが難しくなりつつあります。

こういった状況を受けて、認可トークン（アクセストークン）の権限寿命を短くさせることが一般的になりつつあります。GitHubとAWSをOpenID Connect（OIDC）で連携させたアクセストークンなどがその一例です。本件リリースの「7. セキュリティ管理のさらなる高度化」のうち「1. 秘密情報の管理強化」にある「長期トークンから短期トークンへの置き換え」は、具体的な内容は不明ながら、同様の趣旨なのかもしれません。

開発環境のクラウド移行で従来型防御は機能せず

開発環境のセキュリティという観点では、ほかに着目した点はありますか。

開発環境を守りましょうという話も、昔からよくあります。たとえば、SIや受託開発の金融系案件において、GitHubなどは使わない非常にクローズドな環境で、閉じたネットワークにあるファイルサーバーかリポジトリのサーバーにだけつなぐ、場合によってはインターネット接続すら許さないような、いわゆるガチガチといえる強固な環境で開発するケースなどが典型です。

一方、前述の通り生成AIの登場で、オープンなネットワーク環境へと急に環境が切り替わるかもしれない。その場合、従来のいわゆる境界型の防御は通用しません。オープンな開発環境をどう安全に運用するかの知見はまだ十分普及しておらず、現在進行形で新たな脅威も生まれています。

開発環境に広がる生成AI活用、守るべきはソースコードより認証情報

開発環境を守るためにはこれから何を、どう対策すべきでしょうか。

生成AIにより、バイブコーディング、いわゆる非エンジニアの開発機会が増えています。ただし、生成AIはコードを壊してしまうこともある。担当者個人のPCでバージョン管理もせずに開発するよりも、バージョン管理をはじめとする履歴を管理でき、無料で使え、情報も豊富なGitHubを活用するということは、非常に自然な流れです。

その際に、GitHubなどを使うこと自体はよいのですが、認証情報などが絶対に漏れないよう切り分けることを、強く推奨します。たとえば、ソースコードは漏れたとしても——ソースコードが漏れることもあまり喜べませんが——その漏洩は致命的ではありません。現在のセキュリティの世界では、ソースコードの漏洩までであれば最悪いたしかたないというのが、防御時のラインになりつつあると思います。

本当に致命的なことは、認証情報の漏洩です。漏洩した場合に重大な事態になりうるような情報は、着実に分別して管理すべきです。

適切な就業環境の徹底を

そのほか、本件で注目した点があれば教えてください。

冒頭で、なぜ従業員個人の開発環境を利用していたかの動機が確認できない点もあげました。個人の開発環境についての言及が少ない印象で、どういう状況だったかわかりませんが、会社の環境でのみ管理すべきものは徹底すべきです。熱心な従業員の場合、もう少し自宅でも業務をしたいという方が出てくることは理解できます。その動機は非常に素晴らしいですが、そのままやらせるのでなく、必要に応じて在宅勤務用のPCを別途用意するなど、情報および環境の区別・徹底は必要でしょう。本件の調査結果のリリースが出た翌日に、私もXでポストしましたが、漏らしてしまった個人の気持ちを想像すると、「つらいね」という気持ちが湧いた、というのが率直なところです。