はじめに
スロップスクワッティングは、GPT-4のような大規模言語モデル（LLM）の能力を活用した、ソフトウェアサプライチェーン内の新しい脅威です。
開発者が誤って使用する可能性のある、もっともらしいが実際には存在しないパッケージ名をLLMが生成することに関連していて、潜在的なセキュリティリスクをもたらします。
タイポスクワッティングは以下にも説明していますが、人によるパッケージ名などの「打ち間違い」を利用した脅威で、そのLLMバージョンといった感じでしょうか。
Goパッケージを装ったマルウェアに注意
https://kumahiyo.com/go-malware/
主要な概念
タイポスクワッティングと同様に、スロップスクワッティングはAIツールによる偽のパッケージ名の生成を悪用します。
これらのパッケージは正当なものに見えますが、完全に架空のものであり、攻撃者がそれら架空のパッケージ名を実際に登録した場合にリスクとなります。
LLM生成パッケージやLLMは自動補完やコード提案を通じて、これらの架空のパッケージ名を一貫して生成できるため、悪用される可能性が高まります。
また、バイブコーディング(開発者が望む結果を説明し、実装の生成をAIに依存する新しいコーディング手法)により、AI生成の依存関係への依存が高まり、スロップスクワッティングのリスクが高まります。
リスクと影響
スロップスクワッティングは、悪意のあるまたは侵害されたパッケージを広く使用されるプロジェクトに導入することで、オープンソースエコシステムを危険にさらす可能性があります。
多くの開発者は厳密な検証なしにAIツールを信頼していると思いますので、その信頼が攻撃者がスロップスクワットされたパッケージを悪用する機会を作り出しています。
AIツールが広く架空のパッケージを推奨し、それが攻撃者によって登録された場合、広範囲にわたる侵害の可能性が大幅に高まります。
対策
セキュリティツール
Socketのようなセキュリティプラットフォームを使用して、インストールスクリプトや難読化されたコードなどの高リスクな動作を依存関係ツリーでスキャンし、悪意のあるパッケージが本番環境に入るのを防ぎます。
リアルタイムの脅威検出
ブラウザ拡張機能やその他のツールを使用して、不審なパッケージに関するリアルタイムのアラートを収集します。
積極的な監視
依存関係を継続的に監視し、プロジェクトに統合する前に検証し、異常または新しく公開されたパッケージを捕捉します。
LLMのモデル選択
自身が架空のパッケージ名を提案したことを特定できるモデルの開発を促進している企業のモデルを選択し、内部検出精度を向上させます。
EC-CUBE開発でAIがパッケージを提案したときの確認手順
EC-CUBE 4系では、オーナーズストアのプラグインもComposerパッケージ（ec-cube/プラグインコード）として扱われ、bin/console eccube:composer:require のコマンド1行で導入します。
AIが提示したコマンドが正規の導入手順と同じ形をしていても、そのパッケージ名が実在するとは限りません。
クマひよ工房ではEC-CUBEの開発にAIを活用していますが、AIがパッケージやプラグインの追加を提案したときは、導入前に次の4点を確認しています。
1. 標準機能で代替できないか検討する
EC-CUBEやSymfonyの標準機能で実装できるなら、パッケージを追加しません。依存が1つ減れば、偽のパッケージが紛れ込む入口も1つ減ります。
2. 実在と公開元を確認する
プラグインはオーナーズストア、ライブラリはPackagistで、パッケージが実在するか、公開元・更新履歴・ソースのリポジトリを確認します。
3. AIが出したコマンドをそのまま実行しないcomposer require や eccube:composer:require を、お客様の本番環境でそのまま実行しません。
4. composer.lock の差分をレビューする
指示したパッケージ以外に、意図しない依存が増えていないかを確認します。
最後に
スロップスクワッティングは、積極的な対策と高度なセキュリティツールを必要とする深刻な新しい脅威です。
AIがソフトウェア開発ワークフローに統合され続けるにつれて、これらのリスクを理解し対処することが、安全なサプライチェーンを維持するために不可欠になります。