CVEはソフトウェアのセキュリティを示す良い指標ですか？
製品ごとのCVEレポートの数 を見ると、どのプログラムが最も安全であるかを示す指標として使用したくて、それに応じてインストールするプログラムを選択します。
しかし、これらの数値は誤解を招くのではないかと思います。たとえば、Linuxカーネルはリストの2番目であり、Windows 10についても言及されていません。 Linuxのオープンソースの性質が原因であると思います。これにより、欠陥の検出と修正がより簡単かつ迅速になり、CVEの数が増加します。
Chromeには2016年にFirefoxよりも多くの脆弱性がリストされていますが、Firefoxにはコード実行の欠陥が多くありますが、Chromeの欠陥の大部分はDoS攻撃です。 、それほど深刻ではありません。
これらのソフトウェアが持つCVEの数に基づいて、ソフトウェアは他のソフトウェアよりも「安全」であると言えますか？
これらのソフトウェアが持つCVEの数に基づいて、ソフトウェアが他のソフトウェアよりも「安全」であると言えるでしょうか。
いいえ。CVEエントリは、「全体的なセキュリティ」で製品をランク付けするための適切なソースではありません。
[〜＃〜] cve [〜＃〜] システムの背後にある主なアイデアは、ソフトウェアの脆弱性の一意の識別子を作成することです。これは、製品の既知のすべての脆弱性の完全で検証済みのデータベースになるようには設計されていません。つまり、ベンダーまたは研究者は、特定の欠陥についてCVE番号を要求しないことを単に決定できます。さらに、エントリ たまに組み合わせる 単一のIDに関連するバグまたは 非公開 正確な影響、単純な「バグ数」はかなり意味のないセキュリティ基準になります。また、ランキングでは、さまざまな重大度を比較するための賢明なメトリックを見つける必要があります。 （DoSバグの数は、リモートコードの実行に相当します...？）
とはいえ、CVEは製品にどのような脆弱性が見つかったかについてのアイデアを確実に提供し、研究の出発点として適しています。ただし、その量は、ソフトウェアの古さ、およびセキュリティ監査を通じてソフトウェアが受ける注意の程度に強く依存します。多くのCVE割り当てがソフトウェアの記述が不十分であることを意味するのか、それとも明らかに多くの脆弱性が修正されているために特に安全であることを意味しているのか、実際には推論できません。 couldは完全に監査されていないことを示しているため、古い製品にパッチを当てた脆弱性の非常に短い記録がある場合、私は個人的にそれを疑う傾向があります。
したがって、CVEを データベースではなくディクショナリ と見なす必要があります。これは、脆弱性にハンドルを割り当てるだけなので、簡単に参照できるため、セキュリティを比較するツールとして使用しないでください。
安全な製品のより良い指標は次のとおりです。
- ソフトウェアは積極的に使用および開発されています。
- ベンダーは、人々に脆弱性を検索するように奨励します（そして多分報奨金を提供するかもしれません）。
- 新しいセキュリティバグは迅速に処理およびパッチされます。
自発的なシステムとして、CVEは追跡するソフトウェア製品と同じくらい悪用される可能性が高く、多くの場合非常に主観的です。これは、通常はCVSSv2である重大度を追跡するために使用されるスコアリングメカニズムによって多少複雑になります。
理想的な世界では、製品に脆弱性が発見された場合、開発者はCVEを登録し、後でその製品に対して作成した修正と一緒にCVEを公開します。
ただし、他の人が指摘したように、CVEが作成されない場合や、開発者が一連の脆弱性を取り、すべてを修正するリリースを1つカットして、付随するCVEで作成する場合があります。
特定のソフトウェア製品の使用に興味があり、そのセキュリティについて予約があった場合は、CVEデータベースを具体的に確認するよりも、セキュリティ問題の処理方法やレポートの受信方法などを検討する可能性が高くなります。
上記の1つの例外は、他のコンポーネントを使用するソフトウェア製品です。これらの場合、製品がその構成製品/サービスに対して発行されたCVEに追いつくのにかかった時間を調べると、啓発できる場合があります。オープンソースコンポーネントを再パッケージ化する市販のソフトウェアは、多くの場合、セキュリティ修正で何ヶ月も遅れることがあります。これはおそらく、CVEデータベースを利用する上で最も有用なものです。
CVEは、人々が積極的に悪用しようとしているアプリケーションのバグのみを表します。オープンソースは、CVEの量の増減の影響を受ける場合とそうでない場合がありますが、アプリケーションが悪用される傾向があることを意味するものではないと合理的に想定できます。多くのエクスプロイト/脆弱性は、CVEエントリと見なされる前に、0日として販売されることがよくあります。また、オープンソースコミュニティの多くの人々は、利益よりも合理的な開示に向いていることを考慮してください。いずれの場合も、2つのアプリケーションの脆弱性をいくつかの指標に基づいて測定します。
- 過去のエクスプロイトの影響はどの程度深刻ですか？
CVEの量：ほのめかしたように、CVEの数が増えると、アプリケーションがセキュリティ調査によって頻繁に監査されることになります。
オープンソース：私は個人的にオープンソースを「一般的に」より安全だと考えています。自分のソースコードを見て、コーディングスタイルを見てください。たぶん、自分で脆弱性を見つけることができます。
多分少しかもしれませんが、カウントと品質の関係は、意味があるとしても複雑です。 CVEの数と、ソフトウェアのセキュリティ/品質に関するそれらの影響に関して尋ねるのに役立つ質問は次のとおりです。
CVEはありますか？そうでない場合、それはおそらく、誰もその中のセキュリティバグを探すほど気にしていないことを意味します（つまり、関連性が低く、高品質ではありません）。
同じ種類のバグのCVEが年々繰り返されていますか？もしそうなら、それは、開発者/メンテナがおそらくコードベース全体を修正してバグを引き起こしたプロセスを修正するのではなく、特定のバグを修正するために必要な最低限のことを行っていることを意味します。
CVEは、同じ年の他の同様のプログラムのCVEに匹敵することがわかりましたか。また、それらが見つかった年の間さえ妥当ですか？たとえば、ウェブアプリケーションで使用されるほとんどの言語では、SQLインジェクションのバグが存在することは、完全に間違っている/後方のAPI /フレームワークが使用されていることを示します（つまり、準備されたステートメントのない古いもの）。 Cプログラムの場合、これは判断がはるかに困難です。 CVEの要約では、バグが微妙である（つまり、「合理的に」現れる）か、またはばかばかしく、現代の慣習に反する何かを行ったことが原因であるかはわかりません。
等々。これらの質問のほとんどは、単純なカウントだけに依存しているわけではないため（「さまざまなクラスのカウント」としてモデル化できるものもあるかもしれません）、カウントだけに大きな価値があるのではないかと疑っています。