脆弱性に特化したフォーム
脆弱性の深刻度を算出するCVSSや脆弱性の再現方法利用環境など、脆弱性の報告に特化した報告フォームを、Embedでウェブサイトに埋め込みや公開Urlで設置が可能です。
重大な脆弱性に迅速に対応
Slackと連携しているため、報告が来ると、然るべき人にメンション付きで通知が届きます。
これにより、重要な報告の見逃しを防ぐことが可能です。
脆弱性をチーム間で一元管理
受け取った報告はダッシュボード内に蓄積され、ステータス（対応待ち・改善済み、など）を可視化し、チームで共有することが可能です。
エンジニアリソース不要
全てNo Codeでフォームの設置から運用まで実施することが出来ます。貴重なエンジニアリソースを投下する必要がありません。
⚠️ 脆弱性の報告が、セキュリティ担当者に伝達されない
カスタマーサポートしか報告出来る場所がなく、発見者が報告をしたとしても、セキュリティ担当者に伝達されない場合があります。最悪のケースとして、SNSに脆弱性が公開されてしまった事例もあります。
⚠️ 発見された脆弱性が、届くのが遅い
発見者が早期警戒パートナーシップへ脆弱性を報告し、JPCERT/CCを経由して企業が報告を受け取る場合もありますが、実際に企業が報告を受け取るまで数日以上のタイムラグがあるため、脆弱性（≒個人情報漏洩リスク）が放置されてしまいます。
⚠️ 善良な発見者が、法的責任を恐れる可能性
調査に関する規約がなければ、発見者がどれほど善意を持っていたとしても、法的責任を恐れて報告を行わない場合があります。その結果、本来直す事が出来た脆弱性が放置されてしまいます。
RFC9116で規格化が進められている、脆弱性の報告時に、必要な情報を掲示したもの。
ウェブサイトの/.well-known/security.txt に、脆弱性発見時の報告先や調査に関する規約等の情報を掲載する事で設置が可能です。
◎5分で設置完了
security.txtの作成に必要なページ（報告先・ポリシー・謝辞・採用情報）を、ワンクリックで作成。
通常数日かかるsecurity.txtの準備が、5分で完了します。
◎トップグローバル企業と同等のセキュリティ対策
security.txtは、GoogleやFacebook等のトップグローバル企業が導入しています。事前準備不要で、最先端の仕組みを導入することが出来ます。
◎報告先に、IssueHunt VDPのフォームを指定
security.txtには、CSIRTのメールアドレスを掲載しているケースが多いですが、リスト収集業者に悪用される可能性がありますが、フォームUrlを掲載することで防ぐことが出来ます。
メリット①ゼロデイ対策
悪意を持ったハッカーが脆弱性を用いて攻撃を行う前に、ユーザーや善意の報告者から報告を受け取る事で、修正を行う事が出来ます。コミュニティの力を借りて、情報漏洩事故を未然に防ぐことが出来ます。
メリット②メンバーの成長
社内で見つけることの出来なかった脆弱性が報告される場合が多いため、報告を受けてから直すまでの一連の流れを通じ、社内にノウハウを蓄積する事が出来ます。
メリット③企業ブランド向上
security.txtはトップグローバル企業が導入していることもあり、エンジニアコミュニティから好意的に受け入れられる事を期待する事が出来ます。また、報告者とはメッセージ機能を使ってコミュニケーションを行うことが出来るため、サイバーレジリエンスの向上を行うことが出来ます。
.png)
