SBOMを活⽤した脆弱性管理の取り組み

2023年3⽉3⽇

NTTコミュニケーションズ株式会社
イノベーションセンター テクノロジー部⾨⻄野 卓也© NTT Communications Corporation All Rights Reserved.

SBOM（Software Bill of Materials）の利⽤⽬的

サプライチェーン
セキュリティ
• サプライチェーンセキュリティの透明性※1を確保する技術
Supply Chain Security Transparency（国内では Security Transparency と呼ぶ⼈も）• ソフトウェアコンポーネントの透明性※1を確保する技術
Software Component Transparency※1 NTIA （⽶国商務省電気通信情報局）は、SBOMの発⾏による透明性向上でサプライチェーンにおけるサイバーセキュリティリスクと総コストを下げられると主張している。また、NTIAはSBOMの最⼩要素に関するレポートも公開している。

© NTT Communications Corporation All Rights Reserved.

ライセンス管理• SBOMの最初の利⽤⽬的• SPDXフォーマットが開発された元々の理由

脆弱性管理• SBOMの応⽤的な利⽤• セキュリティ⽤途のCycloneDXフォーマット

ポリシー&コンプライアンス管理• 調達に関する制限のチェックなど• SBOMの新しい注⽬領域

3

今回のテーマ

サプライチェーンセキュリティ• サプライチェーンセキュリティの透明性※1を確保する技術
Supply Chain Security Transparency（国内では Security Transparency と呼ぶ⼈も）• ソフトウェアコンポーネントの透明性※1を確保する技術
Software Component Transparency※1 NTIA （⽶国商務省電気通信情報局）は、SBOMの発⾏による透明性向上でサプライチェーンにおけるサイバーセキュリティリスクと総コストを下げられると主張している。また、NTIAはSBOMの最⼩要素に関するレポートも公開している。

© NTT Communications Corporation All Rights Reserved.

ライセンス管理• SBOMの最初の利⽤⽬的• SPDXフォーマットが開発された元々の理由

脆弱性管理• SBOMの応⽤的な利⽤• セキュリティ⽤途のCycloneDXフォーマット

ポリシー&コンプライアンス管理• 調達に関する制限のチェックなど• SBOMの新しい注⽬領域

4

ソフトウェアの脆弱性管理について
脆弱性スキャナの結果をDBに格納して管理する仕組みが重要
脆弱性スキャナ
ソフトウェア構成分析

脆弱性DBの検索結果を統合して出⼒出⼒をDBに格納して管理© NTT Communications Corporation All Rights Reserved.

5

脆弱性スキャナとSBOMの関係
ソフトウェア構成分析(SCA)の結果をSBOMとしても収集可能
脆弱性スキャナ
ソフトウェア構成分析

脆弱性DBの検索結果を統合して出⼒

SBOM

SBOMの収集＝脆弱性スキャナの中間⽣成物を保存しているだけ© NTT Communications Corporation All Rights Reserved.

6

中間⽣成物を集めることに意味はある︖

基本的にない⼀般的なユーザーや開発者は脆弱性の有無にしか興味がない© NTT Communications Corporation All Rights Reserved.

7

脆弱性スキャナとSBOM検討資料の不思議な関係
脆弱性スキャナを分割して再結合すると、脆弱性スキャナの単純利⽤より嬉しい状態に︖︖︖
機能を分離

ソフトウェア構成分析

脆弱性スキャナ

機能を分離

脆弱性DBの検索結果を統合して出⼒SBOM

SCAツール + 脆弱性DB < SBOM + 脆弱性DB ︖© NTT Communications Corporation All Rights Reserved.

8

脆弱性スキャナを分割したら性能が変わるのか︖

変わらない
SBOMの中⾝はSCAツールの能⼒に強く依存•
ライセンス管理•
脆弱性管理•
ポリシー&コンプライアンス管理
使う⽬的に合わせてSCAツールも最適化されているはず© NTT Communications Corporation All Rights Reserved.

9

NTIAの活動と開発現場の温度差
NTIAが考えるスマートなSBOM

開発現場でのSBOM検証

SBOMとは、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた、機械処理可能なインベントリーです。

