脆弱性開示ポリシー(VDP)と受付窓口の作り方。報告を受け取る側の体制を最小構成から整える

自社の製品やサービスに脆弱性が見つかったとき、それを最初に知るのは社内とは限りません。外部の研究者、利用企業の情報システム担当、取引先の開発者が先に気づくことは珍しくなく、そのとき相手が探すのは「どこへ知らせればよいか」という一点です。この記事は、報告を受け取る側の立場から、脆弱性開示ポリシー(VDP)と受付窓口をどう設計し、届いた報告をどう処理するかを整理します。

まず、報告がどの経路で届くかを整理します。経路ごとに、組織が事前に用意しておくものと、応答時計が動き出す起点が違います。

最後の行だけは、他と性質が違います。窓口がないか機能していないときに残る経路であり、修正前に情報が広まるため、対応の自由度がもっとも低くなります。窓口づくりの実利は、この行に落ちる案件を減らすところにあります。

報告を受け取る窓口がないと何が起きるか#

脆弱性を見つけた側の行動を、順を追って考えます。発見者はまず報告先を探します。製品ページ、サポートページ、会社概要のいずれにもセキュリティ用の連絡先がなければ、次に一般の問い合わせフォームを試します。フォームには文字数制限があり、添付ファイルは送れず、返ってくるのは自動返信だけということが起こります。数週間待って音沙汰がなければ、発見者は「この組織は直さない」と判断します。そこから先は、公開の場での指摘か、放置かのどちらかです。

CISAがBOD 20-01の背景として整理した3つのつまずきは、この流れをそのまま言語化しています。報告の方法が分からないこと、脆弱性が修正されているという確信が持てないこと、法的措置を恐れることの3点です。同指令は、報告先が明確でないと、発見者は自分の人脈をたどったり、担当者の個人的な連絡先をインターネット上で探したりすることになり、手間がかかりすぎると感じれば報告する価値がないと判断しうる、と述べています。また、応答がないか、返答が役に立たないと受け取られた場合、発見者は修正を促し利用者を守るために調整を経ない公開に踏み切ることがあり、以後もその方法を既定にしてしまうかもしれない、とも書いています。

CISAのBinding Operational Directive 20-01(2020年9月2日)は、脆弱性開示ポリシーが定義されていない場合に報告者が直面する状況として、報告方法が判断できないこと、脆弱性が修正されているという確信が持てないこと、法的措置を恐れることの3点を挙げています。あわせて、報告者または脆弱性情報を保持する者は、事前通知なしを含めていつでも情報を開示または公表できるとし、調整を経ない開示は組織が対処する前に悪用を招きうると述べています。脆弱性開示ポリシーの利点は、調整された開示を促すことで、公に知られる前に修正する時間を確保し、組織と一般利用者のリスクを減らす点にあるとしています。

IPAが2026年3月31日に公開した「製品開発者向けガイド」も、同じ因果を明示しています。第三者からの脆弱性報告を受け付ける窓口を設置してそれを分かりやすく公開しないと、第三者は脆弱性を発見しても報告できず、脆弱性が放置された結果として攻撃者に悪用されてしまうかもしれない、という記述です。窓口の設置は、悪意ある通報を呼び込む行為ではなく、すでに存在する脆弱性の情報が自社に到達する経路を作る行為だ、と読むと位置づけがはっきりします。

同ガイドは、窓口について現実的な条件も添えています。

• 受付窓口は脆弱性情報専用である必要はないが、脆弱性情報を受け付けていることが分かるように明示する
• 報告の品質を担保するため、ガイドラインや報告用フォーマットを示して最低限盛り込むべき情報を発見者へ周知する
• 一般的な問い合わせ窓口へ脆弱性情報が報告される場合もあるため、その場合の対応を定めて社内へ周知しておく

専用の組織を先に作らなくても始められる、という設計になっています。

日本の枠組みでの受付と調整の役割分担#

日本には、脆弱性関連情報を流通させるための公的な枠組みがあります。経済産業省は、「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」(平成29年経済産業省告示第19号)を制定しており、IPAの届出受付ページはこの告示の最終改正を令和6年経済産業省告示第93号と記載しています。この告示を踏まえて、IPA、JPCERT/CC、JEITA、SAJ、JISA、JNSAが「情報セキュリティ早期警戒パートナーシップガイドライン」を策定しています。IPAのガイドラインのページによれば、最新版は2024年版で、2024年6月18日に公開されました。

役割分担は次のとおりです。

この表はソフトウェア製品の届出をたどった場合の流れです。ウェブアプリケーションの届出は経路が別で、IPAの取扱いプロセスは、IPAがウェブサイト運営者の連絡先を調査して脆弱性関連情報を連絡し、その際に届出のウェブサイトが判別可能な情報は公表しないとしています。個別の案件がJVNで公表される形ではなく、IPAが届出受付業務に係る統計情報を公表する形です。自社がウェブサービスの運営者である場合は、JPCERT/CCではなくIPAから連絡が来る前提で窓口を用意します。

