あなたのDrupalサイトが、ある朝まったく別物にならないために

Packagist が Aikido Intel でマルウェア版をデフォルトブロック

Drupal や WordPress を動かしていると、サイトは毎日外から小突かれている。コメント欄に貼られる怪しいリンク、止まないログイン試行、フォームに流し込まれる変な文字列。たいていは何も起きない。アプリも、その下の PHP も、それぞれ穴を塞いで身構えているから、一発二発の小突きは弾き返す。

問題は、二つ目の穴が空いたときだ。

外からの攻撃が一つ通っただけなら、まだ持ちこたえる。だが、あなたが信頼して入れているライブラリそのものが悪性になっていたら、話は別だ。内側からの穴と外からの小突きが噛み合った瞬間、防御は抜ける。

ある朝アクセスしたら、見覚えのないページにリダイレクトされ、サイトが全然別物になっている。極端に言えば、なぜかベイビーメタル風のページになっている。そうなっても、もう驚かない。

その「二つ目の穴」が、いま現実に空きやすくなっている。メンテナのアカウントが乗っ取られ、信頼されたパッケージに悪性版が混ぜられる。いわゆるサプライチェーン攻撃だ。あなたは何も悪いことをしていない。いつも通り更新しただけ。なのに、悪性版を掴まされる。

何が変わったか

PHP のパッケージレジストリ Packagist と、その導入ツール Composer が、この穴を塞ぎにきた。

Aikido Intel が「この版はマルウェアだ」とフラグを立てると、その情報が Composer の依存関係ポリシーに反映され、Composer がその版を自動ではじく。composer update や composer require だけでなく、マルウェアについては composer install でも止まる。つまり、ロックファイルを書いた後にその版が悪性判定された場合でも、次のインストールで気づける。

重要なのは、これが Composer 2.10 以降でデフォルトON ということだ。特別なプラグインも、追加設定も、オプトインもいらない。Composer を更新していれば、何もしなくても効く。

誰が嬉しいか

まず、Drupal ユーザーだ。

Drupal を Composer で管理しているサイトなら、この保護がそのまま効く。Drupal 8以降の標準的な運用では、多くのサイトがモジュールや依存関係を Composer 経由で扱っている。だから、管理画面だけを見ている利用者には見えなくても、裏側の更新フローで Composer が動いていれば、危ない版を掴む前に止まる。

セキュリティに詳しくなくていい。

危ない版を掴みかけたら、Aikido が代わりに止めてくれる。あなたがその穴の存在を知らなくていい。これが、この仕組みの一番いいところだ。

Composer で依存を管理している PHP 開発者も同じだ。むしろ詳しい人ほど嬉しい。ロックファイルを書いた後に、ある版が悪性判定されれば、次の composer install で失敗して気づける。CI が黙って汚染版を引く事故が減る。

さらに Packagist は、公開済みの安定版を後から書き換えにくくする方向にも動いている。いわゆる re-tagging 攻撃、つまり一度信頼されたタグを後から悪性コードに差し替える手口への対策だ。一度検証してロックした版を、後からこっそりマルウェアにすり替えられない。この差は大きい。

WordPress の人、ごめんなさい

素の WordPress、つまり管理画面から wordpress.org のプラグインを入れる普通の運用では、Composer も Packagist も通らない。だから今回のブロックは、そのままでは効かない。

WordPress のプラグインのサプライチェーンは別の世界で、守り方も「Composer が事前に止める」ではなく、「検出・スキャン・更新管理」が中心になる。今回の話をそのまま WordPress 全体に当てはめるのは正確ではない。

本当に予防的に寄せたいなら、Bedrock などを使って WordPress を Composer 管理に寄せる選択肢はある。ただし、それは少し詳しい人向けの運用になる。

まとめ

普段は何も感じない。これが正しい。

この機能は、事故が起きた日にだけ、あなたが掴みかけたマルウェアを黙って止める。もし今後、更新が突然失敗したら、それは故障ではなく、保護が効いた合図かもしれない。

エラーを無視して無理やり入れる前に、なぜ止まったか一度だけ確認してほしい。

Aikido Intel が何をフラグしているかは、誰でも見られる。公開・無料で intel.aikido.dev にある。