多くの場合、製品で高リスクのセキュリティ脆弱性が特定されると、より大きな課題が生じます。それは、影響を受けるコンポーネントまたは製品を、National Vulnerability Database (NVD) で割り当てられた名前で特定する方法です。 これは、ソフトウェア製品が NVD で識別されるためです。 共通プラットフォームの列挙 (CPE) 名。米国商務省の一部である国立標準技術研究所 (NIST) によって割り当てられます。
NVD は CPE を使用して、ベンダー、製品、およびバージョン文字列に基づいてハードウェアおよびソフトウェア コンポーネントを識別します。 ソフトウェア ユーザーが、使用している製品のコンポーネントに関連する脆弱性があるかどうかを NVD を介して判断したい場合、コンポーネントに割り当てられた正確な CPE 名を知っている必要があります。 ただし、オープン ソースかプロプライエタリかを問わず、特定のコンポーネントの CPE を見つけることはしばしば不可能です。
ほとんどの場合、この問題により、ソフトウェア部品表 (SBOM) の作成など、ソフトウェア セキュリティに必要なプロセスの多くを確実に自動化することができなくなります。
NVD の脆弱性を見つけるのが難しい理由
問題の範囲を理解するには、唯一の識別子として CPE に依存しているため、NVD でコンポーネントおよび製品の脆弱性を検索することが不可能ではないにしても、非常に困難になっている次の XNUMX つの条件を考慮してください。
1. 脆弱性は、「CVE-2022-12345」などの一般的な脆弱性と露出 (CVE) 番号で NVD で識別され、共通脆弱性評価システム (CVSS) を使用して各 CVE に脅威レベルが割り当てられます。 通常、CVE が割り当てられるまで、CPE はソフトウェア製品用に作成されません。 ただし、多くのソフトウェア サプライヤは (CVE を生成する) 脆弱性を報告したことがないため、NVD で製品の CPE が作成されたことはありません。
これは必ずしも製品に脆弱性が存在したことがないためではなく、開発者が既存の脆弱性を NVD に報告していない可能性があるためです。
その結果、NVD 検索では、次のシナリオの両方で「一致するレコードがありません」という応答が返されます。
(i) 特定の製品に脆弱性が存在しない
(ii) 脆弱性が存在するが、開発者によって報告されていない
2. 新しい CPE 名が NVD に入力されたときにエラー チェックが実行されないため、一貫した命名規則に従わない製品 CPE が作成される可能性があります。 その結果、ユーザーが適切に指定された CPE を使用して製品を検索すると、「一致するレコードがありません」というエラー メッセージが表示されます。 これは、元の (仕様外の) CPE 名が使用されたが、それに対して報告された CVE がなかった場合に受け取るメッセージと同じです。
ユーザーがこのメッセージを受け取った場合、検索している製品に有効な CPE があることを意味している可能性がありますが、その製品の CVE は報告されていません。入力した CPE が CPE と一致していない可能性もあります。 NVD に提出された (仕様外の) CPE 名には、実際には CVE が添付されています。
「一致するレコードがありません」というエラー メッセージは、ユーザーが検索バーで CPE 名のスペルを間違えた場合にも発生する可能性があります。 この場合、ユーザーはメッセージがタイプミスによって生成されたことを知る方法がなく、製品に脆弱性が報告されていないと想定できます。
3. 時間の経過とともに、合併または買収により製品またはサプライヤの名前が変更される可能性があり、製品の CPE 名も変更される可能性があります。 この場合、ユーザーが新しい CPE ではなく元の CPE を検索しても、新しい脆弱性について知ることはできません。 以前と同様に、「一致するレコードがありません」というメッセージが表示されます。
4. これは、「Microsoft」と「Microsoft Inc.」、または「Microsoft Word」と「Microsoft Office Word」など、サプライヤまたは製品名のさまざまなバリエーションにも適用されます。正確な正しいサプライヤまたは製品名がない場合、 NVD 検索では、誤った結果が得られます。
5. それぞれが異なる反復を使用する異なる人々によって入力された場合、同じ製品が NVD に複数の CPE 名を持つことができます。 これにより、どちらの名前が正しいかを判断することが実質的に不可能になる可能性があります。 さらに悪いことに、CPE の亜種ごとに CVE が入力されていると、「正しい」名前ではなくなります。 一例として OpenSSL があります (「OpenSSL」と「OpenSSL フレームワーク」など)。 単一の CPE 名にすべての OpenSSL 脆弱性が含まれているわけではないため、ユーザーは製品名のバリエーションごとに個別に検索する必要があります。
6. 多くの場合、脆弱性はライブラリの XNUMX つのモジュールにのみ影響します。 ただし、CPE 名は製品に含まれる個々のモジュールではなく、製品に基づいて割り当てられるため、ユーザーは完全な CVE レポートを読んで、どのモジュールが脆弱であるかを判断する必要があります。 そうしないと、脆弱なモジュールが使用されているソフトウェア製品にインストールされていないが、ライブラリの他のモジュールがインストールされている場合など、不必要なパッチ適用または軽減策が発生する可能性があります。
幸いなことに、業界を超えたグループと呼ばれる SBOMフォーラム OWASP、The Linux Foundation、Oracle などのメンバーを含む .
ソフトウェアのパッケージ URL (purl) やハードウェアの GS1 標準の採用を含むグループの推奨事項は、NVD を確実に照会し、脆弱性に関する正確な情報を受け取るための標準化された方法を作成するように設計されています。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
- 情報源： https://www.darkreading.com/vulnerabilities-threats/how-naming-can-change-the-game-in-software-supply-chain-security
