SBOMクイックスタートガイド

このガイドブックはソフトウェア部品表 (SBOM) の概要と、ビルド パイプラインでの使用方法を理解させるために用意しました。
Sonatype は、次のような多くの重要な機能を備えた SBOM 標準を早期に採用しています。

  • Sonatype は CycloneDX SBOM の仕様と開発に積極的に参加しています。
  • Sonatype Lifecycle は、CLI、API、UI を使用した SBOM のスキャンをサポートしています。
  • Sonatype Lifecycle は、任意のアプリケーション スキャン レポートを CycloneDX または SDPX 形式でエクスポートできます。

 

Sonatype Lifecycle は、CycloneDX 形式と SDPX 形式の両方をサポートしています。
サイクロンDX

CycloneDX は、アプリケーションで使用されるすべてのオープンソースの依存関係をレポートおよび追跡するための素晴らしい標準です。
これには、コンポーネントのハッシュ フィンガープリントと、packageUrlコンポーネントの送信元を特定するための の両方が含まれます。最近、標準には、リスクを理解するためのコンポーネントの詳細とともに基本的な脆弱性データが含まれ始めましたが、これは良いことでもあり、悪いことでもあります。
これにより、その時点で既知のセキュリティリスクが存在する可能性がありますが、SBOM の生成後に新しい脆弱性が発見されるため、誤った安全感を与える可能性があります。

SPDX

Software Package Data Exchange (SPDX) は、ソフトウェア部品表情報を通信するためのもう 1 つのオープン スタンダードであり、ライセンス情報の取得に優れており、CycloneDX の代替としての地位を確立しています。

SBOMの使用例

Sonatype の顧客が SBOM を使用して行う 3 つの主な使用例を次に示します。

  1. SBOMの消費
  2. SBOM の生成
  3. SBOMの管理
SBOMの消費

Sonatype Lifecycle は、アプリケーション分析の一部として SBOM をスキャンしたり、スタンドアロン SBOM でスキャンを実行したりできます。

分析フェーズ

Sonatype 分析は 3 つのフェーズで構成されます。

  1. ビルド中にアプリケーションに組み込まれるすべてのコンポーネントの分析
  2. 見つかったコンポーネントの ID と脆弱性データの収集
  3. そしてそのデータをガバナンスポリシーと比較してレポートの生成
ビルド分析に SBOM分析

状況によっては、SBOM を使用して分析を実行すると、ビルド アーティファクトのみをスキャンするよりも良い結果が得られる場合があります。これは、アプリケーション内で見つかったすべてを報告できるだけでなく、それらの部分がどこから来たのかをより明確に報告できるためです。SBOM は、最終的なアプリケーションには含まれなく、アプリケーションの構築履歴も提供します。これは、コンポーネント全体ではなくコンポーネントの一部が使用されるエコシステムに特に当てはまります。同様に、多くのコンポーネントで共有される共通部分に使用される最終的なソース コンポーネントをより適切に決定できます。これは、ライセンスなどのメタデータがコンポーネントのみに関連付けられており、その部分には関連付けられていない場合に重要です。

アプリケーション構築する前に SBOM 分析

課題の 1 つは、ビルド プロセス中に常に分析を実行できるわけではないことです。アプリケーションの構築方法は、最終成果物とともに保存されません。ビルドの前後にアプリケーションをスキャンしようとすると、混乱を招き、または不完全な結果が得られる可能性があります。Sonatype は、分析に SBOM を使用または含めることで、スキャン結果にコンポーネントの系統を含めることができるようにすることで、この問題を解決しました。これにより、SBOM を使用していつでもアプリケーションの分析を行うことができます。

考慮に値するいくつかの使用例を次に示します。

  • 新しいオープンソース コンポーネントに依存しすぎる前に、アクティブな開発中のソース コード マニフェストを分析してリスクを学習し、シフト レフトに移行します。
  • アプリケーションを運用環境にプロモートする場合は、新たな違反が発見されていないか確認するか、より厳格なリリース ポリシーを適用します。
  • SBOM のポイントインタイム コピーをバイナリとともにリポジトリに保存するか、必要なときにすぐにアクセスできる安全な中央リポジトリに保存します。
SBOM のベスト プラクティス
  • アプリケーションを構築するときは、パッケージ化されたバイナリとともに SBOM を生成して保存し、最終的なアプリケーションに何が組み込まれたのかを常に正確に把握できるようにします。
  • SBOM を使用してアプリケーションを展開する前に分析し、重大な脆弱性が本番環境に流出するのを防ぎます。
  • SBOM を主要な関係者と共有しますが、公開は避けたい場合もあります。

