GitLabで作るSBOMとは?特徴と実践方法を徹底解説

- 執筆者
-
aslead編集部こんにちは。aslead編集部です。
最新ソフトウェア開発のトレンドから、AI・DXツールの効果的な活用法、企業のITガバナンスの強化、業務効率化やDX化を成功に導くソリューションまで、幅広い記事を提供しています。
企業が直面する課題の解決策として効率的なツールの活用方法を探求し、生産性の向上に繋がる実践的な情報をお届けすることを目指します。
背景
近年、ソフトウェア開発におけるセキュリティ対策はますます重要性を増しており、特にサプライチェーン全体のリスク管理が注目されています。
こうした背景には、欧州サイバーレジリエンス法(CRA)の施行などにより、組織がサイバー攻撃に対して対応できる強靭な体制を求められていることがあります。
サプライチェーン全体のリスク管理を適切に行うためには、ソフトウェアの構成情報を正確に把握し、依存関係や脆弱性を明確にすることが不可欠です。その手段として、SBOM(Software Bill of Materials:ソフトウェア部品表)の整備・活用が重要視されています。
こうしたニーズに応えるため、GitLabは開発からセキュリティ、運用までを一元管理できるDevSecOpsプラットフォームを提供しています。
GitLabのSBOM生成機能は、開発プロセスにおける透明性を高め、セキュリティリスクの早期発見・対処を支援する重要な役割を担っています。
本記事では、実際にGitLab上でSBOM生成を試しながら、GitLabが提供するSBOM生成機能の特徴とその活用メリットについて詳しく解説します。
SBOMとは
SBOMとは、ソフトウェア製品の構成要素や依存関係をリスト化した情報のことを指します。
具体的には、ソフトウェアに含まれるオープンソースライブラリやサードパーティ製コンポーネント、各コンポーネントのバージョン情報などが詳細に記載されます。
これにより、ソフトウェアの内部構造を透明化し、どのような部品で構成されているかを一目で把握できるようになります。
SBOMの導入により、以下のようなメリットが得られます。
セキュリティリスクの早期発見
脆弱性のあるコンポーネントを早期に検出・対処しやすくなり、ソフトウェアサプライチェーンの安全性を高めます。
コンプライアンスの確保
使用しているライブラリのライセンス情報を明確に管理できるため、法的リスクの軽減や適切なライセンス遵守が実現します。
保守、運用の効率化
ソフトウェアの更新やトラブルシューティング時に構成要素を素早く把握でき、保守作業の効率向上に貢献します。
これらのメリットから、SBOMは安全かつ信頼性の高いソフトウェア開発に重要な情報基盤となっています。
GitLabでのSBOM生成について
GitLabでは、依存関係スキャン(Dependency Scanning)機能を活用することで、自動的にソフトウェアの依存コンポーネントを検出し、その情報をもとにSBOMを生成することが可能です。
この機能は、CI/CDパイプライン上でパッケージのバージョンを指定しているファイルを解析し、使用されているライブラリの種類やバージョン、依存関係の構造を把握します。
この解析結果をもとに、ソフトウェアの構成情報を詳細に把握するためのSBOMが自動で作成されます。
導入にあたってはGitLab社からCI/CDのテンプレートも用意されているため、追加のツール導入や複雑な設定を行わずに、SBOMを生成できる点が特徴です。
加えて、依存関係スキャンは検出したコンポーネントの情報をもとに既知の脆弱性をチェックし、脆弱性のあるコンポーネントの特定も行います。
これにより、セキュリティリスクの早期発見や対応が可能となります。
なお、この依存関係スキャン機能は、GitLab Ultimateプランのユーザーが利用可能です。
GitLab.com(SaaS版)だけでなく、GitLab Self-Managed(オンプレミス版)の両方で対応しているため、オンプレミス環境やクラウド環境を問わず幅広く活用できます。
SBOM生成の実践例
今回はGitLab.com(18.8.0)の環境で、OWASP Juice Shopのソースコードを使用して実際にSBOMを生成してみます。
OWASP Juice ShopはOWASPがセキュリティ学習のために提供している脆弱性を意図的に含んだウェブアプリケーションです。
①リポジトリをGitLabにインポート
GitLab UI上で「プロジェクトを作成」→「プロジェクトのインポート」→「URLによるリポジトリのインポート」操作を行い、「GitリポジトリのURL」にOWASP Juice ShopのクローンURLを入力します。
https://github.com/juice-shop/juice-shop.git
任意のプロジェクト名・グループ名を入力しプロジェクトを作成します。

②.gitlab-ci.ymlを編集
依存関係スキャン(Dependency Scanning)を行うために、.gitlab-ci.ymlにスキャン用のジョブを設定します。
※依存関係スキャンではリポジトリ内にlockファイルが必要ですが、OWASP Juice Shopのリポジトリにはlockファイルが含まれていません。
そのため、今回は事前に`npm install`コマンドを実行してpackage-lock.jsonファイルを作成し、リポジトリへのコミットを行っております。
| .gitlab-ci.yml |
include: - template: Jobs/Dependency-Scanning.v2.gitlab-ci.ymlstages: - test
|
上記の変更をコミット後、しばらくするとパイプラインの実行が完了します。

