開発者のワークステーションは、ソフトウェアサプライチェーン攻撃において最もROIの高い標的となっており、この問題は深刻化の一途をたどっている。
「私が懸念している重要な指標が1つあります。過去3か月間、当社のサプライチェーンにおける脆弱性の件数は、その前の3か月と比べて7倍に増加しました」と、AI調達プラットフォームプロバイダーであるOmneaのエンジニアリングマネージャー、ギャビン・ウィリアムズ氏は述べる。
「時間が経つにつれて、各レジストリで問題や課題が増えているのがわかります。サプライチェーン攻撃が増えているだけでなく、AIツールによって検出される問題も増えているのです。開発者が脆弱性のあるパッケージや、すでに侵害されたものをインストールしてしまうのは、本当に簡単なのです」。
業界では長年にわたり、セキュリティ対策を開発プロセスの初期段階へと前倒ししてきました。しかし、攻撃対象領域そのものは、開発プロセスよりもさらに初期の段階、つまりマシンそのものへと移行しています。
この1年だけでも、攻撃者はさまざまな経路から侵入してきました。悪意のあるVS Code拡張機能を利用した最近のGitHubへの侵入、セキュリティツールを介したTrivy、パッケージマネージャーを経由したTanStack（ミニShai-Hulud）、悪意のあるパッケージを利用したTeamPCP攻撃などがありますが、これらにはすべて共通する重要な要素があります。それは、開発者の端末を標的としているという点です。そして、その手口は効果を上げているのです。
でも、なぜ？
私はこう考えています。ほとんどの商業ビルでは、正面玄関は鍵や防犯カメラなどで厳重に施錠されています。しかし、裏手にはスタッフ用入口があり、配達員が一日中出入りするため、防火扉は常に開け放たれたままになっています。そのスタッフ用入口は、すべての部屋の鍵が保管されているオフィスへと直結しており、そこは実質的に開発者の作業拠点となっているのです。
これまで、組織やそのセキュリティチームは、「自分たちには関係ない」という理由で、これをセキュリティ上のリスクとは考えてきませんでした。これは、自分たちに関係のないことだから誰も手を出さないだろうという、一種の盲信のようなものです。
しかし、攻撃者の立場からすれば、その扉（この場合はデバイス）が誰のためのものであるかは文字通り関係なく、抵抗が最も少ない場所を狙うのが理にかなっている。
EDRが検知する内容と、開発者が実際にインストールする内容との間の乖離
Latioの創業者兼アナリストであるジェームズ・バーソティ氏によると、サプライチェーン攻撃が頻発する主な理由の一つは、従来型の検知・管理ツールが開発者のエンドポイントの用途には適していないため、これらのエンドポイントがほとんど監視されていない点にあるという。
「EDRツールはきめ細やかではなく、主にインストールされているアプリやプログラムそのものに焦点を当てており、許可されたアプリケーションの内部構成には重点を置いていません」と、英国公共部門のDevSecOps ワリド・マフムード氏は述べる。
EDRはアプリケーションレベルで悪意のある活動を監視します。しかし、組織側では、npmパッケージ、IDE拡張機能、Chromeプラグイン、Cursorスキルなど、開発者が日常的に使用しているツール内部で何が起きているのかを確認することはできません。
これは重要な点です。なぜなら、問題はコードの一行も書かれる前から始まっているからです。
「問題は、セキュリティ上の脆弱性があるコードが本番環境にデプロイされることではありません。インストール段階ですら、GitHubの認証情報が漏洩してしまうという事態なのです」と、Omneaのギャビン氏は述べる。
例えば、悪意のあるパッケージは、開発者がインストールした瞬間にポストインストールスクリプトを実行し、認証情報を外部へ持ち出す可能性があります。
そしてもちろん、LLMのおかげでマルウェアの作成がいかに簡単になっているかについても触れておかなければなりません。Raisinのプロダクトセキュリティ責任者であるスティーブン・ジョージ氏は、これが自社にとって「死角」となっていた分野だったと述べていますが、そう感じているのは彼だけではありません。
英国の公共部門に勤務するワリド氏は、AIの導入がもたらしている影響について次のように説明する。「現在、多くの人がターミナル環境で作業しており、Markdownファイルなどを大量にインストールしています。しかし、当然ながら検証されたプロセスが存在しないため、RedditやXで見かけたものをダウンロードするのを止める手立てはありません。これらは、ユーザーにダウンロードさせるためのマルウェア攻撃の一環である可能性があります。そして、その後の展開は言うまでもありません。」
問題の一因は、開発者のマシンが存在する領域――つまり、アプリケーションセキュリティ、エンドポイントセキュリティ、アイデンティティ、サプライチェーンリスクがすべて交差する領域――を、どのチームも単独で管理していない点にあります。 そのため、EDRやMDMといったツールを用いてその空白を埋める方が容易であり、組織をこうした増大する脅威から真に保護することにはつながっていませんでした。しかし、もはやその手法は通用しなくなっていることが明らかになりつつあります。その代償として、大規模なサプライチェーン攻撃の標的となるリスクを負うことになります（これはかなり深刻な代償です）。
各チームがサプライチェーン攻撃から開発者のマシンをどのように保護しているか
サイバーセキュリティ企業GlasswallDevSecOps クリス・ホルマン氏は、同社の全環境にAikido Chainを導入した。
「サポート対象のパッケージを扱うすべての本番パイプラインにおいて、Safe Chainによるスキャンを実施し、悪意のあるコードが混入したものをインストールしないよう徹底しています。」
ワリドは、英国の公共部門全体でも同様の取り組みを行ってきた。
「ソフトウェア開発ライフサイクルで通常設けられているステージゲートを追加しましたが、そのステージゲートは現在ローカル環境に設置されています。そのため、開発者が何かをインストールする前に、ローカルマシン上で何らかの安全装置が動作し、確認を促してくれるという安心感が少し増しました。」
しかし、パッケージは単なる入り口に過ぎません。ギャヴィンのチームは、開発者向けデバイス全体にわたるより広範な可視性が必要だと気づいた時点で、すでにSafe Chainを利用していました。
「これまで『Safe Chain』を使ってきましたが、全員のデバイスを包括的に管理し、セキュリティ上の問題があるアプリがインストールされていないかを確実に確認できる仕組みは、まさに画期的な変化をもたらすでしょう」とギャビンは語った。
こうした経緯から、いくつかのチームはAikido「デバイス保護」に着目するようになった。これは、パッケージレジストリにとどまらず、IDE拡張機能、ブラウザプラグイン、AIツールにまでその原則を拡張するものだ。
ワリドはこれを「Safe Chainの強化版」と表現している。彼は次のように述べている。「これにより、開発者が何を使用しているか、あるいは何をインストールしようとしたかを知るためのテレメトリデータが得られるため、誰が攻撃を受けやすいかについて、より詳細な情報を把握できるようになる」。
Cognismのクリスティーナ率いるチームも、同様の理由からこのツールの導入を計画している。「現在、これほどの広範なカバー範囲を持つツールは他にありません。EDRツールでは開発者のマシンにインストールされたパッケージは表示されず、Chrome拡張機能の脆弱性についても他のベンダーは対応していません。私たちはそのギャップを確実に埋めていきます。」
スティーブンはすでにこれを試してみました。「ブラウザ拡張機能、Cursor拡張機能、そしてすべてのパッケージレジストリを一覧で確認できるのは本当に嬉しいです。これにより、開発者用マシン全体の脅威モデルを把握できるようになります。」
話を聞いたすべてのチームが、同じ課題を指摘していました
これらの会話に見られた傾向は一貫しており、業界や企業を問わず、セキュリティやエンジニアリングの責任者たちは皆、独立して同じ課題を指摘していました。開発者のマシンは既存のツールの網の目から漏れる隙間に位置しており、攻撃者たちはその弱点を突き止めているのです。
すでにこの問題に取り組んでいるチームは、パッケージレベルの制御から着手し、現在はデバイス全体の可視化へと範囲を拡大しています。まだ着手していないチームは、おそらく本記事で言及されたすべての攻撃を見逃してしまったのと同じEDRおよびMDM環境を運用しているでしょう。
Device Protectionの仕組みについてはこちらをご覧ください。または、こちらから試用できます。
