この記事は Up&Coming という雑誌へ寄稿している内容とほぼ同一のものです。Up&Coming はフォーラムエイトさんという会社が発行している広報誌で、縁あって僕も記事を書かせていただけることとなりました。
「IT ならなんでも！」というご依頼だったのでネタチョイス的にこのブログとも相性がよく、寄稿した内容もブログに投稿することにしました。よければ本誌のほうもぜひお読みください（ネットで無料で読めます！）。
＝＝＝＝＝
この 1 年ほど、筆者は会社でセキュリティ系の対応に追われてばかりいます。AI が高品質なコードを一瞬で生成できるということは、それを使って攻撃をする悪い人にとっても便利な時代になってしまったということなのです。
なかでも今回は、最近特に猛威を振るっているサプライチェーン攻撃に焦点を当ててみることにしました。この概念自体は昔から存在するものですが、AI によりプログラミングの裾野が広がった結果、攻撃の脅威が一般ユーザーにまで拡大していると思われるからです。
これまでのサプライチェーン攻撃というのは主に開発者やソフトウェア関連会社などが遭遇する問題として認知されていましたが、バイブコーディング (1) などによってソフトウェア開発の敷居が下がったことでより多くの一般ユーザーもこの危険性を理解しなければいけなくなりました。攻撃者側は量産性や偽装能力を上げているいっぽうで、狙われる側は対象が増加、しかも防御力の低い層にもリーチしてしまっているという状況です。
とはいえ、これがサプライチェーン攻撃の怖いところでもあるのですが、自分たちが気をつけているだけではなかなか防ぐことができないのが大きなポイントです。
サプライチェーン攻撃とは
サプライチェーンという言葉はもともとソフトウェアセキュリティの文脈に限ったものではなく、あらゆる産業において製品やサービスが消費者の手元に届くまでの過程を指すものです。ズバリ物流の供給網をイメージするのが近いように思います。
これをソフトウェアで例えると「プログラムを書いてから実際にアプリケーションやサービスとしてエンドユーザーが使うまでの過程」となり、その過程で何かしらの攻撃を受けてしまうのがサプライチェーン攻撃、となります。
具体的な攻撃のイメージは次の章で詳しく紹介しますが、特徴として「自分が攻撃のきっかけになるわけではないのに被害には遭う」というイメージがすでにわかるかと思います。例えばショッピングサイトで注文した商品がトラックで輸送されて自宅まで運ばれてくるとして、もしかしたらサービスエリアで休憩しているトラックに異物が仕込まれてしまうかもしれません。これはトラックの警備に問題があったから起きることですが、その実害を被るのは商品を受け取る私たちなのです。実際の攻撃手法を見ながらもう少しこのイメージの解像度を上げていきましょう。
主なサプライチェーン攻撃の種類
ライブラリを使うためのプラットフォームに悪意のあるコードを登録する
みなさんが普段使っているアプリケーションやソフトウェアは、必ずといっていいほど既存のプログラム（ライブラリ）を活用して開発されています。これは自動車における完成車メーカーと自動車部品メーカーの関係を考えればわかりやすいですね。
これらのライブラリは企業が公開しているものもあれば有志のボランティアによって提供されているものなど様々ですが、ソースコードが公開されているものが多いです。ですが、当然の前提として誰でも好き勝手にソースコードを改変できるわけではありません。いたずらや迷惑メールのような種類のプルリクエスト (2) は普段から絶えないものですが、これらを含め悪意のあるコードを書いたとしても当然取り込まれるわけはありません (3)。
攻撃者は、ここで様々な工夫をしてなんとか悪意のあるコードをライブラリとして登録させようとします。具体的な手口はこのあと紹介する他の攻撃手法を組み合わせたものであったり、技術的に非常に複雑な手順を踏んだものであったりします（本稿では紙面も足りないため後者は割愛）。
ライブラリとして危険なコードが登録されると、それを利用している世界中のプログラムが一気に影響を受けうる状態になります。また、あるライブラリが別のライブラリに依存しているという多層構造も極めて一般的なため、連鎖的に影響を及ぼしてしまうような攻撃もありえます。まさにソフトウェアの配送網に対して行われるような攻撃ということで、特に最近ではサプライチェーン攻撃といえばこのソフトウェアライブラリの管理ツール周辺を狙ったものを指す風潮があるように思います。
postinstall スクリプトの悪用
ライブラリはたいてい、パッケージマネージャーというツールによってインストールされます。インストール時に動く処理が悪用されてしまうのがこの攻撃手法です。
パッケージマネージャーの中には、このインストール処理の前後に任意の処理を自動的に実行できる機能を持つものがあります。これらを preinstall/postinstall スクリプトなどと呼びます。複雑なライブラリでは単に部品として取り込むだけでは最適な結果を得ることができず、コンピュータに対して何らかの設定を加えたりする必要のあるものも多いのです。
しかしこれは攻撃者にとっては格好の餌食です。インストールさえしてもらえれば、そのライブラリのコードが動いていなくても自動的に任意のコードを実行できてしまうからです。postinstall スクリプトは被害者のコンピュータ内で直接実行されるため、例えばパソコンに含まれるありとあらゆる機密情報を隅々まで探し出して外部に送信するマルウェア（インフォスティーラーといいます）の実行も簡単です。しかも、マルウェア自体のソースコードは postinstall スクリプトに書く必要はありません。単に「https://xxx.com へ行ってマルウェアをダウンロードしてきてここで実行して」という命令を一文だけ書いておけば十分なので、事前に異変に気づくのもなかなか難しいものがあります。
最近ではこの事情を鑑みてか、デフォルトで postinstall スクリプトを実行するパッケージマネージャーの利用は業界としては減りつつあるのを感じています。
タイポスクワッティング
タイポとは誤字脱字やキーの打ち間違いのこと、スクワッティングとは不法占拠のようなニュアンス。非常にシンプルな罠で、かつ私たちユーザー側の不注意でうっかり引っかかってしまいやすい攻撃手法です。
これもソフトウェアライブラリを例にするとわかりやすいのですが、例えば「up-and-coming」という名前のライブラリがあったとして、それを自分の開発で使いたい場合は「npm install up-and-coming」などのようなコマンドを実行することになります (4)。このとき、もしコマンドを打ち間違えて「npm install up-and-coning」としてしまったとします。そして誰か悪い人がそれを狙って「up-and-coning」という攻撃用のライブラリをあらかじめ登録していたとしたら…？
これが名付けてタイポスクワッティングです。現代でも人間が手動でインストールを実行する操作というのは普通にありますし、もしこれに前述の postinstall スクリプトなどが仕込まれていたら目も当てられません。ネットワーク上にある何か外部のものを自分のパソコンに取り込むときは十分すぎるくらい注意しましょう。
ソースコード管理ツール内で動く自動化処理の中で秘密情報などを盗み取る
書き上がったプログラムは、GitHub などのソースコード管理ツール内にあるリポジトリという単位で記録していくのが通例です。複数人で開発する場合はほぼ必須ですし、個人であってもコードの変更記録がすべて残るため非常に有用なものです。
リポジトリのコードを更新したら、そのコードを使ってテストプログラムを動かしたり実際のユーザー向けにリリースを行なったりするところまで自動化したくなります（なるのです！）。なんとそのような仕組み (5) も GitHub をはじめ多くのソースコード管理ツールには備わっており、これも現代のソフトウェア開発においては非常にスタンダードなものとなりました。リポジトリを更新するたびに仮想マシンが起動し、あらかじめ設定しておいたテストやリリースの手順が順次実行されていく…というイメージです。
しかし自分たちが書いたソースコードをもとにコンピュータの中でなんらかの処理が動くということは、ここにも攻撃者のつけ入るスキがあるということにもなります。プログラムというのはソースコードだけがそこに存在していても絶対になにも起きることはありませんが、これを実行する主体（コンピュータ）が現れると何が起こるかすべてを正確に把握するのは急に難しくなります。
GitHub の仮想マシンの中では、アプリケーションをリリースするためのサーバーの重要な機密情報（パスワードのようなもの）などが使用されます。これら機密情報はソースコードとしてリポジトリに直接記録せず、専用の安全な場所に暗号化して記録するというのがセオリーなのですが、そうはいってもリリースする瞬間は当然復号していないといけません。もしこの瞬間に作動する攻撃が仕込まれていたら機密情報は丸ごと盗られてしまうでしょう。
実際にこの窃取が成功するためには複数の条件が重なる必要がありますが、万が一起きてしまったときのリスクは甚大です。企業にいたってはソースコード自体も非公開であることがほとんどですから、機密情報は無事でもソースコードが漏えいするだけで自社資産の流出ということになり、事態は深刻です。
私たちができる対策は？
フィッシングメールなどと違い、サプライチェーン攻撃に対して私たちが事前に行える対抗策、日ごろ気をつけられる点は正直言うとあまり多くありません。ソフトウェア開発者なら各技術についてより深く理解するべきなのは言わずもがなですが、一般ユーザーも含めて強いて挙げられる心がけがあるとすれば以下のようなものでしょうか。
- ブラウザや IDE（統合開発環境）の拡張機能は可能な限り利用しない（近年は特に攻撃されやすい場所です）
- ツールやアプリは公式ストア、公式サイトから入手する（SNS アカウントをハッキングして偽物アプリをダウンロードさせる手口も流行しています）
- OS やアプリの更新を止めない
3 つめを見て「OS やアプリの更新自体もそもそも気をつけないと危ないという話だったのでは？」という疑問を感じたのなら、それは非常に本質的な問いであると筆者も思います。OS レベルのアップデートですらサプライチェーン攻撃の対象になる可能性はたしかに否定できません。しかし IT 社会で生きる以上、どこかで何かは信頼しないといけないという現実があります。「ここまでは信頼するが、それ以上は自分でリスクを見積もる」という線引きを常に行うことこそセキュリティ対策の本質ではないでしょうか。
この 1 年くらいの間にバイブコーディングを始めてみたという方も多いでしょう。もし本稿で紹介した内容の中に心当たりがあるものがあれば、必ず自分の作業環境を見直してみてください。チェックする観点や対策の方法は、それこそ AI があなたを助けてくれるはず。優秀な AI は悪事にばかり使われるわけではありません。私たちの防御を強化する手立ても、彼らは教えてくれるのです。
[注釈]：
1. コーディングエージェントなどを使って自然言語のプロンプトのみでプログラミングを進めていくこと。雰囲気（バイブス）で行うことからこの名前がついています。
2. GitHub などで公開されているソースコードに対して、修正案を送り、管理者に取り込んでもらうための仕組み。誰でも改善に参加できるというのはオープンソースであることの大きな意義のひとつです。
3. リポジトリの管理者側にチームメンバーとして入り込んで悪意のあるコードを承認するような攻撃例も過去にはありました。なんとチーム内で信頼を得るために数年にわたって通常の仕事を行い、あるときいきなり攻撃に転じるのです。
4. npm は JavaScript というプログラミング言語において最もよく使われているパッケージマネージャーです。実際に postinstall スクリプトなどの問題がよく取り上げられがちなパッケージマネージャーでもあります（npm はいまだに postinstall の実行がデフォルトでオフではない）。
5. CI/CD（Continuous Integration/Continuous Delivery）という概念で、書いたコードをリポジトリに登録するたびにその最新状態をもとにテストプログラムを実行させたり検証用の環境に反映させたりすることを指します。