③依存関係リスト(SBOM)の確認
サイドバーの「セキュリティ」>「依存関係リスト」より、ソフトウェアに含まれるコンポーネント一覧を確認することができます。
依存関係リストでは、「何を使っているか」「どこから検出されたか」「脆弱性があるか」を最小限の項目で一覧できます。

依存関係リストに表示される各項目の詳細は下記の通りです。
| 表示項目 | 詳細 |
|---|---|
| コンポーネント | 使用されているOSS名とバージョン |
| パッケージャー | 依存関係のエコシステム |
| ライセンス | OSSライセンス種別 |
| ロケーション | 検出元ファイル |
| 脆弱性 | 脆弱性の件数 |
また、下記3つの形式でSBOMのエクスポートが可能です。
- JSON
- CSV
- CycloneDX(JSON)

エクスポートを実行すると、GitLabアカウントのメールアドレス宛にダウンロードリンクがメールで送付されます。
下記はCycloneDX形式でエクスポートしたものの一部抜粋になります。
CycloneDX形式のSBOMは、コンポーネントの識別子、バージョン、依存関係、ライセンスなどを機械可読なJSON形式で詳細に記述した部品表です。
画像の「components」以下では、ソフトウェアに含まれるコンポーネントの詳細の記載が続きます。

CycloneDXとGitLab依存関係リストの位置づけ
CycloneDX形式のSBOMは業界で広く標準として採用されているため、他ツールとの連携や監査対応といった用途に適しています。
一方で、この形式では情報量が多すぎるため、人が直接確認するには不向きです。
GitLabでは、このCycloneDX形式のSBOMをもとに、依存関係リストとして情報を整理・可視化しています。
これにより、機械可読な標準フォーマットと、人が確認しやすいUIの両方を提供している点が特徴です。
依存関係スキャンによる脆弱性の検出
依存関係スキャンではコンポーネントに含まれる脆弱性の検知が可能です。
脆弱性の検出結果は左メニューの「セキュリティ」の項目から各種確認することが可能です。
セキュリティダッシュボード

セキュリティダッシュボードでは、検出された脆弱性の推移が表示されます。
脆弱性の重大度を確認できるため、対応優先度の判断や全体の脆弱性の把握が容易になります。
脆弱性レポート

脆弱性レポートでは脆弱性の一覧を確認することができます。
今回は依存関係スキャンのみを実行したため、レポートタイプは依存関係スキャンのみです。
他のセキュリティスキャンを実行していた場合は、実行したセキュリティスキャンによって検出された脆弱性も一覧で表示されます。
また、脆弱性レポートから任意の脆弱性を選択すると詳細情報を確認することができます。

詳細画面では、CVE IDや概要説明に加え、脆弱性のある依存関係を含むパスや脆弱性修正済みのバージョン情報が解決策として表示されます。
これにより、単に脆弱性が存在するだけでなく、どの依存関係をどこまで更新すれば解消されるかを具体的に把握できます。
脆弱性レポートに表示される各項目の詳細は下記の通りです。
| 表示項目 | 詳細 |
|---|---|
| CVSSスコア | 脆弱性の影響度を評価した数値 |
| EPSS | 実際に悪用される可能性の高さ |
| ステータス | 脆弱性の対応状況 |
| ソリューション | 脆弱性を解決する方法 |
| プロジェクト | 脆弱性が見つかったプロジェクト |
| リンク | 脆弱性が登録されている外部データベースのリンク |
| レポートタイプ/スキャナー | 出力の種類と検出に使われたスキャナー説明 |
| ロケーション | 脆弱な依存関係が見つかったファイル名 |
| 到達可能性 | 問題の依存関係がコード内で使われているか |
| 既知のエクスプロイト(KEV)の有無 | 脆弱性が既に悪用されたか |
| 説明 | 脆弱性の原因、影響、推奨される対策の説明 |
| 識別子 | CVEなど脆弱性分類のための参照リスト |
| 重大度 | CVSSスコアをベースに6段階に分類 |
まとめ
本記事では、GitLabのCI/CDを用いてSBOMを実際に生成し、出力結果やUI上での確認方法について簡単に紹介しました。
SBOMの重要性が高まる一方で、生成や管理の負荷が導入の障壁となるケースも少なくありません。
GitLabでは、CI/CDパイプラインの一部としてSBOMを自動生成できるため、新たなツールや専用の運用フローを追加せずに、開発プロセスに自然にSBOMを組み込める点が大きな特徴です。
また、業界標準のCycloneDX形式でSBOMを生成するとともに、依存関係リストとして情報をわかりやすく整理・可視化することも可能としています。
これにより、SBOM生成を特別な取り組みとして扱うのではなく、日常的な開発・セキュリティ運用の一部として自然に取り入れることが可能になります。
お問い合わせ
株式会社野村総合研究所(NRI)は、GitLab社と販売代理店契約を締結しており、中でも優れた顧客価値を提供した実績を持つパートナーだけに与えられる「GitLab Select Professional Partner」に認定されています。
DevSecOpsソリューション「aslead DevOps」は、製品・ソリューションの導入からサポートや運用保守まで、ワンストップのトータルサービスを提供しています。
GitLabの導入に関するご相談や費用のお問い合わせ、GitLab無料トライアルの申し込みについては、こちらよりお気軽にお問い合わせください。




