SBOM Studio

変更不可のコミットそのものがコンプライアンスの成果物となる、SBOM管理プラットフォームです。Product Release SBOMを変更不可のコミットとして記録し、サプライチェーンインテリジェンスで情報を付加したすべてのコンポーネントと、それらに影響する脆弱性を表示します。また、公開したコミットを誰が受け取るかを制御します。

はい、必要です。そもそも難しいのは生成ではないからです。多くのチームはすでにSBOMを生成していますが、それをリポジトリや共有ドライブ、SharePointに置いたままにし、中身を二度と確認しません。ファイルは存在していても、そこに記述されたリスクは読まれないままです。

SBOM Studioは、SBOMに含まれるすべてのコンポーネントの構成を把握し、そのコンポーネントデータに継続的に情報を付加して、一つひとつに影響する可能性のある脆弱性を追跡します。監視対象のプロジェクトを選択すると、Cybeatsがそれらを1時間ごとに再チェックします。これが、SBOMの統合管理基盤がもたらすものです。

はい、必要です。違いは機能の一覧ではなく、データにあります。Dependency-Trackは、CycloneDXを取り込み、公開された脆弱性情報源とコンポーネントを照合するOWASPのオープンソースプラットフォームです。SBOM StudioはCycloneDXとSPDXを取り込んだうえで、サプライヤーのデータを使える状態にする作業を行います。Quality Analysis（品質分析）は受け取ったコンポーネントデータの問題点を指摘し、Autocorrection（自動修正）はそのままでは使えないSBOMを修復します。

その後、すべてのコンポーネントに、Cybeatsのデータレイクからサプライチェーンインテリジェンスが付加されます。さらに、プラットフォーム全体が、数千件のProduct Release SBOMを扱うエンタープライズ規模で稼働するよう設計されており、公開した各Product Release SBOMは管理された形で共有できます。

コミットはCycloneDX 1.6と1.7、SPDX 2.3と3.0.1を生成します。取り込みの対応範囲はより広く、CycloneDXは1.2から1.7まで、SPDXは2.2から3.0.1までです。そのため、サプライヤーから受け取った古いファイルも読み込めます。

サプライヤーからコンポーネントの一覧がCSVやExcelのシートで届いた場合も、行き詰まることはありません。Cybeatsが開発・保守するオープンソースの変換ツールであるcsv2cdxが、そのスプレッドシートを有効なCycloneDX形式のSBOMに変換し、他のSBOMと同じように取り込めるようにします。EU CRAが求めるフォーマットとデータフィールドについては、EU CRAのSBOM要件をご覧ください。

Quality Analysisが問題を指摘し、Autocorrectionが修復します。Quality Analysisは、SBOMに記載されたコンポーネントデータの問題を報告します。また、Cybeatsが長年かけて構築したAutocorrectionの修復モジュールにより、そのままでは使えないSBOMもプラットフォームに取り込めます。この2つの機能は、StudioとConsumerの両方に共通して備わっています。

CISAの2026年版最小要素が推奨しているとおり、SBOMはビルドやリリースのたびに更新し、誤りがあれば修正してください。SBOM Studioでは、Product SBOM（製品SBOM）を必要なだけ何度でも更新できます。すべてのバージョンは変更不可のコミットとなり、公開するまで顧客には届きません。また、各顧客がアクセスできる範囲は、Product SBOMとVEXのダウンロードから閲覧のみまで、きめ細かく制御できます。

必要に応じて生成し、Product Release SBOMと対になる別ファイルとして発行します。SBOMは変更不可で、製品に何が含まれているかを示します。VEXは、そこに含まれる脆弱性のうち、実際に悪用可能なものを示します。

VEXドキュメントが正しいのは、作成された時点においてのみです。生成した数分後に、新しい脆弱性が報告されることもあります。そのため、VEXは一度保管すれば終わりの静的な成果物ではなく、動的なものとして扱う必要があります。SBOM Studioは必要に応じてVEXを生成し、サプライヤーからのVEXもインポートします。

CVEを検索すると、影響を受けるコンポーネントを搭載して出荷している製品リリースを、SBOM Studioが表示します。製品リリースに関連付けられたすべての監視対象プロジェクトについて、全コンポーネントが脆弱性情報と照合されます。そのため、手作業で突き合わせなくても、該当する製品とバージョンが具体的に示されます。

メールの添付ファイルではなく、SBOM StudioのSharing Portalを使う方法です。SBOMがファイルとして外部に出てしまうと、誰が保有し、誰が転送し、誰が読んだかを管理できなくなります。Sharing Portalでは、認証済みの顧客は、アクセスを許可された公開済みのProduct SBOMのみを閲覧できます。また、顧客ごとに、SBOMのダウンロード、脆弱性の閲覧とVEXのダウンロード、閲覧のみのいずれを許可するかを、きめ細かく制御できます。アクセスはいつでも取り消すことができ、すべての操作が記録されます。

マシンツーマシン（M2M）での交換については、Ecma TC54で標準化が進められているOWASPの仕様であるTransparency Exchange APIへの対応が、概念実証（PoC）段階にあります。

はい、サイバーデバイスについては求めています。FD&C Act第524B条(b)(3)は、製造者に対し、商用、オープンソース、既製（OTS）のソフトウェアコンポーネントを網羅したSBOMの提供を義務付けています。また、FDAの2026年2月の市販前ガイダンスは、各コンポーネントのサポートレベル（level of support）とサポート終了日も求めています。

SBOMと同じ方法で管理し、AIモデルとデータセットをカタログで扱います。SBOM Studioは、OWASP AIBOM Generatorで作成したファイルを含め、CycloneDXまたはSPDX形式のAIBOMを取り込み、同じ制御のもとで監視・共有します。

はい、両方に対応しています。そのため、すべての製品のソフトウェア、AI、暗号関連、ハードウェアのインベントリーを、4つのプラットフォームに分けることなく、1つのプラットフォームで管理できます。HBOMにはハードウェアとドライバーの専用カタログがあり、CBOMには暗号関連資産の専用カタログがあります。

CBOM（暗号部品表）は、製品が使用するアルゴリズムや鍵を一覧化します。これにより、移行が必要になる前に、量子コンピュータによるリスクにさらされているものを特定できます。HBOM（ハードウェア部品表）は、製品の動作基盤となるチップ、無線モジュール、プロセッサーを対象とします。

Magic Linkは、パッケージのリンクだけで、SBOMに不足しているOSSパッケージを追加し、SBOMの補完を支援します。npm、Maven、PyPI、GitHub、またはその他10種類のパッケージソースのリンクを貼り付けると、名前、製造者、サプライヤー、利用可能なバージョンを取得し、選択したバージョンをPackage Catalogまたはソフトウェアのバージョンに追加します。Cybeatsのエンリッチメント（情報の付加）は、データが存在する場合は、ライセンス、CPE、ハッシュ値、EOL日などの不足しているフィールドを補完します。また、既知の脆弱性を深刻度別に確認できるため、パッケージを使って開発する前の設計段階で、そのパッケージを評価できます。