JPCERT/CCは脆弱性情報ハンドリングを、公表前の脆弱性関連情報を必要に応じて公開することで、悪用または障害の危険性を最小限に食い止めるプロセスと説明しています。同センターは米国CERT/CCなど海外の機関とも連携し、海外で報告された脆弱性について国内ベンダを特定して公表スケジュールを調整する役割も担っています。ここで繰り返し強調されているのが公表日一致の原則です。関係者間で調整した一般公表日時を待たずに単独で公表することは、他社の製品利用者を危険にさらす可能性がある、という考え方です。

経済産業省は2025年9月9日、IPA、JPCERT/CC、国家サイバー統括室と連名で「国内における脆弱性関連情報を取り扱う全ての皆様へ」を公表しました。脆弱性を発見した者にはIPAへの届出と、正当な理由がない限り第三者へ開示しないことを求め、正当な理由により開示が必要な場合も事前にIPAへ相談するよう依頼しています。製品開発者やウェブサイト運営者にも責任ある情報開示と関係者との協調を求め、報道機関その他産業界に対しては、公表前の脆弱性関連情報は慎重な取扱いが必要であるとして、報道やSNSでの発信を通じてむやみに第三者へ開示することを控えるよう要請しています。あわせて、令和7年5月16日のサイバー対処能力強化法の成立に伴い、本制度の施行以降は脆弱性対応の強化が図られるとして、脆弱性関連情報取扱いの仕組みについても研究会での議論を通じて必要な見直しを検討する予定だと記載しています。

この枠組みは、経営層が押さえるべき2点を含んでいます。第1に、参加は推奨であって強制ではありません。経済産業省の文書は一貫して「お願い」という表現を使い、ガイドラインは関係者に推奨する行為をとりまとめたものと位置づけられています。日本の民間企業一般に対して、脆弱性開示ポリシーの策定や受付窓口の設置を直接義務づける法令は、執筆時点では確認できていません。第2に、制度は動いている最中です。経済産業省は、サイバー対処能力強化法の成立を踏まえて仕組みの見直しを検討する予定だと明記しており、この点は継続して確認する対象になります。

なお届出の規模感は公開されています。IPAが2026年7月16日に公表した2026年第2四半期の届出状況によると、この四半期の届出はソフトウェア製品182件、ウェブサイト65件の合計247件で、2004年7月8日の受付開始からの累計は20,315件です。同四半期にJVNで公表されたソフトウェア製品の脆弱性は54件、累計3,236件で、そのうち11件は製品開発者自身による自社製品の届出でした。

製品開発者リストに登録しておく意味#

パートナーシップの経路で報告が来る場合、連絡してくるのはJPCERT/CCです。ここで問題になるのが、JPCERT/CCが自社の窓口をどうやって知るか、という点です。同センターは製品開発者リストを維持しており、登録した開発者には、影響を受ける可能性のある脆弱性情報が通知されます。

IPAの製品開発者向けガイドは、この登録を明示的に勧めています。第三者がパートナーシップへ報告した場合、製品開発者への脆弱性情報の報告はJPCERT/CCから来ることになり、直接の報告よりも時間を要するため、開発者は脆弱性情報を迅速に入手できるようJPCERT/CCの製品開発者リストへあらかじめ登録しておくように、という記述です。登録していない場合、JPCERT/CCは公開情報から連絡先を探すところから始めることになり、その分だけ自社が脆弱性を知る時期が遅れます。

登録には2種類あります。JPCERT/CCの説明では、受け取る脆弱性情報に特に制限がない一般登録と、受け取る情報が公開前かつ自社製品に固有で他の製品開発者との調整が生じないものに原則として限定される個別登録です。一般登録には申請から説明会を経る手順があり、公開鍵などの情報も必要になります。まずは自社の体制に見合う方を選び、担当者が交代しても連絡が途切れないように、個人名ではなく役割単位のメールアドレスを登録するのが実務的です。

JPCERT/CCは、脆弱性情報が発生した際に影響を受ける可能性のある製品開発者を特定するために製品開発者リストを維持しており、登録した製品開発者には自社製品に影響する脆弱性情報が通知されると説明しています。登録の種類は、受け取る脆弱性情報に特に制限がない一般登録と、受け取る情報が一般公開前のもので登録者が開発した製品に固有かつ他の製品開発者との調整作業が生じないものに原則として限定される個別登録の2つです。登録にあたっては、脆弱性情報の取扱いへの協力と登録の意思、窓口担当者と責任者の情報をJPCERT/CCへ連絡することが求められます。

連絡が取れない製品開発者の扱い#

