機能 1.5.3 脆弱性をトラッキングするシステムのアップデート
PSIRTは、すべての製品の脆弱性に関する記録システムにアクセスでき、トラッキングと情報共有のためのシステムを構築?使用できる必要がある。知る必要性があるユーザは、これらの脆弱性情報へのアクセスおよび情報の更新ができる必要がある。
目的：セキュリティ上の欠陥を適切に記録して追跡することで、脆弱性がいつどこで対処されたかを組織が把握することができる。このシステムは、PSIRT、発見者、および問題解決に積極的に取り組むエンジニア間のコミュニケーションも可能にする
成果：システムを使用してセキュリティ上の脆弱性が適切にトラッキングされるため、欠陥に関する情報にアクセスする必要があるすべての関係者が、履歴、進捗状況、およびコメントを確認できる
サブ機能 1.5.3.1 脆弱性発見者への脆弱性トラッキングシステムの提供
すべてのセキュリティ上の欠陥をトラッキングする必要がある。システムは、進捗状況の更新またはトラッキングのために、組織内外の関係者から（最小特権モデルで）アクセス可能となるべきである。外部の発見者は、PSIRTに提出した報告書のステータスに関する適切なコミュニケーションを受けられる必要がある。
サブ機能 1.5.3.2 脆弱性トラッキングシステムにおけるセキュリティ脆弱性の収集、分類、ルーティング、優先順位付けのプロセスの提供
PSIRTは、組織のサービス提供に影響を与える脆弱性に取り組んでいる脆弱性発見者およびパートナーが、情報を共有するためのプライベートで安全な方法を持つようにする必要がある。
機能 1.5.4 情報の共有および公開
問題が解決された後、PSIRTは影響を受けたすべてのステークホルダと情報を共有すべきである。影響を受けるすべてのステークホルダは、セキュリティの脆弱性、その重大度と影響の内容、利用可能なリスクの可能性、および問題の解決方法や解決策が利用可能になるまでの緩和方法を理解する必要がある。
36
目的：報告され、改修された脆弱性に関する詳細を共有する。ステークホルダは、正式な修正が提供されるまで、リスクを抑えるための回避策または代替的な緩和策を受けることができるべきである
成果：ステークホルダには、脆弱性、その影響を受ける条件、修正方法について通知される。タイムリーな情報と更新情報を受け取ったステークホルダは、組織をポジティブに捉え、提供している製品を使用し続けるか、組織の将来の使用を拡大する可能性が高くなる
サブ機能 1.5.4.1 脆弱性の修正およびその取得方法を告知するために複数のコミュニケーション方法を提供する
異なるステークホルダは、脆弱性が一般に公開される際に、さまざまな相互作用/通信方法を好む。PSIRTは、伝統的なアドバイザリスタイルの更新に加えて、脆弱性に関するステークホルダの関与と意識を最大限に引き出すために、他の方法を使用するようにする必要がある。脆弱性が改修された後、PSIRTは修正を告知するために複数の異なる方法を使用する必要がある。
サブ機能 1.5.4.2 ステークホルダが脆弱性の改修に関する通信、プロセス、およびパフォーマンスに関するフィードバックを提供する方法を提供する
フィードバックは、今後のプロセスと対応を改善するのに役立つ。 PSIRTが強みとする分野を強調することができ、PSIRTがさらに発展し改善する必要がある分野での実績を継続する必要がある。
サービス 1.6 表彰と謝辞による報酬を発見者に与える
セキュリティ脆弱性が発見されると、その脆弱性が誰から報告されたものか示すことが期待される。発見者を信認することは、コミュニティ内での彼らの信頼性の確立に役立つ。また、脆弱性に関するPSIRTへの協力に対する感謝の意を表す。
目的：発見者は製品の脆弱性について責任をもって明らかにする努力により信認される。発見者は、これらの謝辞をもとに専門性の高いポートフォリオを構築し、組織に価値を示すための評判を高めることができる
37
成果：発見者と積極的に協力することで、製品のセキュリティが向上する。発見者を信認することは、内部の従業員への評判を高め、専門知識を示すうえで有益である
機能 1.6.1 謝辞の提供
脆弱性の発見をした人への謝辞は、脆弱性対応フローの中で重要な要素である。感謝の気持ちが少しでも表れれば、コミュニティ内の信頼と尊敬が得られ、組織はセキュリティ上の懸念に対応していることがわかる。
目的：製品の脆弱性について責任を持って明らかにする努力により、発見者は信認される。発見者はこれらの謝辞を基づいて、彼らの評判を高めることができ、専門性の高いポートフォリオを構築することができる
成果：発見者との積極的な協力により、製品のセキュリティが向上する。発見者への謝辞は、発見者が評判を築くのに有益であり、発見者が将来の脆弱性レポートをPSIRTに送ることを奨励する
サブ機能 1.6.1.1 脆弱性トラッキングシステム/リリースノートにおいてセキュリティ脆弱性発見者への謝辞を提供する
発見者の脆弱性の発見への取り組みと関与への謝辞は、PSIRTがこれらの個人に報酬を与える最も効果的で安価なツールである。セキュリティアドバイザリおよびソフトウェアリリースノートに発見者への謝辞を含めることは一般的である。PSIRTは、見つかった脆弱性の内部属性をどのように伝達するのかを理解する必要がある。
サブ機能 1.6.1.2 パブリックセキュリティアドバイザリとウェブサイトでのセキュリティ脆弱性発見者に対する謝辞を提供する
発見者の脆弱性の発見への取り組みと関与への謝辞は、PSIRTがこれらの個人に報酬を与える最も効果的で安価なツールである。 セキュリティアドバイザリ、ソフトウェアリリースノート、およびCVEテキストで、発見者への謝辞を含めることは一般的である。
機能 1.6.2 発見者への報奨
38
善意を育成し、研究のさらなる共有を促進するために、PSIRTは、この良好な行動を報奨または奨励するプログラムを開発し、将来も継続し拡大することができる。
目的：組織の製品やサービスの脆弱性を報告した人に報酬を与える。 報酬は、電子/物理的な感謝のメモ、組織の景品、金銭の贈り物、またはその他の商品/魅力など、多くの形を取ることができる。 PSIRTは、与えられた報酬とそのような報奨の規則に透明性を与える必要がある
成果：この活動は、PSIRT組織にとって善意を喚起し、今後のセキュリティ問題に関する継続的な協力を奨励する
サブ機能 1.6.2.1 脆弱性発見者への報奨プログラムを開始する
PSIRTは、脆弱性の発見者への好意的な行動を促すように設計された報酬プログラムを提供することができる。 報酬は金銭的なもの、法人の景品、または発見者がその問題を発見する上での謝辞を上回る価値のあるものがある。
目的：発見者の好意的な行動に報い、組織がセキュリティの脆弱性に対して注意を払っていることを示す
成果：発見者は組織に報告する前に外部に脆弱性を公開するのではなく、協調的に脆弱性を公開する
サブ機能 1.6.2.2 脆弱性報奨金制度を開始する
報酬の1つの形式として、金銭的報酬がある。 いくつかの組織は、脆弱性情報を彼らに開示する発見者に対し報奨を支払う。
目的：脆弱性報奨金制度は、脆弱性を研究し報告する努力に報いるために、発見者に金銭的な報酬を直接提供する
成果：発見者は、金銭的手段によってその努力を補償される
サブ機能 1.6.2.3 ポイント制度を開始する
報酬の別の形態は「ポイント制度」である。 これにより、脆弱性を発見して報告するリー
39
ダーを促進し、発見者が自慢するためのランキングを提供することによって、友好的な競争を促進する。
サービス 1.7 ステークホルダメトリクス
ステークホルダにPSIRTの有効性を認識させるためには、PSIRTの人数、性能、またはその他の測定値に関する詳細な情報を提供することが重要である。 異なるステークホルダは、異なるフォーマットの成果物（またはビュー）で対処しなければならない独自の視点を持つ。 PSIRTは、各ステークホルダグループがこの情報をどのように利用したいかを理解しなければならない。 これらのメトリックは、PSIRTのKPIである。 機能2.5.1は、PSIRTがスムーズな運用を確保するために提供することを検討すべき運用報告に言及する。 機能2.5.2は、PSIRTがステークホルダに提供することを検討可能なビジネスレポートについて述べる。
目的：PSIRTの測定とパフォーマンスに関するデータを提供する。 これは、PSIRTがサービスを提供するうえで効果的であることをステークホルダが理解するのに役立つ
成果：PSIRTメトリクスをレビューすることにより、ステークホルダは、PSIRTがサービスをどの程度効果的に提供しているかを知り、そのサービス提供を調整するためのフィードバックを提供することができる
機能 1.7.1 ステークホルダの要件を理解する
PSIRTがどのようにサービスを提供しているかを効果的に表現するための第一歩は、各ステークホルダグループの独自の視点を理解することである。一部のステークホルダは、セキュリティパッチの適時性について懸念している場合もあれば、PSIRTの運用の財務規模に重点を置く場合もある。各視点は有効であり、所望の情報を効果的に伝達するために異なる報告書を必要とする。 各ステークホルダグループは、データが必要なPSIRTのどの側面、およびその情報を共有するための最良の方法を理解するために意見を出す必要がある。
目的：PSIRTの運営およびサービスに関してステークホルダが気にかけていることを理解する。これらの要件が収集され合意された後には、アップデートの配信方法/メディアおよび配信頻度を決定する必要がある
40