検索
特集

「脆弱性を見つけたらどうする?」 FeliCa問題が投げかけた情報開示のあるべき姿

FeliCaに関連した脆弱性を巡る報道は、脆弱性情報公開のプロセスやメディアの在り方など多くの問いを投げかけた。果たしてセキュリティ担当者は脆弱性とどう向き合うべきか。既存の公表プロセスの現状と課題、技術者の倫理を有識者が語った。

Share
Tweet
LINE
Hatena

 ソニーが開発した非接触ICカード技術「FeliCa」の脆弱(ぜいじゃく)性を巡る2025年8月の一連の報道が話題を集めた。概説すると、2017年以前に出荷されたFeliCaチップの暗号システムに脆弱性が存在し、これを悪用することでデータの改ざんが可能になるというものだ。

 脆弱性に関する報道は通常、その脆弱性の影響や深刻度の大きさに注目が集まる。しかしそれは今回の問題の本質ではない。FeliCaの脆弱性は影響が限定的で悪用も確認されていなかったものの、情報処理推進機構(IPA)の既存の脆弱性公開プロセスと並行して、一部メディアが先行報道したことで利用者の不安を増幅させた。

 このような問題を踏まえて、脆弱性情報の公表プロセスの現状と課題、脆弱性を発見・報告するセキュリティ技術者の倫理感やあるべき姿について、セキュアスカイ・テクノロジーの長谷川陽介氏(取締役CTO)に話を聞いた。

脆弱性情報公開ガイドラインの“限界” あるべき姿を問う

――まずは脆弱性の発見から報告、公開に至る一連の流れについて教えてください。


セキュアスカイ・テクノロジーの長谷川陽介氏(取締役CTO)(筆者撮影)

長谷川陽介氏(以下、長谷川氏): 脆弱性が公表されるまでの流れは必ずしも統一的に「こうあるべき」と決まっているわけではありません。歴史的に試行錯誤を重ねる中で、現状「ベストプラクティス」といえるような、誰もが不幸にならない最も良い形が出来上がってきています。

 具体的には、日本では20年以上前から「脆弱性が修正される前に公開され、悪用されることを防ぐ」ことを目的に、IPAやJPCERT/CCなどが「情報セキュリティ早期警戒パートナーシップガイドライン」という枠組みを定めています。

 それに従って報告者や発見者、あるいは影響を受ける利用者も含めて、より安全な状態が少しでも保てるようにしています。ただしこの枠組みはあくまで“ガイドライン”であり、法律のように全員に強制するものではないことは留意する必要があるでしょう。

 情報セキュリティ早期警戒パートナーシップガイドラインが成立した背景はインターネットの普及から10年ほどたった2003〜2004年頃にあります。Webアプリケーションや「Windows」の利用が急速に進み、ソフトウェアの脆弱性が社会問題になりつつありました。発見者がどこに報告すればいいか分からず、いきなり公開して悪用されるといったこともあり、その改善に向けてガイドラインが整備されたようです。

 情報セキュリティ早期警戒パートナーシップガイドラインに沿った脆弱性公表のフローはソフトウェアの脆弱性とWebアプリケーションの脆弱性に分かれます。まずソフトウェアの場合、脆弱性の発見者や開発者自身が窓口のIPAに報告をします。IPAは報告を受けてそれをJPCERTコーディネーションセンター(JPCERT/CC)にエスカレーションし、JPCERT/CCから製造元に連絡を入れます。

――JPCERT/CCが一連の流れに入る意義とは何でしょうか。

長谷川氏: JPCERT/CCの役割は調整です。ソフトウェアの脆弱性は単体で完結しないケースが往々にしてあります。例えば重要インフラで利用されていたり、Windowsのように世界的に普及していたり、ライブラリとして他のソフトウェアで使われていたり、国境を越えて利用されていたり、オープンソースの開発元が分からなかったりなどさまざまなパターンがあり、そうなると国内だけでなく海外の機関とも調整が必要になり、JPCERT/CCの介入が必須になります。

 このようなケースに備えてJPCERT/CCがIPAと製造元の間に早期に調整に入り、影響範囲や深刻度を調査し、報告者との間で細かな情報をやりとりします。そして修正が反映され、「脆弱性が修正されました」とまとめて公表されるわけです。

――特定のソフトウェアだけが先に修正を出した結果、他のソフトウェアに悪い影響が生じることもあります。JPCERT/CCが間に入ることでIPAや製造元の足並みをそろえて脆弱性を公表できるということですね。

長谷川氏: 一方でWebアプリケーションの場合はよりシンプルです。脆弱性の発見者がIPAに報告すると、IPAからWebサイトの運営者に連絡が行きます。これを運営者が修正をすれば、IPAを経由して発見者に「修正しました」と伝えられるだけで、世の中に公表されることはありません。この場合、JPCERT/CCは間に入りません。

 この他、古いバージョンで脆弱性が見つかった場合など、開発者自身が自社ソフトウェアの脆弱性を報告するパターンもあります。このときは同じフローでIPAやJPCERT/CCを通じて国内の脆弱性に関する情報と、その対策情報を公開するポータルサイト「JVN」(Japan Vulnerability Notes)で公表されます。なお、ガイドラインを通さずに発見者が直接製造元に脆弱性を報告するパターンもあるのですが、こちらについては後述します。