窓口を用意していない場合に何が起きるかは、制度側の手続きとして具体化されています。IPAは、調整機関から連絡が取れない製品開発者を連絡不能開発者と呼び、連絡の糸口を得るために当該製品開発者名等を公表して情報提供を求めています。製品開発者名を公表してから3か月が経過しても応答が得られない場合は、対象製品の具体的な名称とバージョンを含む製品情報を公表します。それでも応答がない場合は情報提供の期限を追記し、期限までに応答がなければ、脆弱性情報の公表に向けて、パートナーシップガイドラインに定められた条件を満たしているかを公表判定委員会が判定します。判定を踏まえてIPAが公表すると判定した脆弱性情報は、JVNに公表されます。

IPAが2026年7月16日に公表した「ソフトウェア等の脆弱性関連情報に関する届出状況[2026年第2四半期(4月～6月)]」によると、2026年第2四半期の届出件数はソフトウェア製品182件、ウェブサイト65件の合計247件で、2004年7月8日の受付開始からの累計は20,315件です。同四半期にJVN公表したソフトウェア製品の件数は54件(累計3,236件)で、うち11件は製品開発者による自社製品の脆弱性の届出でした。届出を受理してからJVN公表までの日数が45日以内のものは16件(30%)でした。連絡不能開発者としてこの四半期に新たに製品開発者名を公表したものはなく、四半期末時点の連絡不能開発者の累計公表件数は251件です。公表判定委員会は、法律、サイバーセキュリティ、当該ソフトウェア製品分野の専門的な知識や経験を有し、当該案件と利害関係のない者で構成されるとされています。

この手続きの意味は、報告に応答しなくても制度側の手続きが止まらない、という点にあります。連絡が取れなければ、まず社名が公表され、次に製品名とバージョンが公表され、それでも応答がなければ脆弱性情報を公表するかどうかが公表判定委員会の判定に移ります。IPAの調整不能案件公表判定プロセスによれば、判定の結論は公表する場合と公表しない場合があり、調整可能と判定される場合もあります。公表すると判定されれば、対策の準備も利用者への案内も間に合っていない状態でJVNに出ることになります。受付窓口の整備は、この順序で進む手続きの入口を自社側で押さえておく作業だ、と捉えると優先順位が上がります。

累計251件という数字は、20年以上の運用の累計としては小さく見えるかもしれません。ただしここに載るのは、連絡先が見つからない組織だけではありません。IPAの届出関連FAQは、電子メールや郵便、電話、FAX等のいずれの手段で製品開発者に連絡を試みても一定期間にわたりまったく応答がない場合に、連絡が取れないと判断すると説明しています。連絡先が分かっていても応答が返らない組織が含まれる、ということです。合併や事業譲渡でサポート主体が変わった製品、サポートを終了したまま利用が続いている組込み機器、窓口はあるが読む担当がいない状態などが典型で、自社が該当しないと言い切るには、製品ごとに現在の連絡窓口が誰なのかを棚卸ししてみる必要があります。

ISO/IEC 29147と30111が分担していること#

脆弱性対応の国際規格は2本立てで、担当する範囲が分かれています。ISOの公式ページで確認できる範囲を整理します。

ISO/IEC 29147:2018のISO公式ページは、この規格が製品とサービスの脆弱性の開示についてベンダに対する要求事項と推奨事項を示すものだと説明し、提供する内容として、潜在的な脆弱性についての報告を受け取ることに関する指針、脆弱性の是正情報を開示することに関する指針、脆弱性開示に固有の用語と定義、脆弱性開示の概念の概観、脆弱性開示の技法とポリシー上の考慮事項、技法とポリシー(附属書A)と連絡文(附属書B)の例を挙げています。そして、脆弱性報告の受け取りから開示までの間に行われる関連活動はISO/IEC 30111に記述されている、と明記しています。同ページの一般情報では、状態がPublished、発行日が2018年10月、版が第2版、ページ数が32ページ、段階が90.92と表示され、2024年に最後の見直しと確認が行われ現行版として維持されている旨が記載されています。

ISO/IEC 30111:2019のページは、この規格を、製品やサービスで報告された潜在的な脆弱性をどのように処理し是正するかについての要求事項と推奨事項を示すものだと説明し、脆弱性の取扱いに関わるベンダに適用されるとしています。発行は2019年10月、第2版で13ページ、2025年に見直されて現行版として維持されています。

この分担は、社内の文書構成にそのまま写せます。外向けに公開する脆弱性開示ポリシーが29147の守備範囲、社内の手順書とチケット運用が30111の守備範囲です。両者を1本の文書に混ぜると、外部に見せる必要のない内部の判断基準まで公開文書に書き込むことになり、更新のたびに公開文書を触ることになります。外向けの約束と内向けの手順を分けておくと、手順の改善が公開文書の改訂を伴わずに進みます。

