セキュリティ強化のためのSysdig CNAPP戦略の中核要素としてのSBOM

本文の内容は、2024年2月8日にJOSEPH YOSTOS が投稿したブログ（https://sysdig.com/blog/sbom-in-sysdigs-cnapp-strategy-for-enhanced-security/)を元に日本語に翻訳・再構成した内容となっております。

ペースの速いアプリケーション開発の世界では、オープンソースコンポーネントを使用することで、洗練されたアプリケーションを構築するための近道が提供されます。ただし、このアプローチでは、ソフトウェアの構成、ライセンス、セキュリティに関する重大な疑問が生じます。

新しいアプリケーションを本番環境やステージング環境にプッシュする前に、アプリケーション所有者とともにセキュリティチームとコンプライアンスチームは、次のことに取り組む必要があります。

ソフトウェア内の特定のコンポーネント。
使用されているオープンソースライブラリ
アプリケーションの内部依存関係
サードパーティのライブラリを含む脆弱性をスキャンする

ここで、ソフトウェア部品表 (SBOM) の重要性が明らかになります。SBOM は、イメージコンポーネントの単なる標準化されたリストではありません。これは、クラウドネイティブアプリケーションの安全性、準拠性、信頼性を確保するために必要です。

Gartner は、最新の CNAPP マーケットガイドで、クラウドネイティブアプリケーション保護プラットフォーム (CNAPP) のコアコンポーネントの 1 つとして SBOM をリストしています。

このブログでは、Sysdig が脆弱性管理ワークフローのコアコンポーネントとして SBOM を使用してイメージ (コンテナとホスト) のコンテンツを理解し、このコンテンツをコンプライアンス監査と規制監査で抽出できるようにする方法について説明します。

SBOM 抽出による VM スキャンの進化

SBOM の概念は新しいものではありません。オープンソースコミュニティは 10 年以上前に SBOM を作成する必要性を認識していました。2010 年に開始された Software Package Data Exchange (SPDX) オープンスタンダードは、この問題に取り組むための初期の取り組みとなりました。

SBOM が採用される前は、コードの依存関係の理解に顕著なギャップがあり、アプリケーションセキュリティチームにとって大きな課題となっていました。SBOM を脆弱性管理ツールに統合することでこのプロセスに革命が起こり、アプリケーションとその依存関係 (サードパーティのライブラリやフレームワークを含む) の両方を包括的にスキャンできるようになりました。

SBOM は、セキュリティの強化以外にも、脆弱性管理に必要なリソースを大幅に削減するなどの追加の利点を提供します。

SBOM の基礎をさらに詳しく知りたい場合は、こちらの記事でさらに詳しく調べることを検討してください。

SBOM を Sysdig の脆弱性管理プロセスに組み込む

すべての Sysdig Vulnerability Management スキャンオプション (エージェントベース (CLI スキャナ、クラスタ、ホスト、レジストリ) とエージェントレスの両方) に、スキャンされたソースまたはイメージリポジトリから SBOM を抽出する機能が含まれるようになりました。そして、SBOM は他のコンテキストおよびプロファイリングデータとともにバックエンドに送信され、脆弱性検出プロセスが完了します。

すべてのイメージは、 CycloneDX標準と互換性のある SBOM 形式に抽出されます。

初期スキャンの後、SBOM が抽出され、SBOM データベースに保存されると、後続のスキャンリクエストごとに、API 経由で現在の SBOM を取得するようスキャンエンジンに指示されます。次に、この SBOM 内のリストされたすべてのコンポーネントをスキャンしてから、スキャン結果を送り返します。

このワークフローには、次のような複数の利点があります。

リソース効率:
- 脆弱性照合、ポリシー評価、その他のプロセスが Sysdig バックエンドで実行されるため、顧客側で使用されるリソースが大幅に削減され、クライアントシステムの負荷が最小限に抑えられます。
- SBOM が保存されると、同じ SBOM を持つ別のイメージが見つかった場合、SBOM の抽出とダウンロードは必要なくなり、時間とリソースが節約されます。
クライアントロジックの簡素化: 脆弱性照合部分などのクライアントコンポーネントから多くのビジネスロジックが削除され、顧客側でクライアントコンポーネントを更新する必要性が軽減されます。これは、クライアントコンポーネントを更新することなく、クライアントコンポーネントが脆弱性照合、ポリシー、リスク受容、リスクスポットライトに最新のロジックをすでに使用していることも意味します。

エクスポート機能の拡張: SBOM API 統合によるコンプライアンスの合理化

Sysdig は最近、広く認識されている CycloneDX 形式を利用して、APIを介して Sysdig SBOM データベースから直接 SBOM をエクスポートする機能を導入しました。この進歩は、コンプライアンス要件を満たし、規制監査を促進するために特に重要です。

