プロジェクトの脆弱性診断はどうしたら実現できそう
ふとこれみて2つのことを思うわけです。1つは、ブコメにも書いたけれど発想が面白い。もう1つは、テストでバグを仕込んで検出率で品質を確認する手法です。
リクルートテクノロジーズ シニアセキュリティエンジニアの西村宗晃氏（にしむねあ氏）いわく「Ruby on Railsで頑張って書いた、脆弱性てんこもりのソーシャルメディアアプリケーション」。そこから半日かけてそのソースコードを修正し、どれだけ堅牢化できるかに取り組むユニークな勉強会が行われた。
そのあと、これプロジェクトそのものでやったらおもしろいなぁ、と。場面設定を考えるのがものすごく大変そうだけれど。
プロジェクトメンバ一人一人のペルソナ、プロジェクトのプロファイル、あとステークホルダーも必要だ。小さなチームにしても5人以上になりそうで面倒…とすでに作業イメージを想像して夏バテしそう。
ソフトウェアの脆弱性
脆弱性は通常、脆弱性のナレッジ（DBとかシグネチャとか）と照合して拒否したり、危ないよと教えてくれるわけです。ざっくりした物の言い方としては。
肝心なことは、ナレッジと照合する言語化された情報が存在するということです。もちろん、脆弱性のナレッジとして登録されている情報しか識別できませんけれど、それでも多くの脆弱性を可視化してくれます。可視化としたのは脆弱性もレベリングされていて、全部が全部対処する必要はないからです。
脆弱性診断ツールで可視化され、レベルが高（ヤバみがある）であれば直せ、でしょうし、中程度でも直させるでしょう。これも人が認識できるから次のアクションとしてコードを直そうと思うのです。可視化されなければ気づきもしませんし、直そうとも思いません。それにそのコードの脆弱性を突かれるとは思いもしないでしょうから。
プロジェクトの脆弱性は可視化できない
ソフトウェアの脆弱性は診断により可視化できるのは言語化されているからです。比較先があるから。一方、プロジェクトやチームについての脆弱性、つまり、プロジェクトのアウトプットに影響する仕組みのリスクファクターは可視化できないのでしょうか。
世の中に多くのプロジェクトが並行して存在し、組織の中にも多くのプロジェクトとプロジェクトチームが存在します。
プロジェクトがトラブって炎上させるより、脆弱性を可視化して定時で上がれるプロジェクト運営をしたいはずです。
ソフトウェアの脆弱性とプロジェクトの脆弱性の違い、差分は、脆弱性診断検査対象が言語化されているかどうかです。
言語化するためにどうしたら良いか。それはプロジェクトの世界観を可視化することです。
プロジェクト計画書があるからできるのではないか。そうなんですよね。本来はプロジェクト計画書でしたいのです。計画書とずれていることが脆弱性なのですから。
でもそれが実現できないのは、計画書からチームに展開されたとき言語化されていないことについては、チーム、メンバ一人ひとりに解釈と意思決定の基準が投げられ、そのまま可視化されずに結果しか得られないというところなんですよね。
多分それは、永遠に可視化されない…。リポジトリ、コミュニケーションをAIに食べさせてAI任せにしないと情報量過多と複雑で無理ゲーな気がします。