なお、両規格ともISOの該当ページには段階90.92(見直し予定)と表示されています。改訂の内容や時期は執筆時点で確認できていないため、参照する際は最新の状態をISOのページで確かめてください。

security.txtで連絡経路を機械可読にする#

VDPと窓口を用意しても、探し当ててもらえなければ意味がありません。ここで使えるのがRFC 9116のsecurity.txtです。2022年4月にIETFから発行されたInformational文書で、脆弱性が研究者によって発見されたときに適切な報告経路が欠けていることが多く、その結果として脆弱性が報告されないままになりうる、という問題意識から、組織が自らの脆弱性開示の実務を記述するための機械可読な形式を定めています。

主なフィールドは次のとおりです。

設置場所には決まりがあります。RFC 9116は、ウェブベースのサービスについて、組織はsecurity.txtファイルを/.well-known/パスの下に置かなければならないとしており、例としてhttps://example.com/.well-known/security.txtを挙げています。旧来の互換性のためにトップレベルのパスに置くかリダイレクトすることもできますが、両方に存在する場合は/.well-known/の下のものを使わなければならない、とされています。ファイルはhttpsスキームで取得でき、Content-Typeはtext/plainで文字セットはutf-8であることも定められています。

Expiresが必須である理由は、古い情報が残り続けることを避けるためです。RFC 9116は、この値を1年より先にしないことを推奨しています。ここに実務上の含意があります。security.txtを置くという判断は、少なくとも1年に1回はその内容を見直すという運用の約束とセットになります。書きっぱなしにすると期限切れのファイルが公開され続け、報告者から見れば管理されていない窓口に映ります。

RFC 9116「A File Format to Aid in Security Vulnerability Disclosure」(2022年4月、Informational)は、Contactフィールドについて、研究者がセキュリティ脆弱性を報告するために使うべき方法を示すもので、security.txtファイルに常に存在しなければならないと規定しています。値がウェブURIの場合はhttps://で始まらなければならず、複数記載する場合は優先度の高いものから並べるべきだとしています。Expiresフィールドは、そのファイルに含まれるデータが古いとみなされ使用されるべきでなくなる日時を示すもので、常に存在しなければならず2回以上現れてはならないとし、値は将来1年未満にすることが推奨されています。設置場所については、ウェブベースのサービスでは/.well-known/パスの下に置かなければならず、両方の場所に存在する場合は/.well-known/パスのものを使わなければならないとしています。第5.5節では、security.txtの有無が、そのドメインや組織の製品とサービスに対するセキュリティテストの許可または不許可を与えるものと研究者が仮定すべきではないとし、そのような許可はその組織の脆弱性開示ポリシーで示されうると述べています。

第5.5節の但し書きは、VDPとsecurity.txtの関係をはっきりさせます。security.txtは連絡先の掲示板であって、許可証ではありません。何をしてよいかという範囲の定義は、Policyフィールドが指すVDPの側に書きます。逆に言えば、VDPを書かずにsecurity.txtだけ置くと、報告者は許可の範囲が分からないまま判断することになり、双方にとって曖昧な状態が残ります。

米国連邦機関に課されたVDP指令から借りられる設計#

VDPに何を書くかを設計するとき、参照先として使いやすいのがCISAのBOD 20-01です。ここで前提を明確にします。この指令は米国の連邦行政機関を対象とした強制的な指示であり、法律で定義された国家安全保障システムや国防総省と情報機関の一部システムには適用されません。日本の民間企業に対する義務ではありません。それでも、公的機関がVDPの必須要素として何を挙げたかは、自社ポリシーの項目立てを考える材料になります。

同指令が必須としている記載項目は次のとおりです。

• 対象となるシステムの範囲
• 許可されるテストの種類と、明示的に許可されないテストの種類。あわせて、発見した個人識別情報を第三者へ開示することを禁じる記述
• 報告の提出方法。報告先(ウェブフォームやメールアドレス)、脆弱性の発見と分析に必要な情報の要求、報告者が匿名で報告できるという明確な記述を含む
• ポリシーに従う善意の努力だと機関が結論づけたセキュリティ研究活動について、法的措置を推奨も追行もせず、その活動を許可されたものとみなすという約束
• 報告を受領した旨をいつ報告者へ伝えるかという期待値の設定と、是正の過程で取っている手順について可能な限り透明であるという誓約
• 発行日

してはならないことも列挙されています。個人識別情報の提出を必須にすること、テストを審査済みの登録者や米国市民だけに限定すること、合理的に期間を限った応答猶予の要請を超えて報告者の開示能力を制限しようとすること、の3点です。

