脆弱性にはどう名前を付けるべき？ ボットを使ってみるもうまくいかず

脆弱性に中立でランダムな名前を付けるボット「Vulnonym」

　2014年4月に公にされたOpenSSLの脆弱性「Heartbleed」以降、脆弱性に名前を付けることは珍しくなくなっています。脆弱性は一般的に「CVE-西暦-数字」の形式のCVE番号などで識別されますが、名前を付けることで単なる番号よりも覚えやすくなり、また、メディアが取り上げやすくなることもあり、より速やかに関係者に周知させることができるのは確かでしょう。さらに、注目度が上がることで、その脆弱性を見つけた研究者やその所属する組織（一般的にセキュリティベンダー）の知名度を上げる効果もあるようです。

　このような「成功」事例から、脆弱性に名前を付けるのが一般的になったのだと考えられます。しかし、その一方で、さほど深刻でない脆弱性にも名前が付けられたことで必要以上に注目されたり、また、過剰に恐怖心を煽る名前が付けられたことで不要な混乱を生んでしまったりしたケースもあります。

　その典型的な例として、2018年1月に公になったプロセッサの脆弱性「Spectre/Meltdown」が挙げられます。「Spectre/Meltdown」はもちろん無視して良い脆弱性ではありませんが、日々公開される数多くの脆弱性全体の中で見れば、もっと注目すべき脆弱性が他にもあったにもかかわらず、「Spectre/Meltdown」というインパクトのある名前が付けられたこともあって、世界中の多くのIT系のメディアが大々的に報道し、日本ではNHKのニュースでも報道されるほどでした。しかし、これは明らかに過剰でした。

　このような中、世界で最初のCSIRTである米CERT/CCは、脆弱性に「Spectre/Meltdown」のような必要以上に不安を煽るような名前を付けることに対する懸念を述べるとともに、脆弱性に中立でランダムな名前を付けるTwitterボット「Vulnonym」のプロジェクトを始めたことを発表しました。このボットはフリーな辞書「Wiktionary」を使って形容詞と名詞をランダムに組み合わせた複数の単語からなる名前を付けるもので、その名前はCVE番号とマッピングさせる形でTwitter上で紹介されます。CERT/CCでは、このボットが生成した名前の中に攻撃的（offensive）なものがある場合には連絡してくれれば削除した上で名前を再生成するとし、プロジェクトへの協力を呼び掛けています。

　今回、CERT/CCから脆弱性の名前の付け方に対して懸念が表明されたのは、CERT/CCの影響力を考えると歓迎すべきことではあります。しかし、Vulnonymについては、確かに中立な名前ではあるものの、付けられる名前は脆弱性の内容と全く関係がなく、ほとんど意味をなさないものであるため、覚えにくく、名前を付けるメリットが全く感じられないものになっています。

　例えば、PostgreSQLの脆弱性（CVE-2020-25694）に付けられた「Topless Beam（トップレスビーム）」という名前は、完全に意味不明で、確かにそのインパクトのあるネーミングにより名前自体は覚えられるかもしれませんが、この名前からPostgreSQLの脆弱性であるとイメージすることは全くできず、脆弱性の名前としてはむしろ覚えにくい不適切なものになっています。

　また、一般的に「Zerologon」として知られるNetlogonの実装における特権昇格の脆弱性（CVE-2020-1472）には「Wattled Lathe（編み枝細工の旋盤）」という名前を付けていますが、脆弱性の名前としては「Zerologon」の方が相応しいのは明らかでしょう。

　まだ始まったばかりのプロジェクトなので、今後どうなっていくのかは分かりませんが、中立ではあっても、もう少し脆弱性の内容を反映した名前を付けるなどの工夫は必要でしょう。今後の改善に期待したいです。

脆弱性修正の優先順位付けにおけるセキュリティチームと開発チームの連携の実態

　米セキュリティ企業WhiteSourceは、アプリケーションセキュリティのプロとソフトウェア開発者の計560名を対象にDevSecOpsについての実態調査を行った結果を「WhiteSource DevSecOps Insights - Security vs. Developers: The DevSecOps Showdown」として公開しました。レポートの内容の中心は、セキュリティのプロと開発者の考え方や認識の違いなどを比較するものとなっています。

　中でも注目すべきは脆弱性の優先順位付けに関するものです。まず、アプリケーションセキュリティに関する最大の課題としてセキュリティのプロは「脆弱性の優先順位付け」をトップに挙げています。

　一方、セキュリティチームと開発チームとの間でアプリケーションのどの脆弱性を修正するかについてどの程度まで合意しているかとの問いに対する回答は以下のようになっています。

　両チーム間の合意が十分にできているとは言えない、つまりチーム間の連携が不十分な実態が見えています。しかし、同じ質問に対する回答として、アプリケーションセキュリティに関して主導的な役割を担う優秀な人材を開発チームに配している場合とそうでない場合では大きな違いがあることも分かっています。

　この結果を踏まえ、WhiteSourceはアプリケーションセキュリティに関する優秀な人材を開発チームに配することが改善の第一歩であるとしています。しかし、そのような優秀な人材を配しているのは40％から60％にとどまっているようです。

　WhiteSourceのレポートは、課題の2位に挙げられている人材問題を先に解決することで、4位のチーム間連携の問題も解決でき、その結果として1位の優先順位付けの問題も解決できると読める内容になっていますが、これは間違いとは言わないまでも違和感があります。確かに、リーダーシップを発揮してくれる優秀な人材がいれば、チーム間の連携は取りやすくなるでしょうし、それによって優先順位付けに関するチーム間合意も取りやすくはなるでしょう。しかし、それはあくまで「そうなりやすくなる」だけで、優秀な人材さえ配すれば何とかなるかのような説明の仕方は適切ではありません。

　今回のレポートによれば、チーム間の連携が取れていないことを問題視しているのは31％となっていますが、チーム間の連携が十分に取れていないにもかかわらず、それを問題と捉えていないケースもあると考えると、実際にはチーム間連携に問題を抱えている割合はもっと多いと推測できます。とにかく、セキュリティチームと開発チームはそもそもの目的が異なるため、さまざまな点でギャップが生じるのは当然です。しかし、脆弱性への対応に両者の連携は必須です。当たり前のことですが、人材云々にこだわらず、まずは「どうすれば両者の連携がスムーズに行えるようになるか」を検討してみてください。また、解決策は組織ごとに違うものであり、絶対の解などは存在しないことを忘れないでください。