「このツールの出⼒ファイルだと失敗しますが、他のヤツで試したらいけました︕︕というか、SBOM使う意味って︖」- NTIA著「SBOM at a Glance」の⼀般社団法⼈JPCERTコーディネーションセンターによる翻訳から抜粋 -SyftでコンテナのSBOMデータをSPDX形式とCycloneDX形式で出⼒⽚⽅は何故か他のツールで読み込めないが⽚⽅は何故か他のツールで読み込めるJPCERTで何故か⽇本語訳を配布してくれてるので読もう

https://ntia.gov/page/software-bill-materials© NTT Communications Corporation All Rights Reserved.

2023年2⽉21⽇当時の最新環境
10社内のSBOM施策検討で実際に聞いた⾔葉

そもそもの話、現場だけだと構成管理のモチベーションはない© NTT Communications Corporation All Rights Reserved.

11

開発現場のモチベーション
現場のモチベーションは、脆弱性スキャナによるSDLC の改善でSBOMの出⼒ではない※1

SBOMが性能を改善︖
ソフトウェア構成分析

脆弱性DBの検索※1 ソフトウェア開発ライフサイクル

結果を統合して出⼒

SBOMSBOMデータの有無と脆弱性スキャナの性能は無関係© NTT Communications Corporation All Rights Reserved.

12性能とは無関係でも、検証性とは関係あり
脆弱性スキャナ
ソフトウェア構成分析

脆弱性DBの検索結果を統合して出⼒SDLCの成果物をスキャン（コード、コンテナイメージ、バイナリ等）

脆弱性スキャナの妥当性
c
判断にSBOMが欲しい︕© NTT Communications Corporation All Rights Reserved.

SBOM

SBOMにないコンポーネントは検査できていない可能性が⾼い

Vulns

13

脆弱性検査の取り組みを評価したいのか︖
SDLCを評価する必要が社内や社外にある
NO

SBOMは不要︖

YES

SBOMは必要

SDLCのセキュリティ的な観点を客観的に検証するためにSBOMは必要容易にできる︖© NTT Communications Corporation All Rights Reserved.

14

SBOMがあれば容易に検証できるわけではない
2つのSBOMフォーマットと、３つのOSS脆弱性スキャナの観点から説明

SPDXTrivy※1

CycloneDX
Grype (Syft )※1

OSV-Scanner

SyftはGrype内部で使われているはSBOM⽤ライブラリ（単体でCLIツールとしても動作可）© NTT Communications Corporation All Rights Reserved.

15

脆弱性管理の観点でみたSBOMの主要フォーマット
SPDX
最も⼈気があるSBOMフォーマット
ISO/IEC 5962:2021
コンプライアンスに関する情報管理に強い
詳細な分析情報を提供できる
SBOM領域の全てをカバーする⾼い理想を持つ規格設計
少なくとも脆弱性検知の観点ではオーバースペック

CycloneDX

特徴

最新バージョン
(2023/2⽉現在)

2.3

1.4

Linux Foundation

OWASP Foundation

Trivy v0.37.3のスキャン

Trivy v0.37.3のスキャン

Syft v0.60.1のスキャン

Syft v0.60.1のスキャン

検出差分パッケージ(purlで記述)• "pkg:generic/python@3.4.5"• "pkg:maven/gettext/gettext"• "pkg:maven/libintl/libintl"

検出差分パッケージ(purlで記述)• "pkg:generic/python@3.4.5"• "pkg:maven/gettext/gettext"• "pkg:maven/libintl/libintl"

国際オープンな標準(ISO)とは思えないほど⾃由度が⾼いフォーマット、SCAツールの性能に内容が⼤きく左右される。とにかく多くの情報を出⼒きでるた
め、パース機能に不具合があると取り回しが難しい。今後に期待。

脆弱性管理に必要な情報の記載が、SCAツールによって⼤きくブレないところが個⼈的に良い。機械だけでなく、頑張れば⼈間もギリギリ読めるレベルの情報量であるため、不具合が起こった場合にバグ特定が⽐較的容易。

主な開発⽀援団体

Linux Foundationプロジェクトの1つであるSPDX Working Groupが開発••••

SBOMデータの出⼒例(djangoコンテナを対象にM2 MBAで実⾏)