Sonatype ライフサイクル スキャナーと UI は、SBOM がファイルを SBOM として識別するために、スキャナー用の特定の命名形式を持つことを期待しています。SBOM をスキャンする場合は、次の命名形式を使用します。そうでない場合、スキャンではファイルが無視されます。プレフィックスと最初のダッシュはオプションであり、それに応じて正しいファイル タイプを使用する必要があります。プレフィックスは、不明なコンポーネントのアイデンティティ ソースとして使用されます。

SBOM のスキャン-CL
  • CLI を使用してコマンド ライン スキャナーでアプリケーションをスキャンする方法については、CLI ドキュメントを参照してください。
  • 上記の命名要件に従ってフォーマットされた SBOM を直接ターゲットにするか、ビルド中にアプリケーションの残りの部分とともにスキャン コンテキストのルートに SBOM を含めます。
  •  SBOM のスキャンの詳細については、  「CycloneDX アプリケーション分析」ページと「SPDX アプリケーション分析」ページを参照してください。
 SBOM のスキャン-API

SBOM は、サードパーティ REST APIを使用して直接アップロードすることもできます。

  1. 呼び出しのデータ ターゲット (-d) として SBOM を含む REST 呼び出しの例です。

    1. sbom がどこから供給されているかを識別するために、ソース パラメーターに「cyclonedx」を使用しています。
      (SPDX コンテンツ スキャンのソース パラメーターには「spdx」を使用できます)

    2. または、ヘッダーで「application/json」を使用して、JSON ファイルをアップロードします。

      curl - u {ユーザー}:{パスワード} - X POST - H "Content-Type: application/xml" - d '{bom_text}' 'http://localhost:8070/api/v2/scan/applications/{applicationid) }/sources/cyclonedx'
  2. 結果を監視するために statusUrl が返されます。

    1. 結果が準備できるまで、statusUrl への呼び出しを繰り返します。

    2. 分析には通常、レポートが返されるまでに約 20 秒かかりますが、大規模なプロジェクトの場合は数分かかります。

      { "statusUrl" : "api/v2/scan/applications/{applicationId}/status/{statusId}" }
  3. スキャンの詳細は、ポリシー アクションおよび完全な結果を確認できる { reportHtmlUrl } とともに返されます。
SBOM のスキャン-UI

UI を使用してアプリケーションの SBOM をスキャンできます。

  1. [組織とポリシー] タブに移動し、スキャンするアプリケーションを見つけます 。(そこにない場合は追加する必要がある場合があります)。
  2. 右上の「アクション」で、「ファイルを評価する」オプションを選択します。
  3. ファイルの選択オプションから、上記の命名要件を満たす SBOM を見つけ、ステージを選択して、[アップロード] ボタンを選択します。
  4. 「レポートの表示」を選択します。

SBOM の生成

大統領令への準拠に取り組んでいる場合でも、依存関係データを報告するための標準的な方法が必要な場合でも、Sonatype ツールを使用して SBOM を作成するのは簡単です。Sonatype ツールによって生成された SBOM は、NIST によって報告された必須基準と一致しています。

NIST SBOM 基準 Sonatype のライフサイクル
SBOMの完全性 直接/推移的な OSS 依存関係
SDLCの統合 SBOM とソフトウェアのリスクを示すビルド、リリース、デプロイメントを使用した分析
SBOMの精度 正確なコンポーネントデータをレポートし、バイナリと照合します
統合リスク分析 nレベルの依存関係における既知の脆弱性を特定する
悪意のあるコードの検出 (偽造コンポーネント、隠れた機能) 統合されたコンポーネントリスクスコアリングベースのコンポーネント分析による既知の脆弱性の特定、機械学習アルゴリズムによる未知の脆弱性の検索

すべての Sonatype スキャン レポートは、CycloneDX または SPDX SBOM として XML ファイルまたは JSON ファイル形式でエクスポートできます。これは、スキャン レポートの UI で、または REST API を介してプログラムで実行できます。

SBOM のエクスポート-UI

UI を介して SBOM を取得します。

  1. 最新のアプリケーション スキャン レポートに移動します
  2. [オプション] メニューから選択します。
    1. CycloneDx のエクスポート – CycloneDx SBOM は XML ファイルとしてダウンロードされます。
    2. SPDX のエクスポート –165 の新機能SPDX SBOM は JSON ファイルとしてダウンロードされます。

SBOM のエクスポート-REST API

CycloneDx SBOM の取得例。IQ Server の CycloneDX REST APIに関するドキュメントを参照してください。

curl - u admin : admin123 - X GET - H 'Accept: application/xml' - o 'bom.xml' 'http://localhost:8070/api/v2/cycloneDx/1.4/{applicationInternalId}/stages/build'