IPAも追い付けない脆弱性報告の現実――制度疲労と現場の声

――既存の脆弱性情報の公表プロセスの課題について長谷川さんの意見を聞かせてください。

長谷川氏: 情報セキュリティ早期警戒パートナーシップガイドラインに関連した課題としては、ガイドラインの周知不足がまず挙がると思います。脆弱性を探すエンジニアの間では広く知られている一方で、ソフトウェア開発者側では知らない人も多く、脆弱性報告の受け入れ体制が整っていないケースもあります。10年ほど前には、IPAからの連絡を営業電話と勘違いして「間に合ってます」と断った、という笑い話も聞いたことがありました。

 また、現行のガイドラインは脆弱性の危険度に応じた対応も含まれていますが、とはいえ軽微だから簡単に対応が終わるというものでもありません。自身の経験では、重大だから厳重に、軽微だから緩くと、危険度の違いによってフローが大きく変わることは少ないように思います。

 「危険な脆弱性だから厳重にハンドリングしましょう」あるいは「軽微なものだから途中で公開してもいいです」といった判断は、本来は報告者や間に入っている調整機関で水準を合わせるものだと思います。とはいえ、そういった調整そのものも非常に時間や負担のかかるものであり簡単ではないのだろうと思います。

 ただ、発見・報告者が想定している以上に実は重大な脆弱性だった、というケースはよくあります。あるいは、偶発的に技術への知見がない発見者がたまたま見つけてその重大度を判断できないケースもあります。ソフトウェア製品の脆弱性は、どの程度影響があるのか技術的に調査しないと判断できない場合があり、簡単には決められないとも思います。そういう意味では同一の扱いをせざるを得ないのかなと。

 個人的には脆弱性を発見する側だけでなく、ソフトウェアやWebアプリケーションを提供する側も一定の責任を持って自分たちで脆弱性をハンドリングできるようになってほしいとは思います。受け身ではなく体制を整えて報告を受け入れる責任がある、ということです。

――一方で、大きな問題がないのにガイドライン通りのフローで報告したために脆弱性情報の公開が遅れる、あるいは公開されず埋もれてしまうことも多いかと思います。さらにIPAが取り扱う脆弱性の件数が多過ぎて手が回っていないという話も聞きます。

長谷川氏: ガイドライン運用におけるIPA側のリソース不足は深刻な問題です。IPAには年間数百件の脆弱性報告が来ています。その結果、本来ガイドラインで扱うべきものを取りこぼしていることもあるのではないかと感じます。

 あとこれはガイドラインの問題というよりは、脆弱性公表プロセスの構造的な問題なのですが、発見者の利益が確保されないのは20年前から変わっていませんね。

――発見者の善意に頼っている部分があると。

長谷川氏: 国が主導するバグバウンティ制度があるわけでもないので、発見者に「ガイドラインに沿って報告しろ」と強制するのは、報告側からしてみると疲れる一方で、金銭的にも何ら得るものがない状態になりがちです。

――発見者のモチベーションはどこにあるのでしょうか。

長谷川氏: 人によるとは思います。脆弱性を見つけたから淡々と報告している人もいれば、JVNのWebサイトに名前付きで掲載されるのを狙って報告する人もいます。

 ただ今はMicrosoftやGoogleなど主要なソフトウェア開発ベンダーは独自のバグバウンティプログラムを運用していたり、報告用の窓口を持っていたりするため、スピード感を重視するという意味でも必ずしもIPAを経由して報告する必要はなくなっています。

 使い分けとしては脆弱性を見つけてしまったがどうすればいいのか分からなかったり、影響範囲が広くて一人では対処できなかったり、特定のベンダーに報告しても意味がなかったりするときには、IPAに報告するといいのかなと思います。

ガイドラインは補助にすぎない 脆弱性探しで本当に必要な心構え

――重要なのは「脆弱性の悪用を防ぐための適切な情報公開」であり、情報セキュリティ早期警戒パートナーシップガイドラインを順守することに固執してはいけないということですね。

長谷川氏: ガイドラインはあくまでガイドラインで、法律ではありません。そのためガイドラインを破ったということを理由に非難されるのは間違っていると思います。ただし法律についても、それを守ること自体をゴールにしてほしくないです。法律が守ろうとしているのは、利用者に被害が出ないことや金銭的損害が出ないことです。法律を守ることだけを目標にすると「違法でなければやってよい」という解釈につながりかねません。

 そういった意味で脆弱性を探す人たちの指標となるのが倫理だと思っています。関係者への影響や最善の方法を個別に考え、ガイドラインに従うだけでなく自分たちで判断して“責任感を持って”適切な対応を選ぶ。倫理というのは、法律だけでは解決できないことを考える軸として存在します。法律を守るだけでなく、迷惑を掛けないという倫理感に基づいて行動することで、結果的に法律も守られることになります。

 逆にいうと、脆弱性が悪用される可能性を伝えることに価値はありますが、対応策がない状態で情報だけ公開するのは非難されても仕方がないと思います。脆弱性情報と対応策のセットで出ることで初めて情報として価値が生まれるので。

 自分の行動に責任を持つことで、誰にとって価値があるかを考え、ルールを適切に守るかどうかを判断できる。脆弱性を探す人、脆弱性情報を取り扱う人にはそれを意識してほしいと思います。

――本日はありがとうございました。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る