個⼈的な所感••••ファイル形式︓SPDX 2.2
処理時間︓4.892秒
⾏数︓4,724⾏検出されたアーティファクト:185
ファイル形式︓SPDX 2.2
処理時間︓60.61秒
⾏数︓121,218⾏検出されたアーティファクト:188© NTT Communications Corporation All Rights Reserved.

•••••

セキュリティ向けのSBOMフォーマット
サイバーリスク管理に⼗分な情報の管理
SPDXに⽐べてシンプルな構造
実⽤性を重視した実装ありきの規格設計
脆弱性検知の観点では扱いやすい

•••
•
•
•

OWASP Foundationの⽀援を受けてCycloneDX Core Working Groupが開発

••
•
•

•
•
•
•

ファイル形式︓CycloneDX 1.4
処理時間︓3.006秒
⾏数︓7,219⾏検出されたアーティファクト:185
ファイル形式︓CycloneDX 1.4
処理時間︓56.49秒
⾏数︓16,568⾏検出されたアーティファクト:188

16

SBOM対応のOSS脆弱性スキャナ
Trivy

特徴

••
•
•
•
•

最新バージョン
(2023/2⽉現在)

マルチOSで動作(Mac, Linux)
スキャンが⾼速開発⽤パッケージの検知除去が可能
ローカルの脆弱性DBがBoltと呼ばれる
Key-Valueストア
SPDXとCycloneDXのスキャンに対応(SPDXとCycloneDXの出⼒に対応※1)

Grype (Syft)
••
•
•
•

マルチOSで動作(Win, Mac, Linux)
GrypeのSBOM処理はSyftで実装されている• SyftはSBOM出⼒ツールとして⾮常に有名• SyftもGrypeも開発は同じ会社
ローカルの脆弱性DBがSQLite
独⾃形式（Syft）、SPDX、CycloneDXのスキャンに対応
CycloneDXの出⼒に対応※2

OSV-Scanner••••••

マルチOSで動作(Win, Mac, Linux)
スキャンが⾼速
Googleが開発した脆弱性スキャナ
オンラインの脆弱性DBに問い合わせ
SPDXとCycloneDXのスキャンに対応Open Source Vulnerability format(OSV format)でレポートを出⼒※3

0.37.30.57.1 (Grype)
0.73.0 (Syft)

1.2.0

AquaSecurity

AnchoreGoogle

2.2

2.3

2.3

CycloneDX対応
状況

1.4

1.4

1.4

JSONとして⼊⼒できるSBOM形式

SPDX(2.2), CycloneDX(1.0-1.4)

独⾃形式(Syft), SPDX(2.3), CycloneDX(1.0-1.4)
ドキュメント上はまだ2.2のままかもSPDX(2.3), CycloneDX(1.0-1.4)

JSONとして出⼒できる形式

独⾃形式, SPDX(2.2), CycloneDX(1.4)

独⾃形式, CycloneDX(1.4)

独⾃形式(OSV format)※1 これらのSBOM形式を出⼒する場合は、※2 Syftは、SPDX(2.3)とCycloneDX(1.4)のどちらも出⼒可能※3 すべての依存関係をオフラインで取得するPR

主な開発元
SPDX対応状況(2023/2⽉現在)

備考

クラウド系のセキュリティ企業

SPDX公式が配布しているライブラリ(spdx/tools-golang)を利⽤

CycloneDX公式が配布しているライブラリ(CycloneDX/cyclonedx-go)を利⽤

脆弱性スキャンを同時に実⾏できない© NTT Communications Corporation All Rights Reserved.

サプライチェーンセキュリティ系のセキュリティ企業

SPDX公式が配布しているライブラリ(spdx/tools-golang)を利⽤。
Syftの古いバージョン(0.60.1以下)を使えば2.2を利⽤可

CycloneDX公式が配布しているライブラリ(CycloneDX/cyclonedx-go)
を利⽤

検索エンジンで有名なあの会社

SPDX公式が配布しているライブラリ(spdx/toolsgolang)を利⽤

CycloneDX公式が配布しているライブラリ(CycloneDX/cyclonedx-go)を利⽤があり、近⽇中にSBOM的な使い⽅が可能に︖