BOD 20-01は、拘束的運用指令が連邦の行政機関の省庁に対する強制的な指示であること、これらの指令が法律で定義された国家安全保障システムや、国防総省と情報機関が運用する一定のシステムには適用されないことを冒頭で述べています。要求事項としては、発行から30暦日以内に.govレジストラでセキュリティ連絡先とOrganizationフィールドを更新すること、180暦日以内に機関の主要な.govウェブサイトの/vulnerability-disclosure-policyパスにVDPを公開すること、270暦日以内とその後90暦日ごとに対象範囲を少なくとも1つのインターネット到達可能なシステムまたはサービス分ずつ拡大すること、2年後にはすべてのインターネット到達可能なシステムまたはサービスを対象にすることを定めています。加えて、180暦日以内に取扱手順を整備し、報告者への受領確認、初期評価、報告者への結果通知を含む脆弱性の解決について目標期限を設定して追跡することを求めています。バグバウンティについては、VDPと類似するが別のものだと位置づけ、この指令は機関にバグバウンティプログラムの設置を求めるものではないと明記しています。

CISAが公開している脆弱性開示ポリシーのテンプレートは、Authorizationの節について、法律用語や必要以上に威圧的な表現を避け、研究者にできる限り歓迎的であるよう設計されているとして、その文言をそのまま使うことを強く推奨しています。文面は、研究の過程でこのポリシーに従う善意の努力をした場合、その研究は許可されたものとみなし、問題を迅速に理解して解決するために協力し、機関はその研究に関連して法的措置を推奨も追行もしない、というものです。さらに、そのポリシーに沿って行われた活動について第三者から法的措置が開始された場合は、この許可の存在を明らかにする、と続きます。応答時間の例としては、連絡先を共有した報告者に対して3営業日以内に報告の受領を確認すると書かれています。

受け取ってから公表するまでの社内プロセス#

窓口に報告が届いた後の流れは、内部プロセスの規格であるISO/IEC 30111が扱う領域です。実務の単位に落とすと、次の段階に分かれます。

IPAの製品開発者向けガイドは、報告を受けた後の連絡についても具体的です。窓口に報告があった場合は事前に決めた報告ルートに従って適切な部門へ連絡し、脆弱性情報を受領した旨や対応状況を報告者へ連絡するよう求めています。また、発見者がどのような立場の人か(セキュリティ研究者、製品の利用顧客、関係するSI事業者など)を確認して関係部門へ参考情報として展開すると、報告内容が前提とする状況や再現に関する信頼性を判断しやすくなる、とも述べています。

再現の段階には、社内向けの注意が伴います。再現の試行は、自社が管理する検証環境で行います。顧客の本番環境や、自社が管理していないシステムに対して確認を行うことは、たとえ善意であっても許可の範囲を超えます。報告に添えられた検証用のコードやリクエストを扱う際も、実行するのは隔離された環境に限り、その扱いを手順書に書いておきます。関連する法令への注意も同じで、対象が自社の管理下にあるかどうかを最初に確かめる運用にします。

修正と公表の段階では、配布前のテストを省かないことが繰り返し求められています。IPAのガイドは、更新プログラムの不具合が原因でソフトウェアが適用されたサービス等に障害がもたらされる事例が発生しているとして、配布前の不具合を確認するためのテストは必ず実施するよう述べています。修正が間に合わないときは回避策や代替策を先に提供する選択肢があり、それも展開できない場合には利用者へ使用停止を促すことの検討も挙げられています。

初回応答と状況更新のSLAをどこに置くか#

外部に約束する時間の設計は、守れる範囲から始めるのが基本です。守れない期限を書くと、期限切れそのものが不信の材料になります。参照できる公開資料の水準を並べます。

最後の行は約束ではなく実績です。国内の制度経由で処理された案件のうち、受理からJVN公表まで45日以内に至ったものが3割にとどまる、という数字は、脆弱性の修正と調整に相応の時間がかかることを示しています。自社のポリシーで公表までの期限を宣言する場合は、この現実と照らして無理のない値を選びます。

実務的には、3段階に分けて書くと運用しやすくなります。第1に、受領の確認は自動応答ではなく人が確認したことを示す形で、営業日単位の短い期限を置きます。第2に、有効性の判定結果を伝える期限を置きます。無効と判断した場合も理由を添えて返すところまでを含めます。第3に、修正の見込みと状況更新の間隔を約束します。間隔を決めておくと、進捗がないときでも「今は何も進んでいない」と伝える運用が成り立ち、沈黙が生む誤解を防げます。

FIRSTが公開しているPSIRT Services Frameworkのバージョン1.1(2020年春)は、受付の準備としてもう少し細かい項目を挙げています。

• 報告の提出方法として望ましい形をあらかじめ定める
• 連絡先を製品ドキュメント、自社ウェブページ、検索エンジンのインデックス、主要なCSIRTとPSIRTの一覧、CVE採番機関などへ周知する
• psirt@やincidents@、security@といったPSIRTに関連する一般的な語を自社ドメインで確保しておく
• 報告には脆弱性が観測された運用環境や製品についての機微な情報が含まれることが多いため、S/MIMEやPGPで保護したメールやHTTPS対応のウェブフォームのような暗号化された提出手段を用意する
• 外部の発見者への応答時間を社内のSLAとして定める

