IT & Information security Journal
2026年5月から6月にかけて、良品計画や東芝、象印マホービンなど複数企業のWebサイトで、ユーザー名とパスワードの入力を求める不審な認証画面が相次いで表示されました 1。原因は、2024年にソフトウェアサプライチェーン攻撃の温床にもなったJavaScriptライブラリ「polyfill.io」を、各社が依然として削除していなかったことにあります。
Web開発の利便性を支えてきたライブラリが攻撃経路となった今回の事案は、ソフトウェアサプライチェーンのリスク管理に関する課題を浮き彫りにしています。Webセキュリティの第一人者である徳丸浩氏に「防げた事故だったのか」と、本件を教訓として企業がとるべき対策、ソフトウェアサプライチェーンをとりまく昨今の問題について聞きました。
この記事のポイント
polyfill.ioによる今回の問題は、ベーシック認証のダイアログが表示される形で顕在化したが、もしも攻撃者に強い悪意があり、巧妙な手口を使っていたとすれば、情報の窃取や不正なAPI操作、フィッシングなどにつながった可能性も考えられる
本件の発生は防がれるべきだった一方で、過去の経緯を含めて知らなかったエンジニアも少なくないと推察される。知らなかったことに問題はあるものの、強く責められるものではないといえる
現実的な対策は、ソフトウェアサプライチェーンの脅威を念頭に置いて最新情報に気を配り、何かあればすぐに自社への影響を確認すること。また「サブリソース完全性」という技術的な対策をとることや、外部ツール等の使用を最小限に抑えることも有効
ソフトウェアサプライチェーンに関する脅威は、セキュリティ分野で強く問題視されている。オープンソースのライブラリは、1人の個人が10年以上メンテナンスし続けているケースも少なくないなか、協力者や買収者が侵害等を行う事態が発生している
このたび発生した、polyfill.ioにまつわる問題の経緯を教えてください。
今回、問題の原因となったpolyfill.ioは、ブラウザー間の機能の差異を埋めるために使われてきたライブラリです。具体的には、Internet Explorer（以下、IE）で動かなかった最新のJavaScriptの機能をエミュレート（再現）するために用いられることがほとんどであり、IEのためにあるようなソフトウェアだといえます。
ただし、IEのサポートは2022年6月に停止しており、現在はpolyfill.ioを使う必要性はなくなっています。さらに、2024年にはpolyfill.ioの権利やドメイン名が売却され、それを買い取った事業者が、マルウェアを含む汚染したソフトウェアを配信したとして問題になりました。こうした点を踏まえると、そもそも機能が不要になった時点で、利用者はpolyfill.ioを自社の環境から削除すべきでしたし、少なくとも問題が起きたときに速やかに対応しておくべきでした。
2024年に発生した問題については、その後、polyfill.ioのドメインがテイクダウンされ、強制的に使えなくする措置がとられました。これにより、polyfill.ioのJavaScriptは読み込めなくなり、未対応の環境ではエラーが発生していたはずなのですが、最新の各ブラウザーでは特に問題が起こることがなかったために、放置していたところが少なくなかったようです。
いずれにしても、2024年に事態は一旦沈静化していました。しかし、経緯は不明ながら、最近このドメインが復活してJavaScriptを再度配信するようになり、ベーシック認証のダイアログが表示される今回の問題が発生しました。
本件では、ベーシック認証のダイアログが表示される形で問題が顕在化しましたが、polyfill.ioの管理者に強い悪意があった場合には、さらに被害が深刻化していた可能性も考えられるでしょうか。
もしも強い悪意があり、巧妙な手口を使ったとすれば、さらに悪いことができたと考えられます。
ベーシック認証のダイアログが表示される本件の事象については、ログインしないとその先に進まないわけですから、大きな実害まではなかったのではないかと推測します。しかし、意図をもってすれば、ばれにくい形で攻撃を展開することも可能だったはずです。
例として、認証を求めるタイプのサイトで侵害されたJavaScriptが動作した場合、ログイン後のページで、情報の窃取やユーザーの権限を使った不正なAPI操作などが行われる可能性があります。また、詐欺サイトにリダイレクト（遷移）させてフィッシングを仕掛けることなどもできた可能性が考えられます。
少なくない数の企業が被害を公表していますが、その時期にはややばらつきがあるようです。
個人情報が漏れたと明らかにわかる事案であれば、早々にリリースを出そうとなるのでしょうが、本件の事象が発生した各企業のなかには、そこまでの被害だと捉えておらず、しばらく様子をみようと考えているところもあったのではないでしょうか。
そうしたなか、セキュリティ意識の高い企業がリリースを出しはじめたことで、後追いでリリースを出すことにした企業もなかにはあるのではないかと推察します。
本件は「防げた事故」か「対策・管理が難しい事故」か、どちらでしょうか。
この質問には2つの観点から回答したいと思います。
まず、事態の発生は防がれるべきだったという観点です。polyfill.ioに関しては、2024年に問題が一度発生していたわけですから、その時点で各社がWebサイトの確認や棚卸しをして、使用を終了するなど適切な対応がとれていれば、今回の事態は起こりませんでした。次善の対策として、Cloudflareなど複数社がpolyfill.ioの安全なバージョンを提供しているのでそれを利用したり、もしくは自社のサーバーに置いたりする選択肢もありました。
ただし、もう1つの観点として、2024年当時、polyfill.ioの問題はそれなりに話題になったとはいえ、ややマニアックな事案であり、日本中のエンジニアが認知していたわけではないと思います。本件が発生した際も、ソフトウェアセキュリティに関心がある層であれば過去の経緯に思い当たったかもしれませんが、2024年に起こったことを初めて知ったエンジニアの方も少なくないのではないでしょうか。知らなかったことにも問題はあるものの、強く責められるものでもないのかなと思います。
本件を教訓として、企業のセキュリティ担当者はどのような対策をとるべきでしょうか。
まず、大抵の企業が自社のWebサイトを持っている以上、ソフトウェアサプライチェーンに起因する影響をいつか受けるかもしれないという意識を持つ必要があるでしょう。Webサイトを自社開発している企業はもちろんのこと、開発を委託している場合でも、制作会社が断りなくpolyfill.ioを使っている可能性も十分に考えられます。
いずれの場合でも、外部のライブラリが汚染されるという脅威を念頭に置いて、最新情報やニュースに気を配り、何かあった場合にはその都度、自社への影響を確認することが現実的な対策だと思います。
あくまで都度の対応が基本であり、たとえば、自社の環境で使用しているリソースをすべて把握して管理しきるようなことは現実的ではないということですね。
そのほか、技術的な対策として、JavaScriptを読み込む際に、そのソフトウェアが汚染されていないかどうかをチェックするための「サブリソース完全性（Subresource Integrity、SRI）」という仕組みを利用することも考えられます。外部からJavaScriptを読み込むscriptタグには、integrity属性というものを指定できます。そこに、各外部ファイルのハッシュ値を記載しておくことで、ファイルに変更があった場合には即座に読み込みが行われなくなり、エラーが返されるようになるという対策です。この仕組みを使用していれば、今回のpolyfill.ioによる問題は防げたと思います。
ただし、外部のJavaScriptを使用する際に毎回そうした設定をするのは大変だということで、実際にはこの方法はあまり使われていないように思います。個人的には、外部のJavaScriptで問題が発覚するたびに都度対応するよりも、サブリソース完全性を用いたほうが楽なようにも思われますが、なかなか導入には至っていないのが現状です。
さらに、そもそも外部のツールやJavaScriptの使用を最小限に抑えるのも、リスクの低減につながるでしょう。
本件に代表されるような、ソフトウェアサプライチェーンにまつわる昨今の動向について、どのような課題があると捉えていますか。
ソフトウェアサプライチェーンに関する脅威については、セキュリティの分野でいま非常に問題視されています。特に、JavaScriptのライブラリなどを何らかの形で汚染してそれを使わせるという攻撃が発生するなど、JavaScript界隈で多くの問題が起こっています。汚染されたJavaScriptとは、いわばマルウェアです。そのマルウェアを、JavaScriptが動く環境に効率よく送り届けることができるという攻撃手法になっています。
世の中では、オープンソースのライブラリが非常にたくさん使われています。たとえばReact.jsというメジャーなJavaScriptライブラリは、数多くのライブラリが組み合わされています。そのライブラリには、さらに孫、ひ孫のライブラリがあります。そこまでいくともう名前を聞いたことがないようなものも多いわけですが、そのどれか1つでも汚染されると、ソフトウェア全体が汚染されてしまいます。
polyfill.ioは過去に売却したことは先ほどお話ししましたが、実はこれはわりとよくあるケースです。オープンソースのライブラリは、1人の個人（メンテナー）が10年以上メンテナンスし続けていることも少なくありません。そのため、「見返りもないし、称賛もされないし、お金ももらえないのに続けていくのはちょっと疲れたな」と開発者が感じることもあり得ます。そこに、「最近メンテナンスが止まっていますよね。私が協力しましょうか」といった形で協力者が突然現れる。親切にしてくれるので、そのうちにメンテナンスの権利を渡してしまう。するとその協力者が罠を仕込んでしまう、ということが起こっています。
あるいは、「大変有益なライブラリなので我が社が買います」として費用を提示され、売ってしまうこともよくあります。よくあっては困るのですが、実際に起こっています。polyfill.ioはまさに後者のように売却したケースです。
ソフトウェアサプライチェーンの脅威を理解するうえで参考となる事例はありますか。
2021年にはメルカリで、CI（※）環境で使うためのコードカバレッジツールといわれる、ソフトウェアの品質を高めるためのツールが汚染されたことにより不正アクセスを受け、一部の顧客情報が流出した事案が記憶に新しいところです 2。
（※）Continuous Integration（継続的インテグレーション）：コードを変更するたびに自動でテストを走らせ、不具合の混入を防ぐ開発プロセス
メルカリの事案ではツールが汚染されたわけですが、最近ではツールや製品ではなく、みんながよく使うライブラリが汚染される例が増えています。直近では、2026年3月にAxiosという有名なJavaScriptのライブラリが侵害されました。Axiosは、週に1億以上のダウンロードがあるとされる非常に人気があるライブラリで、JavaScriptを用いてWeb APIを簡単に利用するためのものです。これが侵害されると、たとえば多数のJavaScriptを組み合わせてソフトウェアを作るうえで汚染されたAxiosが動作してしまい、結果として、GitHubの認証情報が奪われるといった事態が起こり得ます。
近年では、JavaScriptの著名なライブラリが汚染される事例が立て続けに起こっていますが、原理的にはPythonをはじめ他の言語でも発生する可能性があります。ソフトウェアサプライチェーン攻撃には、感度高くアンテナを張っておくべきでしょう。
基本的な対策として、動向を地道にキャッチアップし続けることが必要だということですね。
また、最近の変化として、これまで「ソフトウェアは常に最新のものを使いましょう」と言われてきたところ、1年ほど前からは「できるだけ新しいものを使うべきだが、出来たてほやほやのものは危ない」と主張されはじめています。最新のソフトウェアは汚染されている可能性があるので、リリースされてから2〜3日置いてから使おうという話で、クールダウン期間とも呼ばれます。同様の趣旨で、WordPressも2026年6月に、各種プラグインやテーマのリリース後、自動アップデートが走る前に24時間のクールダウン期間を設けることを公表しています 3。
生成AIの進化を受けて、非エンジニアの方もアプリケーションを作成するようになってきています。IT・セキュリティ担当者の方たちには、そうした際のガードレールの一貫としても、ソフトウェアサプライチェーンの観点を持って対策してほしいと思います。
UNITISは、IT・セキュリティ担当者へ、実務家・専門家による解説や他社事例等を伝えるメディアです。セキュリティ・法律の専門家による実務解説や分析、第一線の実務家による事例・ノウハウをお届けします。
この記事をシェアする
最新情報をフォローする