SPDX SBOM を取得する例。IQ Server の SPDX REST APIに関するドキュメントを参照してください。

curl - u admin : admin123 - X GET - o 'spdx.xml' 'http://localhost:8070/api/v2/spdx/{applicationInternalId}/stages/build?format=xml'
スキャン前のCycloneDX SBOM生成

CycloneDXを使用して、ソース コードから SBOM を生成できます。これらは、アプリケーションのビルド コンテキストを使用して、コード内で参照される宣言された依存関係と推移的な依存関係のリストを取得します。ビルド プロセスの一部としてツールを使用して、Sonatype の評価に含めることができます。当社のアナライザーは、これらの結果をコード内で検出されたものと組み合わせて、アプリケーションの完全な部品表を取得します。

サードパーティの SBOM に関する重要事項
  • サードパーティ ツールの結果は、当社の内蔵アナライザーとは異なる場合があります。
    • 何がコンポーネントであり、何がコンポーネントではないかを判断するために、さまざまな方法が使用される場合があります。
    • 彼らは誤って報告したり、私たちの分析から拒否された不完全な血統データを含んでいる可能性があります。
    • マニフェストで報告されたコンポーネントのみが含まれる場合がありますが、ソース内の名前が変更されたコンポーネントや埋め込まれたコンポーネントは欠落しています。
    • 開発範囲で使用されるコンポーネントのうち、最終アプリケーションには含まれないことが多いコンポーネントを含めたり除外したりする場合があります。

ベスト プラクティスとして、さまざまなアナライザーの結果を比較して、どのモデルが要件や期待に最も適合するかを判断することをお勧めします。結果に満足したら、その方法を組織全体で標準化し、ビルド ライフサイクル全体で一貫性を維持することをお勧めします。

SBOMの管理

ポートフォリオから生成した SBOM をどのように管理および使用するかを決定する必要があります。これまでのところ、業界全体がこれを行うための最良の方法を標準化していません。ここでは、パートナーとの成功例をいくつか紹介します。

SBOM の保存

組織は、Nexus リポジトリなどのバイナリ リポジトリを使用して、プライベートでホストされているリポジトリに構築されたアーティファクトを保存および管理します。

  • SBOM を Java アプリケーションとともに Maven リポジトリに保存して、すぐに参照できるようにすることができます。
  • 非 Java アプリケーションの場合は、簡単にアクセスできるように、SBOM を raw リポジトリにアップロードすることを選択できます。
  • 事前に計画を立て、SBOM に明確な名前空間とリリースの詳細を使用して、管理を容易にします。
  • Tagging API を使用して、リリース メタデータをリポジトリ内のコンポーネントに関連付けることができます。

OWASP CycloneDX は、組織全体で SBOM をより適切に管理するために、BOM Exchange API を開始しました。詳細については、BOM リポジトリ サーバーを確認してください。

依存関係の検索

どのアプリケーションの特定の依存関係が使用されているかを見つけようとするときは、すべてのアプリケーション SBOM をエクスポートして開く必要を避けるために、IQ Server Advance Search から始めてください。
詳細については、「ゼロデイ脆弱性のベスト プラクティス」をご覧ください。

組織の依存関係を分析する

IQ Data Insight – Stack Divergence ツールは、組織全体のコンポーネント トレッドを分析するのに最適です。

まとめ

ソフトウェア サプライ チェーンに SBOM セキュリティを提供するようベンダーに義務付ける大統領令に関する話題を聞いたことがあると存じます。
SONATYPE創業以来、オープンソース リスクの識別と管理を自動化することを焦点を置きました。
詳しい内容は、DevSamuraiまでお問い合わせくださいませ。

Sonatype は、多様なソフトウェア サプライ チェーンを持つ組織に最適です。セキュリティ、ライセンス、運用上のリスクも持ち込まれていなく、製品スイートを統合するためのリソースを持ち、あらゆる組織がリスク無しに継続的に活用できるように支援することに重点を置いており、その実現のために様々な製品群を開発しています。すべてのライブラリとソフトウェア サプライ チェーンを保護できる技術ことで自慢しています。

 

SON_Partner_Portal_Page_Gold_partner_badge@2x

DevSamuraiは、Sonatypeのゴールドパートナーとして日本国内で同社製品を販売し、インストール、設定、テクニカルサーポートなどの導入支援サービスを提供しています。


お問い合わせボタン1

 

 

前の投稿
Nexusプラットフォーム機能でセキュリティ確保
次の投稿
管理チームの目標に合うJIRA サービス
メニュー