コンテンツ
出典：BrianAJackson / iStockphoto
取り除く：
今こそ、オープンソースコンポーネントのリスク評価について考える方法で物事を揺さぶる時です。
ソフトウェア開発コミュニティが脆弱性をどの程度深刻に受け止めるべきかを評価するためのシステムを開発することは、簡単に言えば挑戦です。コードは人間によって書かれており、常に欠陥があります。それでは、完璧なものはないと仮定した場合の質問は、生産性の高い作業を継続できるように、リスクに応じてコンポーネントをどのように分類すればよいでしょうか？
事実だけ
この問題への取り組みにはさまざまなアプローチがありますが、それぞれに正当な正当性がありますが、最も一般的な方法は定量モデルに基づいているようです。
一方で、脆弱性の重大度を定量的に判断することは、脆弱性自体に関連する要因のみに基づいて、より客観的で測定可能という点で有用です。
この方法論では、ソフトウェア業界全体でコンポーネント、ライブラリ、またはプロジェクトがどれだけ広く使用されているか、また攻撃者にどのようなアクセス権を与えるかなどの要因を考慮して、脆弱性が悪用された場合にどのような損害が発生する可能性があるかを調べます彼らがターゲットを突破するためにそれを使用するべきであるならば、破壊の大混乱。ここでは、簡単に悪用される可能性などの要素が、スコアに影響する大きな役割を果たします。 （セキュリティの詳細については、Cybersecurity：How New Advances Bring New Threats-And Vice Versaをご覧ください。）
マクロレベルで見たい場合は、定量的観点から、どのように脆弱性が群れを傷つけるかを検討し、実際に攻撃を受けた企業に与えられる損害に焦点を当てません。
おそらく最もよく知られている脆弱性データベースであるNational Vulnerability Database（NVD）は、バージョン2と3の両方のCommon Vulnerability Scoring System（CVSS）に対してこのアプローチを採用しています。脆弱性を評価するためのメトリックを説明するページで、彼らは以下のメソッドを書きます：
その定量モデルにより、ユーザーはスコアの生成に使用された基礎となる脆弱性特性を確認しながら、再現性のある正確な測定を保証します。したがって、CVSSは、正確で一貫した脆弱性影響スコアを必要とする業界、組織、および政府の標準測定システムとして適しています。
プレイ中の定量的要因に基づいて、NVDはスケールの数値（1〜10、10が最も厳しい）、およびLOW、MEDIUM、およびHIGHのカテゴリーの重大度スコアを導き出すことができます。 。
バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド
誰もソフトウェアの品質を気にしない場合、プログラミングスキルを向上させることはできません。
影響の説明
ただし、NVDは、特定のエクスプロイトが被害をもたらした影響度に基づいて、脆弱性のより定性的な尺度と呼ぶことができるものを明確にする努力をしているようです。公平を期すために、システムへの脆弱性の影響を測定する限り、機密性、整合性、および可用性の要因を見て、影響を組み込みます。これらはすべて、より簡単に測定可能なアクセスベクトル、アクセスの複雑さ、および認証などの重要な要素です。しかし、脆弱性が組織の実際の損失を引き起こす場合の現実世界への影響を関連付けるというタスクには至っていません。
たとえば、運転免許証の詳細、社会保障番号、および不正なキャラクターが大規模な詐欺行為を実行するために使用できるその他のビットを含む、約1億4500万人の個人を特定できる情報を暴露したEquifax違反を考えてみましょう。
EquifaxがWebアプリで使用したApache Struts 2プロジェクトで発見された脆弱性（CVE-2017-5638）は、攻撃者が玄関を歩き、最終的には腕をジューシーな個人情報でいっぱいにすることを可能にしました。 。
NVDが重大度スコア10およびHIGHを適切に付与した一方で、その決定は潜在的な損害の定量的評価によるものであり、Equifax違反が公開された後に発生した広範な損害の影響を受けませんでした。
これはNVDによる監視ではなく、彼らが述べたポリシーの一部です。
NVDは、各脆弱性の生来の特性を表すCVSS「ベーススコア」を提供します。現在、「時間スコア」（脆弱性の外部のイベントにより時間とともに変化するメトリック）や「環境スコア」（組織に対する脆弱性の影響を反映するようにカスタマイズされたスコア）は提供していません。
意思決定者にとって、量的測定システムは、業界全体に危害が及ぶ可能性を検討しているため、それほど重要ではありません。あなたが銀行のCSOである場合、エクスプロイトが顧客のデータまたはさらに悪いことに彼らのお金を相殺するために使用される場合、エクスプロイトが持つ可能性のある定性的な影響に注意する必要があります。 （さまざまな種類の脆弱性については、The 5 Scariest Threats In Techをご覧ください。）
システムを変更する時？
そのため、Equifaxのケースで使用されたApache Strusts 2の脆弱性は、被害がどれほど広範囲に及ぶか、またはNVDのようなシステムにとってシフトがあまりにも主観的であることに照らして、より高いランキングを獲得する必要があります続けて？
NVDで説明されている「環境スコア」または「時間スコア」を作成するために必要なデータを作成することは非常に困難であり、無料のCVSSチームのマネージャーを果てしない批判と膨大な作業に開放することを認めます。 NVDなどが、新しい情報が公開されたときにデータベースを更新します。
もちろん、開示法で義務付けられていない限り、侵害の影響に関する必要なデータを提供する組織はほとんどないため、そのようなスコアのコンパイル方法については疑問があります。 Uberの事例から、企業は、一般の反発に直面しないように、違反に関する情報が報道機関に届かないようにするために、迅速に支払いを行う意思があることがわかりました。
おそらく必要なのは、脆弱性データベースの優れた努力を取り入れ、情報が利用可能になったときに独自のスコアを追加できる新しいシステムです。
前の層がここ数年十分に仕事をこなしているように見えるのに、なぜこの得点の余分な層を扇動するのでしょうか？
率直に言って、組織のアプリケーションに対する責任を負うのは組織に対する説明責任です。理想的な世界では、誰もが自分のインベントリに追加する前に製品で使用するコンポーネントのスコアをチェックし、以前に安全であると考えられていたプロジェクトで新しい脆弱性が発見されたときにアラートを受け取り、必要なパッチをすべて自分で実装します。
おそらく、これらの脆弱性の一部が組織にとってどれほど壊滅的なものであるかを示すリストがあれば、組織はリスクのあるコンポーネントに巻き込まれないようにプレッシャーを感じるかもしれません。少なくとも、彼らは既に所有しているオープンソースライブラリの実際のインベントリを取得するための措置を講じることがあります。
Equifaxの大失敗の後、複数のCレベルの幹部が、製品にStrutsの脆弱なバージョンが含まれていないことを確認するために急いでいる可能性がありました。残念ながら、業界にオープンソースのセキュリティを真剣に考えさせるように、この規模の事件が発生しました。
アプリケーションのオープンソースコンポーネントの脆弱性が非常に現実的な結果をもたらすという教訓が、意思決定者がセキュリティを優先する方法に影響を与え、製品と顧客のデータを安全に保つ適切なツールを選択することを願っています。