暗号部品表(CBOM, Cryptographic Bill of Materials)
1. 概要
定義: 暗号部品表(CBOM, Cryptographic Bill of Materials)とは、システムを構成する暗号アルゴリズム・鍵・証明書・プロトコル・暗号ライブラリと、それらの間の依存関係を、バージョン・パラメータ・セキュリティ強度・使用箇所とともに機械可読形式で記録した暗号資産インベントリである。
従来のソフトウェア部品表(SBOM)は、アプリケーションを構成するパッケージ・ライブラリ・コンテナを識別し、サプライチェーンの可視性を高めることに集中している。 しかしSBOMは「どのライブラリを使うか」は示すが、「そのライブラリが実際にどの暗号アルゴリズムを、どの鍵長で、どこで使うか」までは説明しない。 たとえば同一のOpenSSLバージョンを使っていても、あるサービスはRSA-2048でTLSハンドシェイクを行い、別のサービスはハードコードされたMD5で完全性を検証していることがあるが、SBOMだけではこの差異を区別できない。
CBOMが登場した背景には、量子コンピュータの発展とそれに伴う移行の圧力がある。 十分に大きな誤り耐性量子コンピュータが登場すれば、ShorのアルゴリズムによってRSA・ECCのような公開鍵暗号が無力化され、いま窃取して保存した暗号文を将来復号する「Harvest Now, Decrypt Later」という脅威が現実化する。 これに対しNISTは2024年にFIPS 203(ML-KEM)・FIPS 204(ML-DSA)・FIPS 205(SLH-DSA)で耐量子暗号(PQC)標準を確定し、移行ロードマップ(NIST IR 8547など)では量子脆弱アルゴリズムを2030年ごろ非推奨(deprecated)、2035年ごろ使用不可(disallowed)へと段階的に押し出す方向を示している(詳細な日程・ドラフト/最終の別は原文での確認が必要である)。
問題は、多くの組織が「自らがどの暗号を、どこで、どのパラメータで使っているか」すら正確に把握していない点である。 インベントリがなければ移行対象の範囲を見積もれず、移行の優先順位を決められず、移行完了の有無も証明できない。 CBOMはまさにこの「暗号可視性」の空白を埋める標準化されたインベントリであり、暗号アジリティ(Crypto-Agility)とPQC移行の前提条件かつ出発点である。
本答案では、CBOMの構成原理とデータモデル、生成・運用ライフサイクル、SBOMとの関係と相違、暗号アジリティおよびPQC移行との連携、そして技術士の観点からの導入戦略と考慮事項を論述する。
2. CBOMの構成原理とデータモデル
2.1 なぜ「構成要素の一覧」ではなく「関係と文脈」なのか
暗号資産は、単なる列挙だけではリスクを評価できない点で一般のソフトウェアパッケージと異なる。 同じAESでも128ビットCBCモードと256ビットGCMモードはセキュリティ特性が大きく異なり、同じRSAでも署名用2048ビットと鍵交換用1024ビットでは量子・古典の脅威に対する露出度が全く異なる。 したがってCBOMの識別単位は「アルゴリズム名」ではなく、アルゴリズム・モード・鍵長・セキュリティ強度・用途・実装箇所を束ねた一つの暗号資産でなければならない。
さらに暗号リスクは、個々の資産ではなく資産間の依存関係において増幅される。 たとえばサーバ秘密鍵(関連暗号資材)はそれを収めたX.509証明書(certificate)に結び付き、その証明書はTLS 1.2プロトコル(protocol)で使われ、そのプロトコルはRSA鍵交換とSHA-256署名(algorithm)に依存する。 一つのノードが量子脆弱と判定されれば、それに依存する上位の資産・サービスを逆にたどって影響範囲を見積もる必要があるが、CBOMはこうした依存グラフを表現することで、「何があるか」から「何が何に依存し、どこまで影響が波及するか」へと分析範囲を拡張する。
2.2 CBOM全体構成概念図
flowchart LR
subgraph SRC["収集源"]
CODE["ソースコード(静的解析)"]
BIN["バイナリ・ライブラリ"]
CFG["設定・証明書ストア"]
NET["ネットワーク・TLSスキャン"]
end
subgraph CBOM["CBOM(CycloneDX 1.6)"]
ALG["algorithm(アルゴリズム・モード・強度)"]
CERT["certificate(X.509など)"]
PROT["protocol(TLS・SSH・IPsec)"]
MAT["related-crypto-material(鍵・トークン)"]
end
subgraph USE["活用"]
RISK["量子リスク・規制分析"]
PLAN["PQC移行の優先順位"]
PROOF["移行完了の証跡・監査"]
end
CODE --> ALG
BIN --> ALG
CFG --> CERT
CFG --> MAT
NET --> PROT
ALG --> RISK
CERT --> RISK
PROT --> RISK
MAT --> RISK
RISK --> PLAN --> PROOF
上図のとおり、CBOMは複数の収集源から暗号資産を抽出し、標準スキーマへ正規化し、それをリスク分析・移行計画・監査証跡へと流し込むパイプラインの中心に位置する。 収集源が一つではないという点が重要である。 ソースコードの静的解析だけでは運用環境で実際に交渉されるTLSスイートを知ることができず、ネットワークスキャンだけではコードに潜在する未使用の暗号経路を見つけられないため、信頼できるCBOMは複数の源をマージ・重複排除して作る。
2.3 CycloneDX 1.6とCBOMデータモデル
CBOMは独自フォーマットではなく、OWASP CycloneDX 1.6で追加された暗号資産表現機能を基盤とする。 IBM Researchが主導して設計し、2024年のCycloneDX 1.6リリースでAttestations(証跡)とともに導入され、CycloneDX仕様はECMA-424として標準化され、国際標準の地位を得た。 核心は既存のSBOMと「同じフォーマット・同じツール体系」を再利用する点であり、組織はすでに運用中のSBOM生成・検証・配布パイプラインに暗号資産を載せることができる。
CycloneDXは暗号資産をcomponentのcryptoProperties.assetTypeで分類し、代表的な型は次のとおりである。
| assetType | 意味 | 記録例 | リスク分析の着眼点 |
|---|---|---|---|
algorithm |
暗号アルゴリズム・プリミティブ | RSA-2048, AES-256-GCM, SHA-1 | 量子脆弱性、セキュリティ強度(112/128bit)、廃止対象の別 |
certificate |
公開鍵証明書 | X.509サーバ証明書 | 署名アルゴリズム、有効期間、チェーンの信頼性 |
protocol |
セキュリティプロトコル | TLS 1.2/1.3, SSH, IPsec | 脆弱バージョン・脆弱スイート交渉の可能性 |
related-crypto-material |
鍵・トークンなど付加資材 | 秘密鍵、共通鍵、トークン | 保管場所、寿命、アクセス制御 |
各資産にはアルゴリズム変種(primitive)、パラメータセット、NIST水準、認証状態、実装ライブラリとともに、「コードのどのファイル・どの行で使われるか」を指す証跡(evidence)が結び付けられる。 この証跡の連結のおかげで、CBOMは単なる宣言ではなく実際のコード・設定を根拠とする検証可能なインベントリとなり、移行作業時に修正箇所を直ちに特定できる。
3. CBOM生成・運用ライフサイクル
3.1 発見(Discovery)・正規化・マージ
CBOM生成の第一段階は、暗号使用を自動発見することである。 ソースコードの水準では静的解析器が暗号API呼び出し・アルゴリズム定数・鍵長を抽出し(IBMのSonar/CBOMkit系ツールが代表的)、バイナリの水準ではリンクされた暗号ライブラリとシンボルを識別し、運用の水準ではTLS/SSHスキャナが実際に交渉されるプロトコル・スイート・証明書を収集する。 異なる源が同じ資産を重複報告するため、アルゴリズム・パラメータ・箇所をキーに正規化・重複排除し、一つの一貫したグラフへとマージする。
ここでの実務的な難点は、「静的には見えるが実行されない経路」と「動的にのみ現れる経路」をどう扱うかである。 コードにMD5呼び出しがあってもデッドコードのことがあり、逆に外部設定でランタイムに選択されるアルゴリズムは静的解析に捕らえられない。 したがって成熟した組織は、静的結果に「使用の証拠(呼び出し頻度、トラフィックサンプル)」を結合して資産の実効性を重み付けする。
3.2 分析・優先順位・移行・証跡
収集されたCBOMはリスクルールと結合され、資産ごとのリスク度へ換算される。 代表的なルールは、(1)量子脆弱な公開鍵(RSA・ECC・DH)か、(2)古典的にも脆弱なレガシー(MD5・SHA-1・DES・RC4・TLS 1.0)か、(3)セキュリティ強度が112ビット水準で廃止日程が早いか、である。 このリスク度にデータ機微性・露出面・寿命(長期保護が必要なデータか)を掛け合わせ、移行の優先順位を算出する。 長期機密性が要求される資産ほど「Harvest Now, Decrypt Later」の脅威が大きいため、PQC移行を前倒しする。
sequenceDiagram
participant Dev as 開発・運用
participant Scan as 発見ツール
participant CB as CBOMリポジトリ
participant Risk as リスク・ポリシーエンジン
participant PM as 移行管理
Dev->>Scan: コード・バイナリ・TLSスキャン要求
Scan->>CB: 暗号資産・証跡を提出(CycloneDX)
CB->>CB: 正規化・重複排除・依存グラフ構成
CB->>Risk: 資産・依存関係を伝達
Risk->>Risk: 量子リスク・レガシー・強度を評価
Risk->>PM: 優先順位・影響範囲を算出
PM->>Dev: 移行バックログ・修正箇所を指示
Dev->>CB: 移行後に再スキャン(ML-KEM・ML-DSAを反映)
CB->>Risk: 移行完了の有無を再検証
移行が終われば、同じパイプラインで再スキャンし、量子脆弱資産が除去されPQCアルゴリズムへ置換されたことをCBOMで証明する。 CycloneDX Attestationsと結合すれば、「誰が・いつ・どの根拠で特定の統制を満たしたか」を署名された形で残せるため、規制当局・顧客に移行の進捗を機械可読形式で報告できる。
4. SBOM・QBOMとの比較、そして暗号アジリティとの関係
CBOMはSBOMの競合概念ではなく、補完・特化の関係である。 SBOMが「何で作られたか(構成要素)」を扱うのに対し、CBOMはその構成要素が「どの暗号をどう使うか(暗号の振る舞いと資産)」を扱う。 両者は同じCycloneDXフォーマットを共有するため、一つのBOM文書に共に収められる。
| 区分 | SBOM | CBOM | 備考(QBOMの観点) |
|---|---|---|---|
| 一次的関心 | パッケージ・ライブラリ・依存性 | 暗号アルゴリズム・鍵・証明書・プロトコル | QBOMは量子リスクの観点でCBOMを解釈・拡張 |
| 核心的問い | 何が入ったか | どの暗号をどこで使うか | 何が量子脆弱で、いつまでに変えるべきか |
| 主用途 | 脆弱ライブラリ・ライセンス追跡 | 暗号可視性・PQC移行・コンプライアンス | 移行日程・優先順位の策定 |
| 標準 | CycloneDX, SPDX | CycloneDX 1.6(ECMA-424) | なお収束中、用語の混用に留意 |
この比較に相違が生じる根本的な理由は、「同一性判定の基準」が異なるからである。 パッケージはバージョン・ハッシュで同一性を比較的明確に判定できるが、暗号資産は同じ名前でもモード・強度・用途・実装が異なればリスクが変わるため、CBOMはより豊富な属性と証跡を必須に要求する。 実務的にはQBOM(Quantum-safe/Cryptography BOM)という用語も使われるが、これはおおむね量子安全移行の観点からCBOMを特化して呼ぶ表現と理解すればよい(標準・用語が収束中のため断定は避ける)。
暗号アジリティとの関係も重要である。 暗号アジリティとは「特定のアルゴリズムをコードの至る所にハードコードせず、ポリシー・設定でアルゴリズムを交換できるよう設計する能力」である。 CBOMがなければどこを変えるべきか分からないためアジリティの前提が崩れ、アジリティがなければCBOMで識別した資産を実際に交換しにくい。 すなわちCBOMは「可視性」、暗号アジリティは「交換能力」であり、両者が結合するときにのみPQC移行は反復可能かつ測定可能なプロセスとなる。
5. (深化)規制・政策の動向と実務適用戦略
CBOMの台頭は技術トレンドだけでなく、政策の圧力とも噛み合っている。 米国では連邦機関・契約者に対して耐量子移行の期限(例:2030年ごろの高価値・高影響システム)を求める流れが形成されつつあり、FAR改定の議論などでサプライチェーン全般にNIST PQC遵守が拡散する見込みである(具体的な日程・適用範囲は原文での確認が必要である)。 NIST IR 8547はRSA・ECCなど量子脆弱アルゴリズムを2030年に非推奨、2035年に使用不可へ押し出す移行ロードマップを示しており、この際112ビットと128ビット強度の適用時点が異なり得るため、CBOMにセキュリティ強度を必ずタグ付けしなければならない。
実務適用の核心は段階的アプローチである。 第1段階は発見であり、全社の暗号使用をCBOMでインベントリ化し「分からない」を「分かる」へ変える。ある金融機関が数千のサービスのTLS設定をスキャンして数百件のTLS 1.0/1.1と多数のRSA-1024を発見した事例のように、発見だけでも直ちに対処可能なレガシーが露わになる。 第2段階は優先順位化であり、長期機密データ・外部露出面・規制対象システムを上位に置く。 第3段階はハイブリッド移行であり、今すぐPQC単独移行が難しい領域には従来アルゴリズムとPQCを併用するハイブリッド鍵交換を適用し、互換性と安全性を同時に確保する。 第4段階は継続検証であり、CI/CDにCBOM生成を内在化し、新しいコードが禁止アルゴリズムを持ち込めばビルドを失敗させる「ポリシーゲート」を作る。
この過程でCBOMは、開発・セキュリティ・規制・監査の各組織をつなぐ共通言語として機能する。 開発者は修正箇所を、セキュリティチームはリスク優先順位を、規制対応チームは遵守証跡を、監査チームは特定時点の暗号構成を、それぞれの観点から同じCBOMで意思疎通できる点が最大の実務的価値である。
6. 考慮事項および示唆(技術士の観点)
- 移行戦略: CBOM導入は「PQCへ全て変える」ことではなく、「まず見て、優先順位を決め、反復可能に変える」ガバナンス体系の構築として接近すべきである。発見→分析→移行→証跡のライフサイクルをCI/CDに内在化してこそ、一回限りの調査ではなく継続管理として定着する。
- トレードオフ: 静的解析は網羅的だが偽陽性(デッドコード)と動的経路の見落としがあり、ネットワークスキャンは実効的だが内部呼び出し・オフライン資産を取りこぼす。単一の源に依存せず複数の源をマージしつつ、証拠に基づいて資産の実効性を重み付けし、ノイズを減らすべきである。
- 暗号アジリティとの連携: CBOMが識別した資産を実際に交換するには、暗号を抽象化層・設定へ分離するアジリティ設計が先行・並行しなければならない。可視性(CBOM)と交換能力(agility)は分離できない一対である。
- 標準・用語の未成熟: CBOM・QBOM・cryptoPropertiesなど用語とスキーマが収束中であるため、特定ベンダのフォーマットへ固定(lock-in)されないようECMA-424(CycloneDX)のような開放標準を基準とし、SPDXなどとの相互運用性も確保すべきである。
- セキュリティ自体のリスク: CBOMは「どこにどの弱い暗号と鍵があるか」を収めた攻撃地図でもある。CBOM成果物自体にアクセス制御・署名・完全性保護を適用しなければ、攻撃者に最適の標的リストを提供することになる。
- 展望と連携技術: 今後CBOMはSBOM・AI SBOM・VEXとともに統合サプライチェーン透明性体系へ収束する可能性が高く、耐量子暗号(PQC)・暗号アジリティ・ゼロトラストの鍵/証明書管理と結合して、組織の暗号ガバナンスの中枢へと発展するであろう。
参考資料
- OWASP CycloneDX v1.6 Released (CBOM·Attestations): https://cyclonedx.org/news/cyclonedx-v1.6-released/
- CycloneDX Specification Overview: https://cyclonedx.org/specification/overview/
- Wikipedia, Cryptographic bill of materials: https://en.wikipedia.org/wiki/Cryptographic_bill_of_materials
- IBM Research, CBOMkit (Zurich): https://www.zurich.ibm.com/cbom/
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
- NIST FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
一言まとめ: CBOMはアルゴリズム・鍵・証明書・プロトコルなどの暗号資産とその依存関係をCycloneDX(ECMA-424)形式で可視化し、暗号アジリティと耐量子暗号移行を反復可能・測定可能・証明可能にする暗号ガバナンスの出発点である。