セキュリティを文脈で考える：CVEがCVEではないのはどんなとき？

Snykでは、セキュリティに関する考え方や意思決定の指針として、いくつかの基本原則を設けています。

まず、誰から守るのかを理解することが常に重要です。それによって、取るべき対策が変わるからです。たとえば、保護対象がWebサーバーであれば、信頼できないユーザーから守る必要があります。一方、暗号化ソフトウェアであれば、システムに物理的にアクセスできるユーザーからも守る必要があるのは明らかです。いずれの場合も、リスクの境界がどこにあり、どこに注意を向けるべきかを明確にします。

次に、設定もコードベースの一部です。悪意ある攻撃者が設定にアクセスできるなら、コードベースにアクセスできる場合と本質的に同じです。

最近のLog4j 2.xの脆弱性（Log4Shell）によって、脆弱なシステムが津波のように押し寄せたことを受け、コミュニティがほかの潜在的な脆弱性をこれまで以上に詳しく探し始めたとしても無理はありません。しかし、コード内で見つかる潜在的なセキュリティ問題すべてについて、急いで判断を下す前に、立ち止まって考える機会にするべきではないでしょうか。冷静に考えれば、セキュリティ問題を引き起こすものがすべて同等に分類されるべきではないこともわかるでしょう。

たとえば、この視点から最近のLog4j 1.xに対するCVE-2021-4104の割り当てを考えてみましょう。これを悪用するには、設定ファイルに直接アクセスして設定を操作する必要があります。現在、Logbackプロジェクトをめぐっても同様の議論が起きており、Nodeコミュニティにも例があります。

潜在的な脆弱性を明らかにすることは、依然として「良いこと」です。ただし、メディアが騒然とする中で、私たち自身の批判的思考を働かせ、コミュニティとして何に注力すべきかという共通認識を改めて築くことも大切です。潜在的な脆弱性の津波をさらに引き起こすと、すでに負荷の高いセキュリティチームをいっそう疲弊させ、オープンソースソフトウェアの安全性を高めるための業界の取り組みを妨げる混乱を招きかねません。

CVEについて批判的に考える

先ほどの議論で取り上げられた内容は、非常に興味深い疑問を投げかけています。

たとえば、脆弱性の悪用にシステム内のファイルへの特権アクセスが必要なら、それは本当に脆弱性なのでしょうか。ほとんどの非自明な現代のソフトウェアは、安全でない動作を許すように設定できます。たとえば、sshdを空のパスワードでログインできるように設定することは十分可能です。これをsshdの新たな脆弱性と見なすべきでしょうか。

セキュリティチームが用いる手法の一つに、想定される動作と想定外の動作を見極めることがあります。リモートコードを実行するように設定でき、その機能が十分に文書化されているソフトウェアの場合、その動作は悪用可能な弱点をもたらすのでしょうか。これは想定された動作であり、厳密にはセキュリティ脆弱性ではないという主張も成り立ちます。

安全でないモードに設定できないよう、ソフトウェアを設計するべきでしょうか。それは望ましい目標かもしれませんが、過去30年以上にわたるオープンソースソフトウェアの設計思想とは多少相いれません。オープンソースソフトウェアの一般的な設計目標は、あらゆるユースケースに対応できるよう、設定の柔軟性を最大限に高めることでした。近年、安全なデフォルト設定も副次的な目標として重視されるようになりましたが、ユーザーが安全かどうかにかかわらず、自分の判断でソフトウェアを自由に設定できるようにするという原則は、常に大切にされてきました。

現在、CVEは個人や企業が容易に登録できる一方で、信頼性や名声を得る手段としての価値もあります。この独特な組み合わせは、疑問の残る割り当てにつながる可能性があります。一方、潜在的なセキュリティ問題を摩擦なく報告できる仕組みは、間違いなく望ましいものです。こうして、ある種のパラドックスが生じています。

業界では脆弱性の特定が大きく進歩する一方、ソフトウェアの量も大幅に増えています。そのため、対応が追いつかなくなる可能性は容易に想像できます。

ソフトウェアの脆弱性を正しく特定して評価し、緩和策を提供するには、多大なリソースが必要です。特に複雑なケースでは、その大部分が今も手作業です。機械学習（ML）の手法は有用性を増しており、AIもさらに役立つ可能性がありますが、多くの場合、皮肉にも診断においてコンピューターはあまり役に立ちません。

編集者注（2021年12月19日）：この記事の公開後、Logbackプロジェクトは上記の問題にCVE-2021-42550を割り当てました。この記事で説明した根拠に基づき、Snykは現時点でこの問題に関するアドバイザリを追加する予定はありません。今後もLogbackコミュニティとの対話を続け、オープンな議論を通じて合意に達することを期待しています。

今後に向けて

ここで示した論点は、特定のCVEを変更することを目的としたものではありません。脆弱性評価の今後や、現在そしてこれから何を安全でない状態と見なすべきかについて、議論を始めるためのものです。幅広い用途に適した強力で柔軟なオープンソースソフトウェアを構築すれば、セキュリティレベルに差のある設定モードが生まれるのは避けられません。そうした開発を続けるなら、ユーザーにも、利用時の落とし穴を理解する責任があります。潜在的な脆弱性を分類するだけでなく、適切なドキュメントや教育を充実させることも答えになるかもしれません。

ぜひコミュニティの皆さんの意見をお聞かせください。ソーシャルメディア（@snyksec）でご連絡いただき、ぜひ話し合いましょう。