タグ: フィッシング

Security NEWS TOPに戻る
バックナンバー TOPに戻る

AIを活用したコーディングが普及する一方で、オープンソースソフトウェア（OSS）を狙ったサプライチェーン攻撃が増加しています。特に、開発者のタイポを悪用する「Typosquatting」や、AIのハルシネーションに便乗する「Slopsquatting」といった手法は、身近で深刻な脅威です。本記事では、実例を交えながらその仕組みとリスクを解説し、安全なAIコーディングを実践するためのポイントを紹介します。

コードを書く人やインフラストラクチャの構築をする人ならば、人生で最低でも一度は経験しているであろうこと、それはタイプミス、いわゆるタイポ（typo）ではないでしょうか。タイポ、些細なミスで、日常的に発生するものなのですが、中には重大なものもあります。

タイプミスが招く落とし穴 ─ Typosquattingとは

皆さんは「タイポスクウォッティング」という言葉をご存じでしょうか。Web関連のお仕事をされている方であれば、URLのタイポスクウォッティング、つまり間違いやすい・紛らわしいURLでユーザーをおびき寄せる手法としてのタイポスクウォッティングをご存じの方も多いかと思います。この手法がオープンソースソフトウェアでも昨今使用されるようになっています。

例えばnpmの場合、

npm install package_name

と入力することでパッケージのインストールを実行できます。インストールしたパッケージは例えばjavascript（react）を利用している環境であれば

import {
コンポーネント名
} from “@/fullpath/to/package_name”;

の形でコードの先頭で利用するパッケージ名を宣言します。

世の中にはこのパッケージ名のよくあるタイプミス（typo）を狙って作られたマルウェアの一種が存在します。そんなマルウェア、何のためにあるのだろうという方も多いと思いますが、例えば暗号資産のウォレットを狙ったマルウェアや、システムへの侵害目的のマルウェアなどが最近では話題になっています。

npmやPythonなどOSSでの事例

• Phylum,[Typosquat Campaign Targeting npm Developers]（https://blog.phylum.io/supply-chain-security-typosquat-campaign-targeting-puppeteer-users/）
• Socket,[Malicious Python Package Typosquats Popular passlib Library, Shuts Down Windows Systems]（https://socket.dev/blog/malicious-python-package-typosquats-popular-passlib-library）

暗号資産を狙うマルウェアの脅威

暗号資産を狙ったマルウェアについては偽の採用面接中に実行を求められるケースも報告されています。

Socket,[Another Wave: North Korean Contagious Interview Campaign Drops 35 New Malicious npm Packages]（https://socket.dev/blog/north-korean-contagious-interview-campaign-drops-35-new-malicious-npm-packages）

偽の採用プロセスとソーシャルエンジニアリング

採用面接に至るということは例えば採用条件面で魅力的である、採用プロセスに見せかけたフェーズで偽の採用者に対して高い信頼を持つよう誘導されている、著名な企業などに成りすますことで権威性・信憑性を信じさせられる、オンライン環境による信頼レベルを悪用される、といったソーシャルエンジニアリングの基本ともいえる「人」が抱える脆弱性をすでに悪用された状態です。

関連記事：
「ソーシャルエンジニアリング最前線【第1回】ソーシャルエンジニアリングの定義と人という脆弱性」（https://www.sqat.jp/kawaraban/37089/）

その状態で、面接というストレスのかかる、失敗が許されないと思ってしまう状況で紛らわしい名称の不正なコードや、不正なパッケージを含むコードを実行させられた場合、気づくことは容易ではありません。面接で突然コードを実行させられることに違和感を覚えてその場を退出することが最善かもしれませんが、Zoomのリモートコントロール機能を使ってマルウェアを実行するケースもあることから、特にすべてをオンラインで完了させるタイプの採用プロセスそのものに対して常に疑わしいかどうか疑問を持ち続けるしか対策はないかもしれません。

Zoomのリモートコントロール攻撃

参考情報：

The Trail of Bits Blog,[Mitigating ELUSIVE COMET Zoom remote control attacks]（https://blog.trailofbits.com/2025/04/17/mitigating-elusive-comet-zoom-remote-control-attacks/）

なお、昨年末に警察庁・内閣サイバーセキュリティセンター・金融庁連名で偽の採用試験関連で注意喚起が出ています。今一度ご確認ください。

警察庁／内閣サイバーセキュリティセンター／金融庁「北朝鮮を背景とするサイバー攻撃グループ TraderTraitor によるサイバー攻撃について （注意喚起）」（令和6年12月24日）（https://www.npa.go.jp/bureau/cyber/pdf/20241224_caution.pdf）

タイポよりも怖い？生成AI時代の新たな罠 ─ Slopsquatting

生成AIやAIエージェントの普及でAIを使用したコーディングを行う人も増えていると思います。「typoもないし、いいじゃない？」と思う方も多いと思いますが、生成AIには「ハルシネーション」という最大の難点があります。人間のtypoぐらいの頻度で遭遇する現象の一つといっても言い過ぎではないかもしれません。そんなハルシネーションを狙って、偽のパッケージが用意されていたら？という内容のレポートが公開されました。

参考情報：

トレンドマイクロ株式会社「スロップスクワッティング：AIエージェントのハルシネーションにつけ込む攻撃手法」（https://www.trendmicro.com/ja_jp/research/25/g/slopsquatting-when-ai-agents-hallucinate-malicious-packages.html）