セーフハーバー条項と許可の範囲の明文化#

VDPで報告者側がもっとも気にする部分が、法的な扱いです。日本法の文脈で押さえておきたいのが、不正アクセス行為の禁止等に関する法律(平成十一年法律第百二十八号)の構造です。同法第三条は「何人も、不正アクセス行為をしてはならない。」と定め、第十一条は第三条に違反した者を三年以下の拘禁刑または百万円以下の罰金に処すると定めています。

そのうえで、何が不正アクセス行為にあたるかは第二条第四項が定義しています。同項第二号は、アクセス制御機能を有する特定電子計算機に電気通信回線を通じて、そのアクセス制御機能による特定利用の制限を免れることができる情報または指令を入力して当該特定電子計算機を作動させ、制限されている特定利用をし得る状態にさせる行為を挙げたうえで、括弧書きで、当該アクセス制御機能を付加したアクセス管理者がするものおよび当該アクセス管理者の承諾を得てするものを除く、としています。

e-Gov法令検索で参照できる不正アクセス行為の禁止等に関する法律(平成十一年法律第百二十八号)は、第二条第一項でアクセス管理者を、電気通信回線に接続している電子計算機(特定電子計算機)の利用につき当該特定電子計算機の動作を管理する者と定義しています。第二条第四項第二号は、アクセス制御機能による特定利用の制限を免れることができる情報または指令を入力して制限されている特定利用をし得る状態にさせる行為を不正アクセス行為として挙げつつ、括弧書きで「当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く」と規定しています。第三条は「何人も、不正アクセス行為をしてはならない。」と定め、第十一条は第三条の規定に違反した者を三年以下の拘禁刑又は百万円以下の罰金に処すると定めています。

条文が承諾の有無を書き分けている以上、自社のシステムについて誰にどこまでの調査を認めるかを文書で明らかにしておくことには、実務上の意味があります。ここで整理しておく要素は次のものです。

• 対象となるドメイン、IPアドレス、製品名とバージョンを列挙する。列挙しにくい場合は、対象外を列挙する方式に切り替える
• 許可しない手法を明示する。サービス妨害を狙う負荷試験、物理的な侵入、従業員へのソーシャルエンジニアリングは典型的な除外対象になる
• 脆弱性の存在を確認するのに必要な限度を超えて掘り進まないこと、データの取得や改変、他システムへの横展開をしないことを求める
• 個人情報や機微な情報に触れた時点でテストを止め、直ちに連絡し、それを第三者へ開示しないよう求める
• 第三者が提供するクラウドサービスやSaaSを対象に含める場合は、そのベンダから明示的な許可が得られているかを事前に確認する
• 報告を受けたときに自社が取る対応と、報告者に対して法的措置を推奨も追行もしない範囲を書く

6番目の項目は見落とされがちです。CISAのテンプレートも、対象へ追加する前に、そのシステムやサービスに対するセキュリティテストを許可できる立場にあるかを確認するよう求め、マネージドサービスやSaaSを使っている場合は契約や公開ポリシーでベンダが明示的にテストを許可しているかを確かめ、許可が得られない場合はそのシステムを対象に含めてはならないとしています。自社の名前で許可を出せる範囲は、自社が管理権限を持つ範囲までです。

報奨金を出す場合と出さない場合の設計#

報奨金の有無は、VDPの必須要素ではありません。BOD 20-01は、VDPはバグバウンティと似ているが別のものだと位置づけ、バグバウンティでは組織が自社のシステムや製品における一定種類の脆弱性について、有効で影響のある発見に対して支払いを行うと説明したうえで、この指令は機関にバグバウンティプログラムの設置を求めるものではないと明記しています。金銭的な報酬は行動を促し、普段は脆弱性を探さない人を引き寄せる可能性がある一方で、報告数の増加や低品質な提出の増加をもたらすこともある、とも書かれています。

出さないと決めた場合は、そのことをポリシーに書きます。CISAのテンプレートは、報告者が支払いを期待していないこと、提出によって将来の支払い請求を明示的に放棄することを認識する旨の記述を、ポリシーやウェブフォームの送信ボタン付近に入れることを検討するよう挙げています。書いておかないと、報告のたびに個別に説明する手間が発生します。

出すと決めた場合に決めておく項目は次のとおりです。

• 対象となるシステムと脆弱性の種類。範囲外の報告に支払わないことを明示する
• 金額の決定方法。深刻度や影響の区分ごとに幅を示す
• 支払いの条件と時期。重複報告の扱い、最初に報告した者の判定方法を含む
• 支払い手段。海外送金や本人確認、社内の経理と税務の手続きを事前に確認しておく
• 報奨金の対象外だが有用な報告への扱い。謝辞の掲載や記念品などの代替手段を用意する

