ピックアップテーマ
ロジスティクスWMS（倉庫管理システム）やTMS（輸配送管理システム）を普段通りに更新したら、その更新が感染経路になる。入出庫データが漏れ、配車指示が止まり、荷主への出荷が滞る。その入り口が、日常の更新作業そのものになる。3月に入って世界のソフトウエア開発基盤で大規模に拡散したマルウエア「グラスワーム」（GlassWorm）は、この事態を現実の射程に入れた。（編集長・赤澤裕介）
WMSやTMSそのものが攻撃されたという報告は、18日時点では確認されていない。だが、WMSやTMSを開発・運用しているITベンダーが、グラスワームに汚染された部品を知らずに使っていれば、次のアップデートで物流システムに感染コードが入り込む。これがこの記事の核心だ。
ソフトの中の下請けが崩れている
物流業界は多重下請け構造のリスクを知っている。元請けが2次・3次の下請けの実態を把握できず、どこかが崩れると全体が止まる。グラスワームが突いたのは、ソフトウエアの世界にあるまったく同じ構造だ。
WMSやTMSは、開発者がゼロから作っているわけではない。世界中の開発者が公開しているオープンソースの部品を何十、何百と組み合わせて構築されている。その部品はさらに別の部品に依存し、依存の連鎖は5層、10層と深くなる。自社のシステムがどの部品に依存しているか、その全体像を把握している物流企業はほぼない。ITベンダーですら、末端の依存先まで管理しきれていないケースがある。
物流でいえば、こういう状態だ。自社の荷物を運んでいるトラックの2次下請け、3次下請けが誰なのか分からない。その下請けが事故を起こしても、自社の荷物が載っていたことに気づくのは荷主からクレームが来てからだ。ソフトウエアの依存構造で起きていることは、これとまったく同じだ。
グラスワームはこの「見えない下請け構造」を攻撃した。
なぜ今、この攻撃が成立したのか。オープンソースへの依存が臨界点に達したからだ。現代のソフトウエア開発では、コードの大部分が外部のオープンソース部品で構成されている。開発のスピードと効率を優先した結果、依存構造は複雑化し、末端まで把握することが事実上不可能になった。グラスワームはその構造の弱点を突いた。個々の企業が自社のセキュリティーを強化しても、依存先のどこか1か所が汚染されれば感染が成立する。攻撃の標的は個別のシステムではなく、ソフトウエア供給網そのものだ。従来の「自社のセキュリティーを固めれば守れる」という前提が通用しない領域に入ったことを、この攻撃は示している。
▲グラスワームの主な感染拡大状況（開発基盤別）（クリックで拡大）
ギットハブは世界最大のプログラム共有サイト、npmはプログラム部品の配布サービス、Open VSXはオープンソース版のコード編集ソフト拡張機能の配布基盤だ。この3つは、ソフトウエア開発のインフラにあたる。物流でいえば、港湾・幹線道路・配車センターに相当する基盤が同時に汚染されたことになる。
攻撃の手口は、プログラムのコードの中に人間の目には映らない特殊な文字でウイルスを埋め込むものだ。開発者がコードを読んでも、変更履歴を確認しても、画面には何も表示されない。だが実行するとパスワードや認証情報が外部に送信される。セキュリティ企業のアイキドー（Aikido）とステップセキュリティ（StepSecurity）がこの手口を解析し、報告した。
盗んだ認証情報を使って別の開発者のアカウントに侵入し、さらに別のプロジェクトにウイルスを仕込む連鎖も確認されている。しかも変更履歴の著者名も日時も元のまま保持するため、管理者が見ても改ざんに気づけない。16日にはスマートフォンアプリ開発で広く使われる人気部品2件（合計月間ダウンロード13万件超）にも感染が確認された。
ここで重要なのは感染の経路だ。ある部品Aが安全に見えても、部品Aが内部で読み込んでいる部品Bが汚染されていれば、Aをインストールした時点で感染が成立する。セキュリティー企業のソケットがこの手法を確認し、従来のコードレビュー（プログラムの目視検査）では検知できないと警告した。物流の多重下請けで、元請けが直接契約している1次下請けは問題なくても、その先の2次下請けが事故を起こせば荷主に被害が及ぶのと同じ構造だ。
自社のシステムが何に依存しているか把握できていなければ、感染の有無すら確認できない。クラウド型のサービスであっても、ベンダー側のサーバーが汚染されていれば同じことが起きる。自社で直接ギットハブやnpmを使っていなくても、ベンダーが使っていれば影響を受ける。
WMSやTMSに感染コードが入り、更新停止や緊急遮断が必要になれば、現場で起きることは明確だ。
▲物流システム停止時に想定される現場影響（クリックで拡大）
すべての物流企業が同じリスクにさらされているわけではない。先に詰まるのは次の条件に当てはまる企業だ。ITベンダーにシステムを丸ごと委託し、依存部品の構成を把握していない企業。SBOMの提出を求めたことがない企業。ソフトウエア部品の自動更新を止める手順を持っていない企業。この3つのうち1つでも該当すれば、グラスワームの影響を受けた部品が次の更新で入り込んだとき、検知も遮断もできない。自動更新を前提に運用しているシステムは、更新そのものが攻撃経路になる以上、設計思想から見直しが必要になる。
「ITベンダーに確認します」で終わらせてはならない。確認すべきことは3つある。
まず、自社のWMS・TMS・ERP（基幹業務システム）が依存しているオープンソース部品の一覧（SBOM、ソフトウエア部品表）をITベンダーから書面で取得する。SBOMが存在しない場合、ベンダーは自社製品の依存構造を把握していない。それ自体がリスクだ。
次に、取得したSBOMを、グラスワームの影響を受けたパッケージのリスト（セキュリティ企業のアイキドーとソケットが公開している）と照合する。自社で照合できなければ、ベンダーに照合結果を書面で提出させる。
さらに、ソフトウエア部品の自動更新が有効になっている場合、更新を一時停止する。安全が確認された部品だけを手動で適用する手順に切り替える。クラウド型のサービスを使っている場合は、ベンダーがこの3点を実施済みかどうかを書面で回答させる。口頭の「対応済みです」では証拠が残らない。
グラスワームの感染拡大は現在も進行中で、ステップセキュリティーによると攻撃者はウイルスの送信先を1日に複数回変更している。次の更新ボタンを押す前に、その更新が安全かどうかを確認する手順があるか。なければ、感染コードはそのまま入ってくる。
■「より詳しい情報を知りたい」あるいは「続報を知りたい」場合、下の「もっと知りたい」ボタンを押してください。編集部にてボタンが押された数のみをカウントし、件数の多いものについてはさらに深掘り取材を実施したうえで、詳細記事の掲載を積極的に検討します。
※本記事の関連情報などをお持ちの場合、編集部直通の下記メールアドレスまでご一報いただければ幸いです。弊社では取材源の秘匿を徹底しています。
LOGISTICS TODAY編集部
メール：support@logi-today.com
LOGISTICS TODAYでは、メール会員向けに、朝刊（平日7時）・夕刊（16時）のニュースメールを配信しています。業界の最新動向に加え、物流に関わる方に役立つイベントや注目のサービス情報もお届けします。
ご登録は無料です。確かな情報を、日々の業務にぜひお役立てください。