17

脆弱性管理に向けたSBOM戦略
検証性や動作速度の観点からCycloneDX+Trivyの組み合わせがオススメ(2023年2⽉時点)
SBOM標準を意識するならSPDX+Grype(Syft)だが、検証の複雑さや速度の点で脆弱性管理の検証に向かない

SPDX
Trivy

© NTT Communications Corporation All Rights Reserved.

CycloneDX
Grype (Syft)

OSV-Scanner18ゴールはSDLCの改善と評価
客観的に評価可能なセキュリティ運⽤
1. 脆弱性検査のレポート報告• 脆弱性スキャンの実施
2. SCAコンポーネントの動作保証• SBOMデータの保存と分析
3. 検出された脅威の調査や対応• パッチ管理など
4. 脅威の無⼒化に関する報告• 対処レポートとSBOMデータの提出

脆弱性検査とSBOM出⼒
例︓Trivyスキャン＆CycloneDX出⼒

脆弱性管理
SBOMデータを利⽤した
脅威の発⾒とSDLC評価

脆弱性検査の実施とSBOM利⽤のどちらを優先すべき︖

Vulns

脆弱性検査の妥当性を評価するためのSBOMデータ© NTT Communications Corporation All Rights Reserved.

SBOMc
少なくとも脆弱性管理の観点では、脆弱性スキャナのCI/CD導⼊が先

19

GitHub上でのSDLCと脆弱性スキャナ
新機能のPR

PRを修正

脆弱性通知

脆弱性修正PR

脆弱性スキャンのワークフローを実⾏

脆弱性スキャンのワークフローを実⾏

脆弱性スキャンのワークフローを実⾏

NG

OKOK

Vulns

LGTM

mainへmerge

LGTM

mainへmerge

main ブランチ
SBOMを利⽤する存在がSDLCの中に存在する

SBOM⽣成のワークフローを実⾏SBOM
社内外のセキュリティ
アナリスト© NTT Communications Corporation All Rights Reserved.

SBOM⽣成のワークフローを実⾏

定期的な脆弱性スキャン

Vulns

SBOM

20

GitHub上でのSDLCと脆弱性スキャナ（Trivyを例に）新機能のPR

PRを修正

脆弱性通知

脆弱性修正PR

Trivyで脆弱性スキャン

Trivyで脆弱性スキャン

Trivyで脆弱性スキャン

NG

OK

OK

Vulns

LGTM

mainへmerge

LGTM

mainへmerge

main ブランチ
TrivyでCycloneDX
ファイルを出⼒

SBOM
社内外のセキュリティ
アナリスト© NTT Communications Corporation All Rights Reserved.

SPDXとCycloneDXの両⽅を⽣成して配布する場合が多いかも︖

定期的な脆弱性スキャン

TrivyでCycloneDX
ファイルを出⼒

Vulns

SDLCの評価は︖
21

脅威の発⾒とSDLC評価
脆弱性検査をしてSBOMデータを出⼒するだけでは、SBOMの活⽤とはいえない
1. 脆弱性検査のレポート報告• 脆弱性スキャンの実施
2. SCAコンポーネントの動作保証• SBOMデータの保存と分析
3. 検出された脅威の調査や対応• パッチ管理など
4. 脅威の無⼒化に関する報告• 対処レポートとSBOMデータの提出

脆弱性検査とSBOM出⼒
例︓Trivyスキャン＆CycloneDX出⼒

脆弱性管理
SBOMデータを利⽤した
脅威の発⾒とSDLC評価

コンテナ環境（K8s/Docker）であれば、OSSのKubeClarityが⽐較的試しやすい
https://github.com/openclarity/kubeclarity• プロダクトチームは複数のSBOMデータを提出することがある
SBOM

コンテナA

SBOM

コンテナB

SBOM

コンテナC

プロダクトチーム© NTT Communications Corporation All Rights Reserved.

• プロダクトチームでパッチアップデートが容易とは限らない• アップデートの容易さは業種や契約、提供サービスに依存• アナリストは複数のプロダクトチームを対象に脆弱性管理を⾏う
22脅威の発⾒と対処に特化したツールの内製確認できる範囲のリポジトリを統計調査して、既存のツールで対応が可能かどうかを判断する