金銭が絡むと、支払いを条件に情報を出さないという申し出が届くことがあります。OWASPのVulnerability Disclosure Cheat Sheetは、この種の要求に対して、仲介型のバグバウンティプラットフォームの利用を提案することで、正当な報告と恐喝的な要求を切り分ける方法を挙げています。同時に、組織の側が報告者へ法的な脅しをかけたり、許可されていないテストを理由に威圧したりしないことも求めています。

謝辞の掲載は、費用をかけずに報告者へ報いる手段として機能します。RFC 9116のAcknowledgmentsフィールドは、報告した研究者が認知されるページへのリンクを示すものと定義されており、そのページは脆弱性を報告して是正に協力した研究者を掲載するものだとされています。あわせて、将来の攻撃を防ぐために、公開する脆弱性情報は限定するよう注意が添えられています。日付と報告者名と脆弱性の種類程度にとどめるのが無難です。

CVE採番を自社で行うという選択肢#

自社製品の脆弱性にCVE IDを付ける立場になることを、CVE ProgramではCNA(CVE Numbering Authority)と呼びます。CVE Programの説明によれば、CNAはベンダ、研究者、オープンソース、CERT、ホスティングサービス、バグバウンティ提供者、コンソーシアムなどの組織で、CVE Programから権限を与えられ、それぞれ固有の対象範囲の中で脆弱性にCVE IDを割り当ててCVEレコードを公開します。執筆時点の同ページの表示では、43か国と国別の所属がない1件から、544のCNA(541のCNAと3のCNA-LR)が参加しています。

参加の条件は、金銭的な負担よりも体制の整備に寄っています。CVE Programのパートナー情報のページは、費用について、金銭的な手数料はなく、CNAは自らの利益のために自らの時間を提供するもので、署名する契約はないと記載しています。そのうえで要件として、公開された脆弱性開示ポリシーを持つこと、新しい脆弱性の開示のための公開された情報源を持つこと、CVE ProgramのTerms of Useに同意することを挙げています。

ここが本題との接点です。CNAになるための最初の要件が公開されたVDPである、という並びは、脆弱性開示ポリシーが単独の文書ではなく、対外的な脆弱性対応の入口として扱われていることを示します。逆に言えば、VDPと窓口とアドバイザリの公開場所が揃っていれば、CNAへの参加は制度的な手続きの問題に近づきます。

日本の組織についても、CVE Programの公開データで確認できます。JPCERT/CCはRootとCNAの役割を持つ組織として登録されており、Rootとしての対象範囲は日本の組織、CNAとしての対象範囲は脆弱性調整の役割に関連する採番とされています。日本に所在する組織としては、機器や情報通信の製造業を中心に複数がCNAとして参加しています。自社が製品を出しており、脆弱性アドバイザリを継続的に発行しているなら、検討する価値のある選択肢です。

脆弱性開示ポリシーに書く項目のひな形#

ここまでの内容を、公開文書の目次の形にまとめます。すべてを最初から書く必要はなく、下の表の「最小」の列だけでも公開する価値があります。

対象外の報告の扱いを1行でも書いておくと、運用の負荷が下がります。設定の推奨事項に関する指摘、自動診断ツールの出力をそのまま貼っただけの報告、第三者サービス側の問題などが典型です。「これらは対象外として記録のみ行い、個別の返信はしない場合があります」と書いておけば、応答の約束が現実的な範囲に収まります。

最小構成で受付体制を立ち上げる手順#

専任のPSIRTを先に作らなくても、順序を守れば小規模な組織でも立ち上げられます。IPAの製品開発者向けガイドは、実施すべき対処を段階的に示していて、可能なところから実施できる構成にしている、と述べています。同ガイドの体制の項目では、レベル1をPSIRTを構築して維持し必要な機能を定義する段階、レベル2を製品セキュリティポリシーを策定して体制とプロセスを整備する段階、レベル3をそれらに加えて脆弱性対処計画の策定などを行う段階として区分しています。下の手順は、この段階的な考え方を受付窓口の立ち上げに絞って並べたものです。

報告者との関係を壊す対応の型#

うまくいかない対応にはいくつかの型があります。それぞれ、どういう機構で悪化するかを整理します。

第1に、報告を読んだまま返さないことです。報告者は自分の報告が届いたかどうかを確認できません。この状態が続くと、報告者は組織が対応しないと判断し、公開の場での指摘に切り替えることがあります。CISAが指令の背景で述べているとおり、報告者は事前通知なしを含めていつでも情報を公表できる立場にあります。受領の確認は、対応そのものより先に効く手当です。

