ハンマーは弱くても頭を殴ってダウンを取るのが浪漫なんだ...と言い聞かせてモンスターハンターワイルズをプレイしている @hsbt です。今回は CRA や SBOM という言葉を聞くものの、よくわかってないのでちゃんと調べて勉強したという内容の紹介です。
CRA とSBOM
CRA(Cyber Resilience Act)は欧州連合(EU)が2024年11月20日に発行した、デジタル製品のセキュリティを強化し、サイバー攻撃に対するレジリエンス(回復力)を高めることを目的とした法規制です。ソフトウェアをはじめとするデジタル製品の設計、開発、製造におけるセキュリティ要件を定め、製品のライフサイクル全体を通じてサイバーセキュリティへの脅威に対する安全性を確保することを企業や組織に求めています。
SBOM(Software Bill of Materials)は、ソフトウェアの構成要素を一覧化し機械可読可能なフォーマットとして作成した「部品表」です。SBOM によって、アプリケーションが使用しているライブラリ、依存関係、およびそれらのバージョン情報を可視化できます。
CRAとSBOMの関係
CRAでは製品に含まれるソフトウェアコンポーネントを特定や製品のリスク評価、脆弱性管理、セキュリティアップデートの提供を求めています。これらの要件を準拠するために使われるのが SBOM という位置付けになります。SBOM 以外に要件を満たすフォーマットや規格をご存知の方は教えていただけると助かります。
CRAの対象範囲
CRAはソフトウェア製品だけでなく、IoT機器、ネットワーク機器、産業用制御システム、医療機器、自動車などのデジタル要素を含む幅広い製品に適用されます。そのため、ソフトウェア開発だけでなく、製造業や重要インフラ事業者にも影響を与えると予測されています。また CRA は 2026年9月11日 より製造業者による脆弱性の報告義務がはじまるため、特に欧州でビジネスを展開する企業にとっては 2025年と2026年前期が体制の準備期間になるということのようです。
ここまで記載したことは検索したり LLM に聞けばすぐに回答される内容なので、この辺にとどめて、実際に現場で SBOM を扱う話の紹介に進みます。
GemfileとSBOMの違い
Rubyでソフトウェアを作る際には RubyGems と Bundler を用いつつ、GemfileとGemfile.lockによってライブラリの依存関係を処理します。私も最初に SBOM の概要を見たときは、「lockfile と何が違うのだ?」となりましたが、明確な違いをいくつか紹介します。
対象範囲の違い
Gemfile は Rubyプロジェクト特有のランタイムバージョンやライブラリの依存関係のみを管理しますが、SBOMは言語やプラットフォームを問わず、OS、システムライブラリ、外部サービスなどすべての依存関係を含むという違いがあります。後述する生成ツールを標準的な現代の Rails のプロジェクトに対して実行した場合、RubyGems に加えて npm の情報も含めた SBOM を作成することができます。
フォーマットとメタデータの違い
Gemfile は Rubyの構文で書かれたBundler特有のフォーマットですが、SBOM は SPDX、CycloneDXなどの標準化された業界共通フォーマットです。主に json か xml で作成されることが多いようです。
❯ cat Gemfile.lock
GEM
remote: https://rubygems.org/
specs:
actioncable (7.2.2.1)
actionpack (= 7.2.2.1)
activesupport (= 7.2.2.1)
❯ cat bom.json
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": ".",
"documentNamespace": "http://trivy.dev/filesystem/.-700b7d28-00e7-49a1-aff9-a37369cf4721",
"creationInfo": {
"creators": [
"Organization: aquasecurity",
"Tool: trivy-dev"
],
"created": "2025-03-06T06:59:27Z"
},
"packages": [
{
"name": "Gemfile.lock",
"SPDXID": "SPDXRef-Application-d19828012f8d6ece",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"primaryPackagePurpose": "APPLICATION",
"annotations": [
{
"annotator": "Tool: trivy-dev",
"annotationDate": "2025-03-06T06:59:27Z",
"annotationType": "OTHER",
"comment": "Class: lang-pkgs"
},
{
"annotator": "Tool: trivy-dev",
"annotationDate": "2025-03-06T06:59:27Z",
"annotationType": "OTHER",
"comment": "Type: bundler"
}
]
},
{
"name": "actioncable",
"SPDXID": "SPDXRef-Package-6143d411f50a5b2c",
"versionInfo": "7.2.2.1",
"supplier": "NOASSERTION",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"sourceInfo": "package found in: Gemfile.lock",
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:gem/actioncable@7.2.2.1"
}
],
"primaryPackagePurpose": "LIBRARY",
"annotations": [
{
"annotator": "Tool: trivy-dev",
"annotationDate": "2025-03-06T06:59:27Z",
"annotationType": "OTHER",
"comment": "PkgID: actioncable@7.2.2.1"
},
{
"annotator": "Tool: trivy-dev",
"annotationDate": "2025-03-06T06:59:27Z",
"annotationType": "OTHER",
"comment": "PkgType: bundler"
}
]
},
(snip)
上記に例示したように含まれるメタデータも Gemfile は主にライブラリの名前とバージョンの制約を記述しますが、SBOMはライセンス情報、脆弱性データ、作者情報、ハッシュ値など詳細なメタデータを含みます。これらのデータを利用することで、脆弱性が修正されていないライブラリやプロジェクトで許容していないライセンスの抽出など、幅広い用途に用いることが可能です。
GitHub以外の環境におけるSBOMの必要性
ここまで学んで、自分でも GitHub の dependabot alert や update を使って脆弱性管理をするのと何が違うのか?と思いましたが、その目的に閉じた場合は特に違わないようです。
世の中にはさまざまな種類の会社や組織があり、CRA の対象となる全ての会社が GitHub を使えるわけではありませんし、ソフトウェアの特性上パブリッククラウド上に保存することができないソフトウェアもたくさんあります。そのような場合に SBOM を作成して、内製ツールやアプライアンス製品によって脆弱性管理を行う、ということもあるうるでしょう。
また、医療機器などの安全性が重視される分野では、厳格な認証プロセスがありSBOMを作成し、ライセンス管理など目的に応じて記録していくことには有用な面もあると感じました。
Ruby 開発者が SBOM を触る時のツール群
さてSBOMが何者なのか、を理解したところで実際に SBOM を作成したり中身を見ていこうと思います。SBOM は統一的な規格があるわけではなく、要件を満たすようなフォーマットをいくつかの団体が作っているというのが現状です。
- SPDX - Linux Foundationが推進するフォーマット、従来はライセンスの識別子を定義していたが、現在は規格の範囲が広がり SBOM として使用できる。
- CycloneDX - OWASPが推進するフォーマット
- Syft - Anchore社が開発したフォーマット
現在、SBOM について開発を行う際には SPDXとCycloneDXのいずれか、または両方に対応するということが多いようで実質的な標準はこの2つと考えても良いと思います。今回は SPDX フォーマットを用いる前提で各種ツールを紹介します。
生成ツール
SBOM を生成するツールの多くはすでに Gemfile と その lockfile に対応しています。syft や trivy を用いた例は以下のとおりです。
$ syft file:./Gemfile.lock -o spdx-json=bom.json $ trivy fs Gemfile.lock --format spdx-json --output bom.json
他にも Microsoft が作る sbom-tool や GitHub の cli である gh なども SBOM の生成に対応しています。また GitHub の Web UI からも SBOM をダウンロードすることができます。
上記のうち引数としてカレントディレクトリ(.)を与えた場合は Gemfile だけではなく package.json なども読み取り SBOM の対象となる全てのソフトウェア情報を含めた json を生成します。
分析ツール
SBOM を作成して満足するだけでは物足りないので、せっかくなので脆弱性スキャンを行いたいと思います。SBOMファイルに含まれるソフトウェアコンポーネントの脆弱性を検出する bomber というツールを Ruby のバグトラッカーである https://github.com/ruby/b.r-l.o/ の SBOM に使おうと思います。bomber 自体のインストール方法は README.md を参照してください。
$ trivy fs . --format spdx-json --output bom.json
$ bomber scan bom.json
__ __
/ / ___ __ _ / / ___ ____
/ _ \/ _ \/ ' \/ _ \/ -_) __/
/_.__/\___/_/_/_/_.__/\__/_/
DKFM - DevOps Kung Fu Mafia
https://github.com/devops-kung-fu/bomber
Version: 0.5.1
■ Scanning Files:
bom.json
■ Ecosystems detected: gem
■ Provider supported ecosystems: almalinux,alpine,android,bitnami,cargo,curl,debian,git,github-actions,go,haskell,hex,linux,maven,npm,nuget,oss-fuzz,packagist,pub,pypi,python,cran,rocky,rubygems,swift,ubuntu
■ Provider does not support detected ecosystem: gem
■ Scanning 153 packages for vulnerabilities...
■ Vulnerability Provider: OSV Vulnerability Database (https://osv.dev)
■ Files Scanned
bom.json (sha256:3fdd92b3677f4adc5e8a2dad9d06a0ba58b89c4d62c9fc3ed4679217d4689b2f)
╭──────┬──────────┬─────────┬──────────┬─────────────────────┬────────╮
│ TYPE │ NAME │ VERSION │ SEVERITY │ VULNERABILITY │ EPSS % │
├──────┼──────────┼─────────┼──────────┼─────────────────────┼────────┤
│ gem │ rack │ 3.1.10 │ MODERATE │ CVE-2025-27111 │ N/A │
│ ├──────────┼─────────┼──────────┼─────────────────────┼────────┤
│ │ nokogiri │ 1.16.8 │ LOW │ GHSA-5mwf-688x-mr7x │ N/A │
│ │ ├─────────┼──────────┼─────────────────────┼────────┤
│ │ │ 1.16.8 │ LOW │ GHSA-vvfq-8hwr-qm4m │ N/A │
╰──────┴──────────┴─────────┴──────────┴─────────────────────┴────────╯
Total vulnerabilities found: 3
╭──────────┬───────╮
│ RATING │ COUNT │
├──────────┼───────┤
│ MODERATE │ 1 │
├──────────┼───────┤
│ LOW │ 2 │
╰──────────┴───────╯
NOTES:
1. The list of vulnerabilities displayed may differ from provider to provider. This list
may not contain all possible vulnerabilities. Please try the other providers that bomber
supports (osv, ossindex, snyk)
2. EPSS Percentage indicates the % chance that the vulnerability will be exploited. This
value will assist in prioritizing remediation. For more information on EPSS, refer to
https://www.first.org/epss/
3. An EPSS Percentage showing as N/A means that no EPSS data was available for the vulnerability
or the --enrich=epss flag was not set when running bomber
実はこの bugs.ruby-lang.org のリポジトリは私が毎日手入れをしていて、脆弱性を有するライブラリは使わないようにしているので結果は何も出てこなかったので、わざと少し巻き戻したコミットを使っています。上記の例だと使用している rack と nokogiri に公開済みの脆弱性が存在することがわかります。
実践的なワークフロー
GitHub の dependabot alert は GitHub のリポジトリに push した後にわかるものです。よりプロアクティブな使い方として依存ライブラリを手でアップデートした時に Gemfile.lock の更新をトリガーとして以下のような GitHub Actions を作成すると最新バージョンまで上げる途中のプロジェクトで思わず脆弱性が残っているバージョンを使う、ということは防げそうな気がしました。
trivy fs . --format spdx-json --output bom.jsonで SBOM ファイルを作成bomber scan --eixtcode bom.jsonで脆弱性スキャンを実行、Severity が高いものが検出された場合はexit 0以外となる- 上記で見つかった場合には Actions が落ちるので脆弱性が残っている、ということがわかるので解決しているバージョンまでアップグレードを頑張る
とはいえ、最新バージョンでしか脆弱性が解決されておらず、そこに辿り着くまで上記のチェックが落ち続ける、というようなことはアップグレード作業をした方なら容易に想像はつくと思うので、一旦上げ切ってからという前提があるかもしれません。
まとめ
私が SBOM についての動きを知ったのは OpenSSF 2024 アニュアル レポート - The Linux Foundation などからですが OpenSSF ではGitHub が SBOM の export で使っている protobom の開発など、SBOM の導入と利用に向けた様々なプロジェクトが動いているようです。
ただし、日本でソフトウェアを開発して日本むけに提供をしている、という領域だと GitHub があれば十分かな...というのが現状というのが今回調べての所感でした。ただし、状況によっては多くの企業で CRA や SBOM の対応が求められることになるかもしれません。この記事が Ruby でソフトウェア開発をしているみなさんの一助となれば幸いです。
