目次
最新のソフトウェアは、純粋に自己開発されるのではなく、組み立てられます。デジタル アプリケーションで使用されるオープン ソース コンポーネントの割合が増加するにつれて、混合ソース開発が業界の主流の開発方法になりました。オープンソース コンポーネントの導入によりソフトウェア開発の効率は加速しましたが、ソフトウェア サプライ チェーン全体にオープンソースのセキュリティ問題も持ち込まれました。ソフトウェア コンポーネントの透明性はソフトウェア サプライ チェーン セキュリティの基盤となっており、SBOM (Software Bill of Materials、ソフトウェア部品表) はソフトウェア サプライ チェーン セキュリティ ガバナンスの重要な出発点であり、業界での適用が大幅に加速しています。
ソフトウェア サプライ チェーンのセキュリティ ガバナンス
サプライチェーンセキュリティの概要
サプライチェーン（Supply Chain）とは、生産・流通の過程でエンドユーザーに製品やサービスを提供する上流と下流の企業によって形成されるネットワークチェーン構造、つまり販売者から消費者に至るまでの製品の連鎖全体を指します。サプライチェーン活動とは、天然原料を消費者が必要とする最終製品に継続的に組み立てるプロセスを指し、製品の供給関係を表します。サプライチェーン システム全体には、人材、組織、資材、データなどが含まれます。
ソフトウェア サプライ チェーンの定義は、要件、設計、開発、構築、パッケージ化、リリース、調達、導入、運用と保守、オフラインからソフトウェア ライフ サイクルに至るまでのソフトウェア ライフ サイクル全体のリンクを指す、従来のサプライ チェーンの概念から拡張されています。破壊。通常、ソフトウェアの作成者 (サプライヤー/上流)、ソフトウェア ユーザー (消費者/下流)、およびソフトウェア オペレーター (企業または企業) が関与します。
ソフトウェア サプライ チェーンのセキュリティは、ソフトウェア サプライ チェーンに対する攻撃に関連しています。攻撃者は、ソフトウェア サプライ チェーンのあらゆる活動において、ネットワーク ツール、ダウンロード ポイズニング、コード汚染、脆弱性の悪用、認定された不正行為などの手段を使用して、企業のビジネス システムに対して破壊的な操作を実行します。近年のより深刻なソフトウェア サプライ チェーンのセキュリティ インシデントには、SolarWinds (太陽嵐) 攻撃、Realtek WiFi SDK の脆弱性、Apache Log4j2 の脆弱性などが含まれます。
リスクガバナンスの焦点
ソフトウェア サプライ チェーン プロセスにおけるリスク ガバナンスには、ソフトウェア サプライ チェーンのトレーサビリティと見通しを向上させることを目的として、主にソフトウェア ソース管理、ソフトウェア セキュリティ コンプライアンス管理、ソフトウェア資産管理、サービス サポート、セキュリティ緊急対応が含まれます。主要なガバナンス コンテンツには、ソフトウェア資産のサードパーティ コンポーネントの脅威レビューやソフトウェア セキュリティ コンプライアンス管理が含まれます。
図 1 ソフトウェア サプライ チェーン ガバナンスの主要分野
企業がソフトウェア サプライ チェーンのセキュリティ問題を効果的に解決できるようにするために、SBOM はソフトウェア サプライ チェーン セキュリティの主要な技術ツールの 1 つとして、ソフトウェア資産情報形式の統一的な記述を実現し、購入したソフトウェアと自社開発したソフトウェアのリスク評価を支援します。ソフトウェアのサプライチェーン活動を形成するソフトウェア情報インターフェース標準に合格しました。
SBOMとは
初期の SBOM の概念は製造業界に由来しており、製品に含まれるすべての品目のリストの詳細を示すために部品表 BOM が使用されていました。たとえば自動車業界では、メーカーは各車両に、OEM 製造のコンポーネントとサードパーティ サプライヤーのコンポーネントをリストした詳細な部品表を提供します。欠陥部品が見つかった場合、自動車メーカーはどの車両が影響を受けるかを正確に把握し、所有者に修理または交換を通知できます。ソフトウェア部品表 SBOM は、ソフトウェア製品に含まれるコンポーネントの材料情報を記述するために使用されます。例は次のとおりです。
図2 SBOMの例
しかし、サプライ チェーンのセキュリティ インシデントの激化に伴い、2021 年 7 月 12 日、米国は国家ネットワーク セキュリティの向上に関する大統領令 (EO 14028 セクション 10) で SBOM を「ソフトウェアの構築に使用されるさまざまなコンポーネントに関する詳細な情報が含まれる」と定義しました。 「情報とサプライチェーン関係の正式な記録」。ソフトウェア開発者とサプライヤーは通常、既存のオープンソースと商用ソフトウェアのコンポーネントを組み合わせて製品を作成しますが、新しい定義ではソフトウェアのサプライチェーン関係が記録の範囲に加わります。
図 3 コンポーネント関係図
SBOMの要素
図4 NTIA《ソフトウェア部品表（SBOM）の最小要素》
米国NTIA（国家電気通信情報局、National Telecommunications and Information Administration）は2021年7月にSBOMに含まれる最低限必要な要素をリリースした。これらの要素は次の 3 つのカテゴリに分類されます。
SBOM の最低限必要な要素は、実践プロセスにおいて最低限必要な要素を記述したものであり、関係組織・機関は、上記 3 種類の要素を参考に、企業自身が必要とする追加情報を拡充することで、自らに適した標準的な SBOM リストを作成することができる。管理する。国内のオープンソースコンポーネント管理要件とソフトウェアライフサイクルリスクの観点から、推奨される拡張データフィールドは以下のとおりです。
SBOM形式
現在、SBOM は主に 3 つの形式で実装されています。
1.SPDX
SPDX は、ソフトウェア パッケージに関連するコンポーネント、ライセンス、著作権、およびセキュリティ参照情報を含む国際オープン標準 (ISO/IEC 5962:2021) 形式です。SPDX 標準は、Linux Foundation が後援する草の根オープン ソース プロジェクトによって開発されています。現在、最新バージョン 2.3 に維持されています。詳細なライセンス情報のサポートが強化されているのが特徴です。主な出力ファイル形式には、RDF、XLS、SPDX、 YAML と JSON。
SPDX Lite は SPDX の軽量サブセットで、完全な SPDX を必要としないシナリオに適しており、オープンソース ライセンスの知識や経験がない人でも使いやすいように設計されており、SPDX 標準と特定の業界ワークフローの実際のニーズのバランスをとるために使用されます。 。
2.サイクロンDX
CycloneDX は、セキュリティ コンテキストとサプライ チェーン コンポーネントの分析専用に設計されており、アプリケーションのセキュリティ コンテキストとサプライ チェーン コンポーネントの分析に使用できる軽量の SBOM 標準です。CycloneDX は、OWASP コミュニティのオープンソース プロジェクトとして誕生し、戦略的な方向性と標準的なメンテナンスを提供するコア チームによって指導されています。現在、最新のメンテナンスはバージョン 1.4 までで、形式を拡張し、SPDX ライセンス ID、pURL などの外部識別子を統合することができ、主な出力形式には XML と JSON が含まれます。
3.SWID
SWID は、ソフトウェア製品のコンポーネントを識別し、それをコンテキストと組み合わせて、製品名、バージョンの詳細など、ソフトウェア コンポーネントに関する固有の情報を記録できる標準化された XML 形式です。SWID ラベルは、SDLC のリリース後にソフトウェア製品の一部として追加され、ラベル情報はソフトウェアのインストール時にシステム端末に追加され、製品のアンインストール後に自動的に削除されます。
SBOM の使用シナリオ
1) 大まかな分類の観点から、SBOM には 3 つの異なる使用シナリオがあります。
〇ソフトウェア製作者は、提供するソフトウェアの構築と保守を支援するために SBOM を使用します。
〇ソフトウェア購入者は、購入前の参照、割引交渉、調達戦略の策定に SBOM を使用します。
〇ソフトウェア事業者はSBOMを利用して脆弱性管理や資産管理のための情報を提供し、ライセンスやコンプライアンスを管理し、ソフトウェアやコンポーネントの依存関係やサプライチェーンのリスクを迅速に特定します。
2) エンタープライズ ロール タイプの観点から見ると、SBOM にはさまざまな使用要件があります。
〇プロジェクト チーム: ソフトウェア資産の管理、開発初期のセキュリティ リスクの評価、適切なコンポーネント/ソフトウェアの選別、SBOM の継続的な更新に使用されます。
〇セキュリティチーム：提出されたSBOMによりソフトウェアリスクを分析し、一元管理により継続的に監視し、セキュリティインシデントにタイムリーに対応します。
〇法務チーム：会社自身の権利利益を損なうことを避けるために、ソフトウェアの認証問題をチェックします。
図 5 エンタープライズ管理役割の SBOM 使用要件
SBOMの使い方
SBOMツールを選択します
統合管理を容易にするために、エンタープライズレベルの SBOM は、前述の SPDX、SWID、OWASP CycloneDX などの一貫した形式を使用する必要があります。2021 年に米国が発行した大統領令では、企業が使用する SBOM の特定の形式は義務付けられていません。これまでのところ、3 つの形式のうちどれが最適であるかの比較はなく、どの形式を使用する必要があるかについて確立された業界標準もありません。ほとんどの SBOM ツールにはコード セキュリティ スキャナーとその他のプログラムがバンドルされており、企業は独自のニーズに応じて選択する必要があります。SBOM ツールを選択するためのいくつかの提案を以下に示します。
Gartner では、SBOM を生成するツールには次の機能が備わっている必要があると推奨しています。
〇建設プロセスに組み込むことができ、SBOMを自動作成できます。
〇ソースコードやバイナリファイル（コンテナイメージなど）を解析できること。
○検出された成分に対してSCA検出を実行し、SBOMを生成します。
〇生成されたSBOMは編集可能です。
〇 SBOM を読み取り可能な形式で表示、比較、インポート、検証します。
○複数の SBOM のコンテンツを結合し、ある形式またはファイル タイプから別の形式またはファイル タイプに変換できます。
〇SBOMを使用し、APIやライブラリを通じて動作する他のツールのサポート。
SDLC で SBOM を完了する
SBOM が再定義されると、SBOM の透明性、特定のソース、普及効率が向上し、企業組織は特定の条件下で SBOM を通じて脆弱性リスクを特定し、修復できるようになります。また、SBOM は、開発者やサプライヤーがセキュリティ ソフトウェア開発慣行を SDLC 全体に適用するようガイドすることもできます。以下では、専門家が参照できるように、SBOM が SDLC でのアセンブリ プロセスを完了する方法について説明します。
図 6 「ソフトウェア ライフ サイクルと部品表組立ラインの例」
注: マテリアル (マテリアル)、メタデータ (メタデータ)、リファレンス (参照)、サプライヤー (サプライヤー)、ユーザー (コンシューマー)、サンプル Bom フラグメント (フラグメントの例)
SDLC の各段階での SBOM アセンブリの内容と方法の説明:
SBOM アセンブリ プロセスには膨大な量の手動メンテナンス作業が必要ですが、メタデータ情報ライブラリを確立し、SCA テスト ツールを利用してアセンブリを CI/CD プロセスに統合することで、実装の難易度を大幅に軽減できます。
リスクインテリジェンスにリンクされたSBOM
SBOM にはソフトウェアのコンポーネント構成情報が記録されており、サプライヤーや開発者は、SBOM リストをコンポーネント脆弱性情報分析プラットフォームに提供することで、SBOM の修復や更新を行うことができ、最新の脆弱性リスクインテリジェンスを取得できます。さらに、セキュリティ オペレータは、脆弱性インテリジェンスがプッシュされたとき、またはサプライ チェーンのセキュリティ イベントが発生したときに、SBOM リスト ライブラリを維持することで、危険なソフトウェアを迅速かつ逆に特定できるため、サプライ チェーンの攻撃イベントに対する緊急対応が迅速化されます。
図 7 SBOM を使用したソフトウェア リスク情報の生成
SBOMを中心とした管理プロセスを構築する
SBOM 形式と対応するツールが決定したら、SBOM 統合セキュリティ評価標準に基づいてソフトウェア ライフ サイクル脅威チェックポイントを確立できます。管理プロセスは企業セキュリティプロセス管理チームによって策定され、ソフトウェアサプライチェーンセキュリティ評価チームはセキュリティ評価テストを実施し、評価結果を出力する権限を与えられています。その一般的な管理プロセスの枠組みは次のとおりです。
図 8 SBOM を中心とした安全管理プロセスの確立
1. ベースラインを確立する
カウントされた資産に基づいて、後続のコンポーネントの選択をガイドするホワイトリストとブラックリストのコンポーネント ベースラインを確立します。
2. 安全設計の評価
プロジェクトの要件設計とセキュリティ レビューの段階で、選択したサードパーティ コンポーネントのリスク評価を実施し、ホワイトリストとブラックリストのコンポーネント ベースラインに基づいてセキュリティ コンポーネントを選択します。
3. アプリケーションのセキュリティテスト
コンポーネントのリスクの管理と制御に加えて、アプリケーションの起動およびリリースのプロセス中に、アプリケーション システムでアプリケーション セキュリティ テストが実行され、既存のアプリケーションの脆弱性の脅威が発見されます。
4. CI/CD 欠陥の修復と追跡
発見されたリスクを Jira、Zen Road などの CI/CD 欠陥修復および追跡プラットフォームに接続し、事前に欠陥を修復し、SBOM 内のアプリケーションの脆弱性リスク情報を更新します。
5. 製品リリース
製品アーティファクトがリリースされると、同時に SBOM が生成されます。安全管理プロセスを通じてソフトウェアおよびソフトウェアSBOMの安全性評価を実施し、安全性試験報告書を発行します。
SBOMへの思い
サプライチェーン攻撃の検出要件がハードウェア攻撃訓練スコアに追加されたことにより、ソフトウェアサプライチェーンのセキュリティ構築はますます注目を集めています。現在のソフトウェア サプライ チェーンにおけるセキュリティ ガバナンスの実装では、主にサードパーティのオープンソース コンポーネントのガバナンスが考慮されており、主に SCA ツールと関連するガバナンス手法を使用して、ソフトウェアに導入されたサードパーティのオープンソース コンポーネントに対する脅威を検出および管理します。広義のソフトウェアサプライチェーンのセキュリティガバナンスでは、ガバナンスの範囲をソフトウェアライフサイクル全体、ベンダー管理、自動プロセス構築に拡大し、継続的な運用保守監視、緊急対応能力などを備える必要がある。
SBOM の主な価値は、企業組織がソフトウェアの透明性を向上させ、ソフトウェア サプライ チェーン リンク内での交換と転送が容易なインターフェイス標準を形成するのに役立ち、同時にソフトウェア資産情報を記述することができることです。ソフトウェア資産管理における「不透明」と「維持できない」という主な問題点を解決するために、SBOM がソフトウェア資産管理機能の基盤として使用され、SBOM を中心に比較的完全なソフトウェア サプライ チェーン ガバナンス システムが確立されます。成熟した SCA ツールは、さまざまな SBOM 形式と互換性があり、さまざまなサプライヤーが提供するさまざまな形式の SBOM をインポートでき、さまざまな形式の SBOM の変換と集中管理を実行でき、自動化されたプロセスに簡単に統合できる必要があります。Xuanjing Yuanjian SCA は、上記の SBOM 機能要件を満たすことに基づいて、オープン ソース OpenSCA でパブリック SBOM 生成ツールも提供します。これは、ソフトウェア メーカーが SBOM リストを自動的に生成するのに便利です。