はじめに
こんにちは、@tak-tak_beng です。
この記事は 脆弱エンジニアの Advent Calendar 2025 の9日目の記事です。
昨年の自社アドベントカレンダーで、「SBOMを利用した脆弱性管理の導入準備あれこれ」という記事を書きました。
今回は、実際のSBOM生成をしようとした際に遭遇した 「リポジトリサイズが大きいとGitHub CLIではSBOM生成できない」 という課題と、その解決策についてお伝えします。
前提条件・環境
この記事で扱う内容は、以下の環境で検証・運用しています。
- インフラ環境: Amazon EC2 (Amazon Linux 2023)
- 脆弱性管理プラットフォーム: Dependency-Track（Docker Composeで構築）
- SBOM生成ツール: cdxgen（Node.jsベース）
-
GitHub CLI:
ghコマンド（拡張機能advanced-security/gh-sbomを使用）
コードを実行する際は、適宜以下の点を読み替えてください。
-
<cdxgenサーバー>: cdxgenが動作しているサーバーのホスト名またはIPアドレス -
<TOKEN>: GitHubのPersonal Access Token -
XXXXX/YYYYY: 対象となるGitHubリポジトリのオーナー名/リポジトリ名
1. SBOM作成の際に起きたエラー
SBOM（Software Bill of Materials）を利用した脆弱性管理を始めるにあたり、まずは各プロダクトのSBOMを作成する必要がありました。
プロダクト毎に利用しているソース管理や言語が異なるため、作成方法を完全に統一するのは難しいと判断。各担当者にSBOM作成を依頼する際、いくつかの方法を紹介することにしました。
その中でGitHubを利用しているチームは GitHub CLI (gh コマンド) を使って簡単にCycloneDX形式のSBOMが出力できる はずでした。
# こんな感じでサクッといけるはずだった
# ※ gh extension install advanced-security/gh-sbom が必要です
gh sbom -c -l -r XXXXX/YYYYY > 保存ファイル名
（GitHub CLIのSBOM拡張機能については、公式リポジトリを参照）
公式の拡張機能として提供されているものですし、事前にプライベートリポジトリでの確認をした際もCycloneDX形式のSBOMが問題なく生成されていました。
しかし、実際に試してみると、開発担当者からは エラーが発生してSBOM生成ができない との報告があったのです。
# エラーメッセージ
YYYY/MM/DD HH:mm:ss non-200 OK status code: 502 Bad Gateway body: "{\n \"data\": null,\n \"errors\":[\n {\n \"message\":\"Something went wrong while executing your query on YYYY-MM-DDTHH:mm:ss+00:00. This may be the result of a timeout, or it could be a GitHub bug. Please include `xxxx:xxxxx:xxxxxx:xxxxxx:xxxxxxxx` when reporting this issue.
2. 公式の拡張機能でエラー…何が起きた？
2-1. 問題はリポジトリサイズ
この問題は、GitHub CLIのSBOM拡張機能のIssue #6で報告されていました。
リポジトリサイズが一定以上大きいとエラーとなる というのが真相で、現時点でも解決されていないようです。
大規模なコードほど管理したいのに、これでは使えません。公式の拡張機能なのに、まさか使えないとは...というのが率直な感想でした。
2-2. GitHub WebUIから出力できるSBOM
ここで、「じゃあGitHubのブラウザ画面（WebUI）からダウンロードすれば？」と思う方がいらっしゃるかもしれませんが、GitHubが標準でエクスポートするSBOMは SPDX形式 です。
対して Dependency-Track がネイティブでサポートしているのは CycloneDX形式。
そのままでは取り込めないという、地味ながら痛い罠があります。
参考:
3. 解決策
GitHubの機能に頼れないなら、自前でやるしかありません。
Node.jsベースのSBOM生成ツール cdxgen を使うことにしました。cdxgenは、CycloneDX形式のSBOMを生成できるツールで、様々な言語やパッケージマネージャーに対応しています。
3.1 実装方法
Dependency-Trackが動いているEC2インスタンスに cdxgen を導入し、サーバーサイドで生成させることにしました。
cdxgenのAPIを利用して、 curl でリポジトリURLを叩くと生成する方法を使うことでひとまずは解決です。
# cdxgenサーバーを叩いてSBOMを取得するイメージ
curl "http://<cdxgenサーバー>/SBOM?url=https://<TOKEN>@[github.com/XXXXX/YYYYY.git](https://github.com/XXXXX/YYYYY.git)" > sbom.json
ここでは cdxgen の公式ドキュメント記載のリポジトリスキャン方法 に従い URL にトークンを含めています。
商用環境などで利用する際は、サーバーのログ設定に注意するか、可能であればサーバー側の環境変数（GITHUB_TOKEN）等で認証情報を管理することを検討してください。
4. さらなる自動化
今後、脆弱性管理の対象を広げていくにあたり、より手軽にSBOMを作成する仕組みを準備するべきであると考えました。
そこで、ソースコードの圧縮ファイル（zipとtar.gzに対応）を指定のフォルダへアップロードすると、そこからSBOMを作成する仕組みを作りました。
この自動化により、Gitリポジトリ以外のソースコードからもSBOMを生成できるようになり、運用の幅が広がりました。
まとめ
GitHub CLIのSBOM生成機能は、公式の拡張機能として提供されているものの、大規模リポジトリでは使えないという限界があります。また、GitHub WebUIからダウンロードできるSBOMはSPDX形式のため、CycloneDX形式を必要とするDependency-Trackではそのまま使えません。
この課題を解決するため、cdxgenを使ったサーバーサイド生成という方法を採用しました。これにより、GitHub CLIで生成できなかった大規模リポジトリでも、問題なくSBOMを生成できるようになりました。
さらに、圧縮ファイルからの自動生成システムを構築することで、より柔軟なSBOM生成の運用が可能になりました。
実際にSBOMを作成、登録して、脆弱性管理は順調に進むのでしょうか？(どう見てもフラグ)
後半は管理面の話になるので、明日の記事にて記載をさせていただきます。
また、ビジネスエンジニアリング株式会社では自社でも独自の アドベントカレンダー を実施しています。よろしければこちらもご覧ください！