生成AI単体には生成内容の検証メカニズムがありません。このため、AIエージェントを利用したコーディングの場合はエージェント側の機能として備わっている検証機能を利用することが必要です。具体的な手法はレポートにも記載がありますが、日進月歩で新たな機能が登場する現状では最新の情報も併せて探すことをお勧めします。 また、エージェントを用いない場合も含めて、以下のようなリスク回避策を基本とするのもよいかもしれません。

• 参照するパッケージ・モジュールを限定して、typosquattingやslopsquattingなどのリスクを回避する
• やむを得ず新しいパッケージ・モジュールをインストールする場合は人の手を介したチェックを行うことで、リスクを抑制する

実際に筆者もプロンプトで利用パッケージを限定していますが、特に利便性の阻害を感じたことはありません。また、周囲とのコミュニケーションでパッケージ・モジュールの情報の交換、推奨などの情報を得ることも多くあり、AI時代のコーディングとはいえコミュニケーションも併せて重要であることを実感しているところです。

プロンプトエンジニアリングと検証の重要性

前出のレポートで指摘されている原因の一つにはプロンプトの一貫性やあいまいさといった自然言語による指示ならではの問題があります。プロンプトエンジニアリングなどについては以下の記事でもご紹介しています。ただし、モデル側の実装状況などによりユーザー側の努力の反映には限界があるため、必ず生成結果に対する人のチェック（一種のHuman in the Loop）はプロセスとして欠かさないことが望まれます。

関連記事：
「AIコーディング入門　第1回：Vibeコーディングとプロンプトエンジニアリングの基礎」（https://www.sqat.jp/kawaraban/38067/）

正規リポジトリの乗っ取りという最大の脅威

2025年7月、npmの開発者をターゲットにしたフィッシングが報告されました。この後、複数のパッケージの乗っ取りが報告されています。

npm開発者を狙ったフィッシング事例

• Socket,[npm Phishing Email Targets Developers with Typosquatted Domain]（https://socket.dev/blog/npm-phishing-email-targets-developers-with-typosquatted-domain）
• フィッシングの被害に関連する実際のSNS投稿: https://x.com/JounQin/status/1946297662069993690
• https://bsky.app/profile/jordan.har.band/post/3ludlbnstr22wSocket,[npm ‘is’ Package Hijacked in Expanding Supply Chain Attack]（https://socket.dev/blog/npm-is-package-hijacked-in-expanding-supply-chain-attack）

オープンソースソフトウェア（OSS）経由のサプライチェーン攻撃

ここまででお気付きの方も多いと思いますが、今回取り上げた様々な攻撃手法はすべてオープンソースソフトウェア経由のサプライチェーン攻撃として、１つにまとめることができます。プログラミング言語の多く、そしてWebサイトの構築に用いられるJavaScriptのフレームワークの多くはオープンソースソフトウェアとして流通しています。プログラミング言語やJavaScriptのフレームワークは実際に利用するにあたって利便性を向上させる目的で多くのパッケージやモジュール、ライブラリなどがオープンソースとして開発・公開されています。これらのオープンソースソフトウェアは現在では多くが多数のコントリビューターとメンテナーによってGitHub上で公開され、開発が行われています。GitHubからnpmなどのパッケージ管理システムへの公開も一貫して行うことができるため、非常に利便性が高い反面、今までに挙げたような攻撃を仕掛けるための利便性も高くなっています。また、オープンソースソフトウェアは相互に依存性を持つことが多いことから、人気のあるモジュール・パッケージへの攻撃が多数のモジュール・パッケージやシステムへ影響を及ぼすことができます。これが、オープンソースソフトウェアへのサプライチェーン攻撃における最大の特徴ともいえるかもしれません。オープンソースソフトウェアを利用する以上、こういったリスクがあることは十分理解したうえで利用する必要があります。

オープンソースソフトウェアの利用の条件としてセキュリティ面でかなりハードルが高いのは事実ですが、一方で利便性・柔軟性・モダンなシステムの構築といった観点からオープンソースソフトウェアを全く利用しない（プロプライエタリソフトウェアだけで構築する）というのは難しいという現状に鑑みるとやむを得ない選択であるとも言えます。

開発者がとるべき対策

こういったケースに対応するには依存関係のチェックや追跡、SBOMによる管理が必要になります。依存関係のチェックや追跡にはGitHubを使用している場合ならばDependabotの利用、その他のコードレポジトリを対象とする場合は各種の依存関係トラックツールを使用する必要があります。SBOMで自身のコードのコンポーネントと依存関係の管理を合わせて行うことで、システム全体としての管理を行うことが求められます。

まとめ ― AI時代のオープンソースソフトウェア利用に求められる視点

タイプミスを悪用した Typosquatting、AIのハルシネーションに便乗する Slopsquatting、さらには正規リポジトリの乗っ取りといった攻撃は、いずれもオープンソースソフトウェアを媒介とするサプライチェーン攻撃として位置づけられます。これらは利便性と引き換えに大きなリスクを伴い、暗号資産の窃取やシステム侵害といった深刻な被害へとつながりかねません。OSSの依存関係は複雑で、人気パッケージが狙われることで広範囲に影響が及ぶことも少なくありません。そのため、参照パッケージを限定する運用、人による確認（Human in the Loop）、Dependabotなどの依存関係管理ツールの活用、SBOMによる包括的なコンポーネント管理 といった対策が不可欠です。AIを活用したコーディングが普及する中でも、「便利だから任せる」のではなく、常に検証と疑問を持ち続ける姿勢 が求められます。セキュリティと利便性の両立こそが、これからのOSS利用とAI開発における鍵といえるでしょう。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

最新情報はこちら