新しい脆弱性が公開される割合は常に増加しています。現在、年間平均 15,000 CVE に達しています。 2022 年は 26,000 件を超える新しい CVE が報告されており、際立っています。明らかに、すべての脆弱性がソフトウェアに関連しているわけではありません。特定の脆弱性が問題かどうかを判断するには、まずその脆弱性が含まれるライブラリまたは製品を使用しているかどうかを判断し、次にそのライブラリの問題のあるバージョンとモジュールを使用しているかどうかを判断する必要があります。最後に、開発チームに相談して、その脆弱性が特定の製品に関連しているかどうか、またその脆弱なライブラリや製品の使用方法を確認する必要があります。
これらすべてを理解するプロセスは単純ではなく、かなりの時間がかかる場合があります。著名なサイバーセキュリティ専門家であるトム・アルリッチ氏は次のように推測しています。 特定のソフトウェア製品に存在するすべての CVE の約 95% は悪用可能ではありません。しかし、あなたがエンド ユーザーまたはサードパーティ ソフトウェアを自社のシステムに統合しようとしている企業である場合、適切な修復やパッチ適用を依頼できるように、問題のある 5% をどのように特定できるでしょうか?
ここで考えられるのが、 Vulnerability Exploitability Exchange (VEX) の登場。 VEX の目的は次のように定義されています。 ガイダンス 2021 年に米国電気通信情報局 (NTIA) から発表された、「製品が含まれるコンポーネントの特定の脆弱性の影響を受けるかどうか、また影響を受ける場合には、ユーザー (オペレーター、開発者、サービス プロバイダーなど) に追加情報を提供する」というものです。 、修復するために推奨されるアクションがあるかどうか。」
おそらく今、あなたはこう考えているでしょう – では、どうすればこれらの VEX ドキュメントを入手して、コンポーネントのチェックを開始できるでしょうか?さて、VEX の使用の現実は、いつものように複雑です。
VEX の目的を理解する
簡単に言えば、VEX は「このソフトウェアの私のバージョンはこれに悪用可能ですか」という質問に迅速かつ簡単に答えることになっています。 脆弱性？.
その質問に対する答えは、次の 4 つの主要な選択肢のいずれかになるはずです。
- 影響を受けません： この脆弱性に関して修正は必要ありません。
- 影響を受ける： この脆弱性を修正または対処するためのアクションが推奨されます。
- 一定： これらの製品バージョンには、脆弱性の修正が含まれています。
- 調査中で： これらの製品バージョンがこの脆弱性の影響を受けるかどうかはまだ不明です。アップデートは今後のリリースで提供される予定です。
VEX は機械可読かつ機械生成の両方であると考えられているため、これらの文書の検索可能なデータベースをどこかに用意して、関係者がクエリを実行して必要な答えを得ることができるようにするという考えです。
脆弱性の 95% は特定のソフトウェア製品では悪用できないと想定されているため、このシステムは、各製品で見つかった膨大な脆弱性のリストを、ユーザーが監視するか、修復やパッチ適用を要求する必要がある脆弱性のみに絞り込むことを目的としています。のために。
VEXの歴史については興味深い事実が数多くあります
2020 年に遡ると、NTIA (米国国家電気通信情報局) に付随するツールとしての VEX のアイデアについて議論し始めました。 SBOM (ソフトウェア部品表)。 2021 年 XNUMX 月に、NTIA は VEX が何を行うべきかについての XNUMX ページの紹介と説明をリリースしました。
その後、新しい勧告形式の要件を改良する取り組みは、米国サイバーセキュリティおよびインフラストラクチャセキュリティ庁である CISA の後援の下で進められ、独自の勧告形式がリリースされました。 ドキュメント 2022 年初頭には、VEX ドキュメントが役立つと思われるいくつかのユースケースだけでなく、もう少し詳しく説明する予定です。この文書 (草案) は、NTIA が SBOM の最小必須フィールドを定義したのと同じ方法で、VEX 文書の最小必須フィールドを定義しました。
それ以来、機械可読な VEX ドキュメント形式を実際に作成するという 2 つの主要な試みが行われました。
- この 共通セキュリティ勧告フレームワーク (CSAF) 利用可能な最初の形式でした。この形式は、サイバーセキュリティ、ブロックチェーン、IoT、その他の分野のオープンソース標準の作成に特化した国際的な非営利団体である OASIS Open によって 2022 年末にリリースされました。
- サイクロンDX、 OWASP (Open Web Application Security Project) によって開始された SBOM の標準化された形式で、VEX ドキュメントの作成にも適合しました。
CSAF は包括的な形式ですが、実際に使用するには、複数のフィールドと多くのメタ情報を含める必要があるため、実際の採用は困難です。CyclonDX VEX イニシアチブははるかにスリムであるため、どの VEX 標準を使用するかを検討する場合、おそらく最も適しているでしょう。 CyclonDXフォーマットで。
VEX が障害にぶつかった理由 – 成功を妨げている問題を明らかにする
VEX は良いアイデアであり、特定のソフトウェア製品で特定の脆弱性が実際に悪用可能かどうかを迅速に確認できる貴重な機能を提供します。
ただし、これまでのところその実装を妨げているいくつかの問題があります。
- 提出責任 – 必要な VEX 書類の提出は誰が担当しますか?ソフトウェアの制作者ですか？サードパーティのセキュリティ会社ですか、それとも非営利団体ですか?政府機関？複数の情報源が矛盾する情報を提出した場合はどうなるでしょうか?
- VEX データベース – VEX 情報を保存および分類するのは誰ですか?文書の一部にソフトウェアの悪用可能な問題が記載されていると仮定すると、その情報が間違った (悪意のある) 手に渡る危険はないでしょうか?
- 現在の形式では、バージョンの問題が適切にカバーされておらず、さらには統合バージョン管理の問題も適切にカバーされていません。
ソフトウェア/パッケージ バージョンの結合とは、複数のソフトウェア パッケージまたはコンポーネントを 1 つのリリースまたはインストール パッケージにバンドルする方法を指します。
脆弱性パッチの適用に関しては、ソフトウェアとパッケージのバージョンの組み合わせがプロセスに役立つこともあれば、妨げになることもあります。一方で、必要なすべてのコンポーネントを含む単一のインストール パッケージがあると、脆弱性を特定してパッチを適用するプロセスを簡素化できます。個々のコンポーネントを手動で識別してパッチを適用する必要はなく、パッケージ全体にパッチを適用するだけで済みます。
ただし、これは裏を返せば、パッケージ内の 1 つのコンポーネントが脆弱であれば、ソフトウェア全体が脆弱になるということです。これは、パッケージ内の一部のコンポーネントにパッチが適用されている場合でも、パッチが適用されていないコンポーネントが 1 つだけ存在すると、パッケージ全体が依然として危険にさらされる可能性があることを意味します。
ソフトウェアのライブラリ A のバージョン 1 に脆弱性があるとします。この問題は、ライブラリ A がライブラリ B のバージョン 2 とともに存在する場合にのみ発生します。セキュリティ パッチはありますが、誰もがそれをインストールしているわけではありません。つまり、ソフトウェアの脆弱性に関する VEX ドキュメントは、製品、そのバージョン、それに含まれるライブラリ、そのバージョン、およびリリースされる可能性のあるパッチのすべての可能な組み合わせをカバーする必要があります。単純に表現するのが難しい複雑な情報がたくさんあります。
- VEX は、ハードウェアに組み込まれているソフトウェアを、そこで利用可能なすべてのバージョンとパッチをどのようにカバーするのでしょうか?自分でハードウェアを開けてパッチを適用するのは簡単ではないことを考えると、このソフトウェアにパッチを適用するのは誰の責任になるでしょうか?
これらは、VEX を処理する自動ツールが理解し、考慮する必要がある問題の一部にすぎません。
任意のバージョンの情報をリクエストして入手できれば、もっと簡単だと思いませんか?
この重要な情報を共有する最良の方法はドキュメントを使用することであるという仮定は、おそらく間違っています。バージョン、パッチ、脆弱性のあらゆる組み合わせをカバーするのに十分な VEX ドキュメントを作成することは、当然のことながら、誰もやりたがらない重要な作業です。
筆記 は、特定のソフトウェア プロジェクトまたは製品の各ビルドのセキュリティ関連情報を追跡および共有するためのプラットフォームを構築しました。その一環として、各ビルドは正確な SBOM と製品で発見された脆弱性のリストを生成します。
Scribe を使用すると、ソフトウェア作成者は、これらの脆弱性のそれぞれに VEX 形式でアドバイザリを追加し、悪用可能でない場合や調査中である場合などに注意を払うことができます。バージョンがリリースされると、そのバージョンに関するすべてのセキュリティ情報は、関心のある第三者、ユーザーと共有できます。 、レギュレーターなど。脆弱性リストと VEX アドバイザリー リストを含めることは、受信者がこの特定の製品で潜在的な問題となる脆弱性のみを確認できる必要があることを意味します。これにより、自社の製品を「ホワイトリスト」に登録できるソフトウェア制作者と、特定のソフトウェア製品にどのようなレベルのリスクが含まれているかを正確に理解しているソフトウェア消費者の両方の負担が大幅に軽減されます。
特定の脆弱性が実際に製品の特定のバージョンに関連しているかどうかを明確に言えるのはソフトウェア製造者だけであるため、自社の製品に関するアドバイザリを追加および変更できるのはソフトウェア製造者だけです。この点に関するソフトウェア製作者の判断は最終的なものであり、異論の余地はありません。この情報を誰と共有するかについての決定も、ソフトウェア製作者の特権です。
製品のビルド、SBOM、およびセキュリティ情報の完全な履歴が Scribe によって保存されるため、ユーザーはソフトウェア ライフ サイクル全体を通じて使用する可能性のある任意のバージョンに関するこの情報を簡単に要求して取得できます。
まとめ
最近のソフトウェア製品を適切にスキャンすると、数千とは言わないまでも数百の脆弱性が生じる可能性があることを忘れないでください。ほとんどの人はそのような数字に対処することはできません。アラート疲れが始まり、脆弱性の数はまさにその数になります。
検出される問題の数を管理可能な量まで削減できる可能性は、ソフトウェアの作成者とユーザーにとって恩恵となるでしょう。目的は、ソフトウェア作成者ができるだけ早く問題にパッチを適用して修正できるように、実際の問題のみに焦点を当てることです。
自動化ツールなど 筆記 各プロジェクトやビルドに関連する脆弱性だけを簡単に確認できる簡単な方法を提供し、その情報を簡単に共有できるため、脆弱性の山が大幅に小さくなり、管理しやすくなります。
ただし、重要な注意点は、関連する脆弱性を簡単に確認してそれにのみ対応できるこの未来は、オープンソース コミュニティの積極的な参加なしには実現できないということです。最近のほとんどのコードは大量のオープンソース ソフトウェアで構成されているため、そのようなライブラリのメンテナや開発者は、コードを悩ませている悪用可能な脆弱性の発見と修復に参加する必要があります。
関連性のある悪用可能な脆弱性の問題は解決していないため、「このソフトウェアの私のバージョンはこれに悪用可能ですか」という質問に対する答えを得る最も効率的でコスト効率の高い方法を見つけるのは私たち全員の義務です。 脆弱性」.
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