特殊なアプライアンスを扱う業種や、パッチアップデートが困難なサービスでは内製開発がほぼ必須︖
今⽇紹介した全てのOSS脆弱性スキャナ(Trivy, Grype/Syft, OSV-Scanner)に対応済み

Threatconnectome
脅威分析からサービス影響を把握し、その優先度に応じた予防措置を管理する

SBOMを利⽤した攻撃領域管理
で通知の無駄や確認作業を削減
脅威制御アクションを利⽤した
明快な脅威影響のコントロール
対処ログからチームのSDLCとセキュリティスキルを評価
2023年7⽉〜9⽉にOSS公開予定© NTT Communications Corporation All Rights Reserved.

23

SBOMを実運⽤するための課題は⼭積み新機能のPR
アーティファクトの分析
能⼒はSCA機能に依存

PRを修正

脆弱性通知

内製開発ライブラリが多い場合はSCA機能に最適化した
OmniBOR(GitBOM)を⽤いたアーパッケージ管理⼿法の導⼊ティファクト解析＆追跡補助も検討

アップデート対処できない場合はどうするのか︖

OKNG

脆弱性修正PROK
purlで問題を通知して作業者は対処可能︖

Vulns

LGTM

mainへmerge

LGTM

mainへmerge

main ブランチ
そもそも現在の成果物がSBOM管理できる対象なのSBOMとして出⼒したい
か、SBOM対応のためにデータと利⽤⽬的の⼀致
コードを完全に書き直す必要はあるのか︖

⼈員をどうやって確保して評価体制をつくるのか︖

社内外のセキュリティ
アナリスト

内製開発ライブラリが多い場合や、マイナーなOSSライブラリを利⽤している場
合は、外部の脆弱性DBの利⽤では不⼗分な場合も︖© NTT Communications Corporation All Rights Reserved.

SBOM

脆弱性情報の管理はpurlベースで⼗分か︖

継続的にSBOMデータを活⽤できる状態なのか︖

purl(package URL)のURL
エンコードやsubpathの扱い（有無だけでなくdistro 本当に必要なものはStatic SBOMとVulns のように出⼒内容⾃体が違Runtime SBOMのう場合あり）を完全に理解どちらか︖
して処理しているか︖
24

まとめ• SBOMの利⽤に関してはNTIAの動向を把握すると良い•

今後もサプライチェーンセキュリティに関しては、NTIAのドキュメントが標準になる可能性⼤• NTIAの「理想的なSBOM運⽤」に現実はまだ追い付いていない• 脆弱性管理はSBOMの理解しやすいユースケースだが、曖昧な知識でやると現場が混乱する••

前提︓「脆弱性検査の取り組みを評価」するためにSBOMデータの提出が必要•

脆弱性管理の点において、評価が必要でなければSBOMデータの提出は不要•

開発者⾃⾝がセキュリティ対応をする場合は、セキュリティの取り組みが開発者の⾃⼰満⾜で良い場合も実際は多い

開発の現場においては、「SBOMの導⼊」ではなくSDLCの評価や改善を⽬的にすること•

脆弱性スキャナ導⼊が先、SBOM利⽤は後• 脆弱性スキャナやSBOM出⼒⽤のSCAツール対応には開発チームの協⼒が必須•

プロダクトのコード管理やCI/CDのレベルでSBOM対応が必要になる場合がほとんど••

例︓npmのようなパッケージ管理システムの導⼊、Github ActionのTrivy導⼊など

どんなものでもSBOMデータを正確に出してくれる魔法のようなツールは現状ない• 提出されたSBOMデータを使って脆弱性管理の負担軽減や脅威分析の改善が可能•

SBOMのエコシステム⾃体が⼤きく変化している状態で、企業を超えた共有にはまだまだ課題感あり。攻撃者側にとって有益な情報も多く、業種によってはTLP※1のような仕組みがSBOM共有で必要とされる可能性も※1

Traffic Light Protocol

NTTコミュニケーションズでは業務の特殊性から内製開発に取り組んでいたが、 KubeClarityなどのOSSツールで⼗分な場合も© NTT Communications Corporation All Rights Reserved.

25