APP / APP-04
依存関係とソフトウェアサプライチェーンセキュリティ — SCA/SBOM
ソフトウェア製品の構成要素を把握し、来歴、脆弱性、およびアップデートを管理します。SBOMは構成要素を記述するものであり、セキュリティを維持するために使用・維持されなければなりません。.
役立つとき
的確な回答
定義されたニーズに対して.
多くのオープンソース依存関係、ソフトウェアの部品表に対する顧客の需要、サプライヤーの不具合、または脆弱なコンポーネントを使用して製品を特定できないことなどです。.
適用範囲と成果物
このエンゲージメントの対象範囲.
スコープ
- コンポーネント在庫
- 直接的／転置的な依存関係
- SBOM
- 脆弱性分析
- 資料品の起源
- 必要に応じて署名
- アップデート
- 例外処理
成果物
- バージョン関連 SBOM
- 依存関係登録
- コンテクストに基づく優先順位付け
- 起源政策
- アップデートプロセス
- 確認の証拠とカバー範囲の制限
検収証拠
対象バージョンにおける SBOM は再現可能であり、重要なコンポーネントが特定されている。テストアラートが影響を受ける製品にマップされる。アップデートおよび例外処理が機能している。.
配達
仕事の進め方.
アプローチ
アーキテクチャを理解する；リスクと要件を選択する；制御を統合または検証する；テストする；チームに引き渡す；回帰チェックの計画を行う。.
前提条件と責任
顧客：コード、アーキテクチャ、開発者、テスト環境、およびパイプラインへのアクセス。プロバイダー：専門知識とチェック。コードの修正は含まれている場合のみ。.
スコープ要因
アプリケーション、言語、リポジトリ、依存関係、ロール、パイプライン、ボリュームと深度。個別のツールライセンス、修復開発、保守。.
確認のための質問
各バージョンのコンポーネントを再構築することは可能ですか？リリース後に脆弱性を追跡するのは誰ですか？画像やバイナリ内の依存関係は表示可能ですか？
重要な境界線
脆弱なコンポーネントの存在が常に悪用可能であるとは限らず、SBOM の不完全な部分からその存在が確認されるわけでもありません。ソフトウェアのライセンスには別途分析が必要となります。.
管理策は、合意されたバージョンおよびスコープに適用されます。スキャナー、SBOM、フレームワークのいずれ単体でも、納品されるソフトウェアのセキュリティを保証するものではありません。.
実際には
具体例.
これらの例は、想定される関与と目標とする成果について説明したものであり、顧客の事例や達成された実績ではありません。.
シナリオ01
ベンダーが一般的なライブラリに関するアラートを受け取ります。 プロジェクト：SBOMを出荷済みのバージョンに照らし合わせて評価し、脆弱性を評価します。 ターゲットアウトカム：カタログ全体に統一された対応ではなく、修正すべき製品の正当なリストを作成します。.
シナリオ 02
顧客がサプライヤーからSBOMを要求する。 プロジェクト：フォーマット、バージョン管理、結果の利用方法を定義する。 ターゲット成果：実行可能な情報。不完全なまたは古いSBOMは、保証として扱われるのではなく、フラグ付けされる。.
技術と参照コンテキスト
例：SCA/SBOMおよびプロビジョン検証ツール；NIST SSDFの実践手法（スコープ定義時に形式と連携が定義される）。.
最終的なテクノロジーセットは、相互運用性、ライセンス、アクセス権、および運用要件に基づき、スコープ設定の段階で合意されます。.
コネクテッドサービス
次のステップを構築する。.
これらのサービスはエンゲージメントを補完するものであり、自動的には含まれません。.
会話を始めましょう。
スコープを明確にする。.
このサービスの目的、依存関係、および責任範囲を明確にした上で、納品を提案いたします。.