第2に、報告者を威圧することです。許可のないテストだと指摘して法的措置をほのめかす、勤務先へ連絡する、といった対応は、その1件を止めるかもしれませんが、次からその組織へ報告する人がいなくなります。同じ脆弱性が別の誰かに見つかったとき、今度は報告ではなく悪用の形で表面化します。CISAは、政府機関が外部の研究者に対して防御的あるいは訴訟的だという評判を持っていることが、報告をためらわせる要因になっていると指摘しており、明確で温かみのある保証がなければ研究者は法的な報復を恐れて報告しないことを選びうるとしています。

第3に、窓口が一般の問い合わせフォームしかない状態です。この場合、報告は営業やサポートの受信箱に混ざり、脆弱性だと認識されないまま「ご意見ありがとうございました」で閉じられることがあります。文字数制限や添付不可の制約で、報告者が必要な情報を渡せないという物理的な問題も起きます。IPAのガイドが、窓口は脆弱性情報専用である必要はないが受け付けていることが分かるように明示すること、そして一般的な問い合わせ窓口へ報告された場合の対応を定めて社内へ周知することを求めているのは、この経路を塞がないためです。

第4に、修正だけして公表しないことです。利用者は自分が影響を受けていたことも、更新すべき理由も知りません。IPAのガイドは、脆弱性対策を作成してもその対策情報が適切に公表されない場合、製品の利用者が対策の必要性を認識できず、対策を適用しないと被害に遭う恐れがあり、その結果として製品や製品開発者への信頼低下につながりかねないと述べています。

第5に、公表日の合意を破ることです。調整の枠組みに入っている案件で、合意した日時より前に単独で公表すると、他社の製品利用者を危険にさらす可能性があります。JPCERT/CCは、国際的な案件で期限前に情報を公開した場合、海外機関から以後のハンドリングの対象外とされる措置が取られることもあると説明しています。合意した日付は、社内の広報計画より優先します。

前提と限界#

IPAの「情報セキュリティ早期警戒パートナーシップガイドライン」のページは、「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」(令和6年経済産業省告示第93号)にもとづくものとして、最新版の2024年版を2024年6月18日に公開したと記載しています。本体のほか、概要版(日本語版と英語版)、別冊として「ソフトウエア製品開発者による脆弱性対策情報の公表マニュアル」、CVSS v3の解説資料、ウェブサイト構築事業者向けガイド、ウェブサイト運営者向けガイド、セキュリティ担当者向けガイドが用意されています。届出から公表までの手順は「脆弱性関連情報の届出受付業務における取扱いプロセス」に、調整ができない場合の扱いは「調整不能案件公表判定プロセス」に整理されています。

法的な位置づけについて、もう一度だけ書き分けておきます。義務にあたるのは、米国の連邦行政機関に対するCISAのBOD 20-01の要求事項です。推奨にあたるのは、日本の情報セキュリティ早期警戒パートナーシップの枠組みで関係者に求められている対応、ISO/IECの規格が示す要求事項と推奨事項、RFC 9116が定める書式です。日本の民間企業が脆弱性開示ポリシーを持つかどうかは、執筆時点では各社の判断に委ねられています。持たない選択も制度上は可能ですが、その場合に報告がどの経路をたどるかは前節までに整理したとおりです。

自組織の脆弱性受付体制の点検リスト#

窓口の公開はリスクの増加ではなく到達性の確保#

脆弱性の受付窓口を公開すると攻撃を呼び込むのではないか、という懸念が出ることがあります。この懸念は、順序を取り違えています。窓口があってもなくても、脆弱性は存在しますし、外部から探す人もいます。違うのは、見つけた人が組織へ連絡できるかどうかだけです。窓口がなければ、その情報が自社へ届くかどうかは発見者の手間に委ねられ、届かないまま公開の場に出るか、悪用されるか、放置されるという結果になりえます。窓口の公開は、すでにある情報が自社へ到達する経路を1本増やす作業です。

もう一つの誤解は、体制を先に整えてから公開すべきだ、というものです。IPAのガイドが段階的な構成を採っているのは、この順序でつまずく組織が多いからだと読めます。連絡先を1本置き、受け取ったら誰へ回すかを決め、受領を返す文面を用意します。この3つが揃えば、最低限の受付は成立します。専任のPSIRT、報奨金、CNAへの参加は、届いた件数が判断材料になってから検討すれば足ります。順序を逆にすると、体制の設計に時間を取られている間、報告は届かないままです。

そして、書いたことは守れる範囲にとどめます。3営業日以内に受領を返すと書いたなら返し、状況を2週間ごとに更新すると書いたなら更新します。報告者から見て信用に足るのは、短い約束を確実に守っている組織であって、長い期限を掲げて沈黙する組織ではありません。脆弱性開示ポリシーは、対外的な宣言であると同時に、社内の運用に対する制約でもあります。その制約を引き受けられる水準から始めることが、結果として報告が届き続ける体制につながります。