CycloneDX は、SBOM データのシームレスな交換と統合のためにさまざまなリポジトリやプラットフォームで採用されている標準化された形式です。Sysdig は、SBOM をこの形式でエクスポートできるようにすることで、他のサプライチェーンセキュリティツールとの統合を大幅に容易にし、全体的なコラボレーションとコンプライアンスを強化します。

特定のイメージの SBOM を抽出するには、次のような簡単な API クエリを使用できます。

curl --request GET \

 --url 'https://secure.sysdig.com/secure/vulnerability/v1beta1/sboms?assetId=sha256:c276a3cc04187ca2e291256688a44a9b5db207762d14f21091b470f9c53794e2&assetType=container-image' | jqCode language: JavaScript (javascript)

このクエリでは次のようになります。

‘assetId’ は、SBOM が取得される資産の一意の識別子を指します。
‘assetType’ はアセットのタイプを指定します。「container-image」または「host」のいずれかです。
‘bomIdentifier’ は、単一の SBOM の ID を指定するために使用されます。

API 経由で SBOM をクエリする場合、‘bomIdentifier’ を単独で指定するか、 ‘assetId’ と ‘assetType’ の両方を指定して目的の SBOM を取得するかを選択できます。

SBOMの詳細とレイヤー分析

抽出されたすべての SBOM 内で、いくつかの異なるレイヤーとコンポーネントのタイプが特定され、それぞれがソフトウェアの全体的な構造と機能に貢献します。SBOM に含まれるレイヤーとコンポーネントの内訳は次のとおりです。

オペレーティングシステム層:

SBOM は “operating-system” コンポーネントを指定します。次の例では、Debian バージョン “12.2”です。これはソフトウェアの基礎レイヤーを形成し、他のコンポーネントが構築され相互作用する基本環境を示します。

{

      "bom-ref": "1c32decb-cdcf-43a8-b0f5-ad78f376ff9e",

      "type": "operating-system",

      "name": "debian",

      "version": "12.2"

    },Code language: JavaScript (javascript)

ライブラリコンポーネント:

各ライブラリは、システムに含まれる異なるソフトウェアパッケージを表します。これらのライブラリには、アプリケーションが依存する必須のツールとユーティリティが含まれています。各ライブラリは、その特定のバージョンとパッケージ URL (purl) で詳細に説明されており、ソフトウェアの依存関係を明確に把握できます。

{

      "bom-ref": "209522c2-79e8-48ec-a95f-ca1ec69243cf",

      "type": "library",

      "name": "adduser",

      "version": "3.134",

      "purl": "pkg:deb/debian/[email protected]?distro=debian-12.2&upstream=adduser&upstream-version=3.134",

    },Code language: JavaScript (javascript)

パッケージレベルレイヤー情報:

SBOM は、各パッケージの詳細なレイヤー情報を提供します。“sysdig:layer:digest” や“sysdig:layer:index” などのプロパティが各コンポーネントに含まれており、コンポーネントが存在するレイヤーの一意の識別子 (ダイジェスト) とレイヤースタック内のその位置 (インデックス) を示します。この情報は、アプリケーションの構築方法を理解し、ビルドプロセスのどこに各コンポーネントが導入されるかを正確に特定するために重要です。

"properties": [

        {

          "name": "sysdig:layer:digest",

          "value": "sha256:cb4596cc145400fb1f2aa56d41516b39a366ecdee7bf3f9191116444aacd8c90"

        },

        {

          "name": "sysdig:layer:index",

          "value": "0"

        },Code language: JavaScript (javascript)

インストールパス:

SBOM 内の各コンポーネントのエントリには、システム内のパッケージの場所を示す “installPath” が含まれています。たとえば、リストされている多くのコンポーネントの “installPath” は “var/lib/dpkg/status” であり、これは Debian ベースのシステムのパッケージメタデータの一般的な場所です。この詳細は、ソフトウェアコンポーネントがどこに保存されているか、およびファイルシステム内でどのように構成されているかを特定するのに役立ちます。

{

 "name": "sysdig:package:installPath",

 "value": "var/lib/dpkg/status"

}Code language: JSON / JSON with Comments (json)

まとめ

まとめとして、Sysdig の CNAPP 戦略への SBOM の統合は、クラウドネイティブアプリケーションの保護における大きな進歩を表しています。SBOM に CycloneDX 標準を採用することで、Sysdig は脆弱性管理を強化するだけでなく、コンプライアンスプロセスも合理化します。SBOM を直接エクスポートできるため、コラボレーションが強化され、透明で安全なソフトウェアサプライチェーンが確保されます。この戦略的な動きは、進化し続けるデジタル環境においてクラウドネイティブのセキュリティを推進するという Sysdig の取り組みを示しています。