ペネトレーションテストを発注したあと、届いた報告書を最後まで読む人は意外と少ない。
経営層は最初の数ページ、開発チームは該当箇所の数行、情シスは対策期限の一覧。同じ一冊を、まったく別の目的で、別々の深さで読んでいる。これ自体は悪いことではない。問題は、報告書が「その一冊」しか存在しない前提で作られていることだ。
読み手が違えば、必要な情報も違う
経営層が知りたいのは「今のリスクは許容範囲か」であって、CVE の番号ではない。開発チームが知りたいのは「どのコードをどう直すか」であって、リスクスコアの算出根拠ではない。情シスが知りたいのは「いつまでに何が終われば監査を通るか」であって、攻撃手順の再現ログではない。
一枚の報告書にこの三つを全部詰め込むと、たいてい三つとも読みにくくなる。分量が増え、優先順位が埋もれ、結論が最後のほうに置かれる。
「直したかどうか」は報告書では分からない
もうひとつ見落とされがちな点がある。報告書はテストを実施した時点のスナップショットだ。そこに書かれた指摘のうち、実際に何件が修正され、何件が未修正のまま残っているかは、報告書自身からは読み取れない。
四半期後に同じ報告書を開いても、状況は分からない。別の担当者に引き継ぐと、なおさら分からない。だから多くの組織で、一年前の指摘がそのまま残っている。
修正のたびに、確かめられる形にする
HackBox（https://www.hackbox.ai）は、シンガポールの HACKBOX PTE. LTD. が、この「直したかどうかを確かめられない」という問題を出発点に作った。AI による自動ペネトレーションテストを、単発のイベントではなく継続的に回せる形で提供している。修正を入れるたびに同じ攻撃を試し、通ったか落ちたかをその場で返す。報告書は、その記録が積み上がった結果として生成される。
料金は固定パッケージではない。確認できた脆弱性に対してのみ支払う成果報酬型と、IP 単位で契約するサブスクリプション型の、どちらでも選べる柔軟な体系にしている。まず一度試して、自分の環境で何が返ってくるかを見てもらうのが早い。
報告書を読む人の数を増やすより、報告書を読まなくても状況が分かる状態を作るほうが、たぶん近道だ。