再発防止には「入手した脆弱性情報の適切な評価」をプロセスに含めることも対策に含めるべきではないか

脆弱性情報は、早期に入手すればするほど「危険性の評価」が難しくなる傾向にある。これは、公開情報などを契機に「早期に」入手できた情報には「PoCなどが伴わない」ことが多いからだ。この場合、おおざっぱには当該情報をもとに「対処する」「PoCなどの公開がされないか経過観察する」「対処しない」という三択になる。

再発防止策が偏ってるなぁ…と感じるのはオレだけか？

再発防止はどれも「まぁそうだね」と思えるものが並んでるけど、「２　情報セキュリティマネジメントに関する防止策」中、「（３）ア　脆弱性情報の早期入手」と「（３）イ　脆弱性情報等に関する情報のエスカレーションプロセスの策定」だけでいいのか？というように感じる。

「全社的リスク管理の課題」は本当に真の課題か？

現場に寄り添うべき立場の者として、この課題（の記述）は少し腹立たしい。
報告書中、以下のような記述がある。

本件事故の原因とも言える「大規模の脆弱性発覚」のリスクは、本来、看過できない重大なリスクであったと考えられるものであるが、経営管理の上流での検討が十分になされないまま、現場サイドの判断によって重大リスクから漏れてしまっていた。

これは少し、現場サイドに責任を押し付けているようにも読める。
現場サイドはこれまで脆弱性対応を（現場で）大変な目にあいながらも致命的な事故が発生する前に迅速に行なえてきたのではないか、と感じる。そして、そういった現場の話とは別に、外部での攻撃発生や被害発生について、経営管理上のリスクを検討するインプットになっていなかったのではないか、とも感じる。

よくわからない点：脱Struts宣言を出したものの、リスク含みの既存システムへの対応が不十分なあたり

新規開発でStrutsを使わない宣言を出したのは評価出来るけど、既存システムへの対応がない（ように見える）のが不可解。
報告書では「既存のStruts 2使用システムの再構築には至らなかった」とあるが、これは正直「システム運用の現場」を理解していない（理解していたとしても、現場の努力に報いない）文言とも取れる。Struts 2で構築されたシステムを別フレームワークを使って再構築ってのは、ほぼゼロからシステム構築するのに等しい。再構築に至らないまでも、「既存システムの監視強化」なり「保有リスクと認識し、セキュリティ強化」となるのが（個人的には）正しいと考えてたり。

ヤバさを認識するまでが遅いのがBad

ヤバさを知覚してから対応に入るまでの速度が高速なのはいいのだけど、脆弱性が公開された時刻からGMO-PG側で脆弱性情報を確認し、ヤバさを知覚するまでの時刻に開きがありすぎというのがヤバい。

簡単に脆弱性公開からGMO-PGさん対応までの話を図に起こしてみた。図の上部がGMO-PGさんの対応、図の下部が（攻撃者も含めた）外部の動き。絵心なくてすんません…。

ヤバい事象の認識から対応に移るまでの時間の短さはGood

3/9 18:00にヤバさを認識し、同日21:56にWAFによるブロックを開始したのはGood。

インシデント発覚から公表までの期間の短さはGood

3/10 2:15にインシデントが発覚し、公表が同日18:22に行われている。
関係各所の調整も含めて16時間で公表というのは、個人的な所感では超高速だと感じる。