״ソフトウェアベンダーは責任を負わなければならない 彼らが消費者、企業、または重要なインフラ提供者に対して負う注意義務を果たさない場合、״（ホワイトハウス）。
今日、ソフトウェア プロバイダーは、契約上の合意、ソフトウェアのリリースとアップデート、通知、脆弱性の軽減を通じてソフトウェアの完全性とセキュリティを確保することに対して、より大きな責任を負うことが期待されています。最近、分野横断的な作業グループである ESF (Enduring Security Framework) は、ソフトウェア サプライ チェーン内でのセキュリティ対策の導入を支援するために、推奨されるベスト プラクティスと標準を含むガイダンスを発行しました。この記事では、トリアージと優先順位付けのための効果的なメカニズムとして SBOM 主導のリスク スコアリングを利用するという実際的な推奨事項についてさらに詳しく説明します。
ソフトウェアのサプライチェーンを侵害する一般的な手法は、ソフトウェア設計の欠陥の悪用、ソフトウェア製品への脆弱なサードパーティ製コンポーネントの組み込み、ソフトウェア製品の最終納品前にサプライヤーのネットワークに悪意のあるコードを侵入させる、導入されたソフトウェアに悪意のあるソフトウェアを注入するなど、依然として存在しています。顧客環境で。
ソフトウェア部品表 (SBOM) は、ソフトウェア セキュリティとソフトウェア サプライ チェーンのリスク管理における重要な要素として浮上しています。 SBOM はネストされたインベントリとして機能し、ソフトウェア コンポーネントを構成する要素のリストを提供します。
SBOM を大規模に運用するには、システム導入、製品開発、ソフトウェア ベンダーと消費者間のデータ交換におけるツールの自動化と標準化が必要です。
機械可読な重要な部分がいくつかあります SBOM標準フォーマット 業界から支持されています。 CycloneDX と SPDX は、SBOM の作成、分析、共有方法を定義します。 VEX は、製品が既知の脆弱性の影響を受けるかどうかを示すセキュリティ勧告の補完的な形式です。したがって、この脆弱性が SBOM に存在する場合でも、製品が特定の脆弱性の影響を受けていないことを示すという利点があります。
企業内に展開されているソフトウェア製品間で SBOM コンテンツを関連付けることで、アプリケーションのセキュリティ、インシデント対応およびフォレンジック チーム、リスク管理、および調達に対する強力な洞察を得ることができます。組織は、効果的な方法で管理する必要がある外部データを利用するだけでなく、社内製品用に大量の SBOM データを生成および管理することが期待されています。したがって、サポートする必要があります プロセス SBOMの自動化-主導型リスク管理 大規模に。
SBOM とリスクスコアリングの使用
リスク スコアリングは、SBOM コンテンツから派生した要約された概要を生成する手段として機能し、外部データ ソースとの迅速な比較を可能にし、受信した SBOM と優先順位付けに基づいた迅速な意思決定を促進します。
- SBOM は透明性を高め、それによって顧客組織のソフトウェア資産管理、パッチ管理、技術的負債ギャップの特定、および脆弱性管理を改善します。また、コンポーネントの出所を抽出して整合性と信頼性を検証する可能性も秘めています。
- 企業内に実装されているソフトウェア製品間での SBOM コンテンツの調整を分析すると、インシデント対応チーム、リスク管理、調達プロセスの検証に貴重な洞察が得られます。
SBOM を大規模なリスク情報に変える – リスクスコアリングの理論的根拠
すべての AppSec プロフェッショナルと CISO にとって重要な課題は、製品とサービス全体にわたるアラート疲労を管理することです。サードパーティのソフトウェアコンポーネントから生じる外部リスクの評価を含みます。
導入の主な障壁は、契約上のサポートやライセンスベースのサポートが期限切れであることです。これらのサポートは、ダウンストリームのパッチや製品アップデートの利用可能性に影響を与える可能性があり、また、オープンソースかクローズドソースかにかかわらず、ソフトウェア製品内の依存関係の複雑さが急激に増大しています。
A リスクスコア ソフトウェアとそのコンポーネントの現在および将来のリスクを予測するために使用される指標であり、大規模な優先順位付けを効果的にサポートできます。
リスクスコア = 確率 x 影響
リスク スコアリングを使用すると、組織は定義されたリスク要因に基づいてソフトウェア サプライ チェーンのリスクを理解し、企業内の特定のソフトウェア製品の潜在的な将来のリスクを予測できます。
有効なリスク スコアは 1 ～ 10 のスケール (CVSS やスコアカードなど) であるため、参照しやすいようにすべてのリスク コンポーネントを 1 ～ 10 のスケールに揃えることができます。
集計されたリスクスコア: 多くの複雑なシステムやシステムのシステムでは、集合的なソリューションの一部として複数の SBOM が存在し、したがってリスク スコアの集合が存在することがあります。
リスクスコアリングのコンポーネント:
1.脆弱性: CVE 列挙を使用した既知の脆弱性のマッピングと NVD、OSV、Github Advisories などの利用可能なフィードからの CVSS スコア。
2. ベンダーからのコンテキスト: 使用状況に応じて脆弱性スコアリングの決定を変更する可能性があるベンダーからの VEX および助言コンテキスト。 SBOM を脆弱性にリンクするとリスクフラグが有効になり、VEX ドキュメントにより消費者は脆弱性に優先順位を付けることができます。
3.EPSS 3.0: FIRST による悪用可能性メトリック。今後 0 日間の悪用の確率 (1.0 ～ 30) を予測します。これは効果的です 追加の尤度層 CVSS スコアは、最初に処理する最も重要な CVE に優先順位を付けるのに役立ちます。
4.ケブ: CISA はまた、今日では CISA KEV (悪用可能な既知の脆弱性) カタログ. このカタログには、CISA によって悪用された、または積極的に悪用されたと確認された、特定されたすべての CVE の約 5% が含まれています。したがって、これは、影響の大きい脆弱性を優先して対処するための良い出発点となります。さらに、これは、新しいバージョンのリリースの最終承認前に検証するチェックリストの一部です。
5. 脅威インテリジェンス – さらに追加 脅威と脆弱性のソースは既知の悪意のあるパッケージをフィードします (例: Snyk、Sonatype、Graynoise などからのプライベート フィード)
6. OSS の評判: オープン SSF スコアカードは、オープンソース プロジェクトのソース コード、ビルド、依存関係、テスト、プロジェクト メンテナンスの評判 (1 ～ 10 の評価) を含む、ソフトウェア サプライ チェーンのさまざまな部分に影響を与えるパフォーマンス測定メトリクスを個別に評価します。
7. 長期にわたるパフォーマンス: 製品/パッケージ バージョンの MTTR (平均修復時間) 重大な脆弱性は、セキュリティ リスク パフォーマンスの関連指標を与える可能性があります。
8。 影響 そしてコンテキスト。この側面では、ソフトウェア製品のビジネス コンテキストに基づく優先順位付けは、脆弱性フォレストの優先順位付けとトリアージに役立ちます。
いくつかの例は次のとおりです
- モジュール/製品の重要度: これはミッションクリティカルですか (機密性または重要性)
- 特定の脆弱性がある製品はいくつありますか?
- サービス/コンポーネントの外部性の露出
9. コンプライアンスの危険 – ライセンス: プロプライエタリ ソフトウェア ライセンスとオープンソース ソフトウェア ライセンスはどちらも、組織の法的ポリシーの遵守を検証するために重要です。
リスク スコアリング レイヤーの概念 – SBOM へのリスク メトリックの追加:
- 開始 SBOM データに基づく CVE 列挙と CVSS スコアを使用します。
- VEX コンテキストを使用および追加して、重要度の優先順位を再設定する
- 高い EPSS スコア (つまり 0.6 ～ 1.0) で CVE を評価します。
- KEV リストの優先順位付け – ～ まずはアドレス。
- OpenSSF レピュテーション スコア (1 ～ 10) によって評価 – 危険な依存関係を特定します。
- 解析 暴露 外部ネットワークへ (CVSS ベクトルを使用)
- 評価するとリスクが蓄積される 製品数の量 脆弱性ごとに。
- によって評価します ラベル ビジネスに対する特定のコンテナ SBOM の重要性。
- 識別する コンプライアンス違反 会社のライセンス ポリシーに従って SBOM 依存関係分析を使用する場合のリスク。
- 共有して データを管理する as アテステーション API および機械読み取り可能を介して、Jira などの他のシステムへのワークフローを備えた共同プラットフォームで。
実際のユースケースでのリスクスコアリングによる SBOM の活用:
- リスク指標を使用して製品全体のパッチ適用作業計画に優先順位を付けることで、製品の脆弱性を継続的にトリアージします。
- リスク指標に基づいて製品を並べて比較します。
- 導入/リリース前に、新しいバージョンの更新を比較して承認します。
- 製品バージョンのリスクスコアしきい値を使用して、技術的負債のギャップを追跡します。
- 最も重要な製品にわたる上位 50 のリスクのクイック レポートを作成します。
- 悪用された脆弱性が実際に見つかった場合に、インシデント対応を加速するための影響分析。この場合、 時間が重要です 私がどのような影響を受けるか、そしてこの暴露のヒート マップの爆発半径はどれくらいになるかをすぐに特定するためです。
効果的なリスク管理のために Scribe Hub プラットフォームを使用する方法:
- 一元化されたSBOM管理プラットフォーム – 脆弱性、VEX アドバイザリ、ライセンス、評判、悪用可能性、スコアカードなどのセキュリティ側面とともに SBOM を作成、管理、共有します。
- 安全なソフトウェアを構築して導入する – CI/CD パイプラインのすべての段階でソース コード、コンテナ イメージ、アーティファクトに継続的に署名および検証することで改ざんを検出します。
- SDLC セキュリティを自動化および簡素化 – リスクをコントロールする ソフトウェア ファクトリでセキュリティとビジネス ロジックを自動化されたポリシーに変換し、ガードレールによって適用することでコードの信頼性を確保します。
- 透明性を有効にします。配送速度の向上 – セキュリティ チームに責任を遂行する能力を与え、開発チームの成果物を妨げることなくセキュリティ管理を合理化します。
- ポリシーを強制します。コンプライアンスの実証 – SDLC ポリシーとガバナンスを監視および施行して、ソフトウェア リスク体制を強化し、ビジネスに必要なコンプライアンスを実証します。
のXNUMXつの例 スクライブハブ リスク分析機能は次のとおりです。
SBOM ごとにマッピングされた脆弱性、CVSS、VEX、EPSS、および KEV データによるリスク スコアリング。
特定された重要な脆弱性を修復する平均時間を MTTR として示す、長期にわたる SBOM バージョンのパフォーマンスの時系列。
まとめ
SBOM 主導のリスク スコアリングにより、組織は、事前定義されたリスク要因を評価し、企業内の特定のソフトウェア製品に関連する潜在的な将来のリスクを予測することで、サプライ チェーンのリスクを評価できるようになります。リスク スコアは、ソフトウェアとそのコンポーネントに関連する現在および将来のリスクを予測するための定量的な尺度として機能します。
このスコアリング指標は、SBOM、VEX などのフィードをソースとする指標から導出されており、サプライ チェーン リスク管理 (SCRM) をサポートするコンテンツと一致しています。リスク スコアを適用または評価する場合は、ソフトウェアの使用状況、ソフトウェアへのアクセスまたは分離の方法、ソフトウェアがサポートするプロセスとシステムなどの要素を考慮する必要があります。
Scribe Hub は、SBOM の抽出、管理、証明書収集、およびリスク スコアリング分析を大規模に行うために設計された共同プラットフォームとして機能します。このプラットフォームは、複数の外部データ フィードを効率的に処理して、複雑なシステムやソフトウェア製品の複雑さを処理します。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
