StableBuild の SBOM 機能でビルド時の依存関係を記録する
製品のリリースごとに SBOM を作成・更新するには、使用したソフトウェアの情報を収集し、各リリースと結び付けて管理する必要があります。完成したコンテナやバイナリの解析は有用ですが、ビルド中だけ使われるツールやパッケージまで把握したい場合には、成果物以外の情報も必要です。
StableBuild は、ビルドで取得した依存関係から SBOM（Software Bill of Materials／ソフトウェア部品表）を生成する機能を、Enterprise プランで提供しています。既存のミラー設定にビルド ID を追加すると、依存関係のダウンロードをビルド単位で記録し、ダッシュボードから CycloneDX 形式で出力できます。
依存関係の固定・保持に使っている仕組みを活用し、最終成果物に残らないビルド依存関係も記録できることが、この機能の特徴です。
成果物の解析を補うビルド時の記録
SBOM は、ソフトウェアのコンポーネントやバージョン、依存関係などを記録するためのものです。新しい脆弱性が公開されたとき、影響を受ける製品やリリースを調べる基礎情報として利用できます。
SBOM ツールには、コンテナイメージやバイナリを解析するもの、ソースコードやパッケージ管理情報を利用するものなどがあります。把握できる範囲は、解析対象と作成方法によって異なります。
例えば、マルチステージビルドでは、コンパイル用のステージでツールやライブラリを取得し、生成した実行ファイルだけを最終イメージにコピーすることがあります。この場合、最終イメージのスキャンだけでは、ビルド時に使ったツールを確認できない場合があります。
StableBuild は、サービス経由で実際にダウンロードされた依存関係を記録します。記録対象のビルドで取得していれば、最終成果物に含まれないビルド依存関係も対象になります。ビルドツールに問題が見つかった際などに、どのビルドで取得したのかを調べる手掛かりとして活用できます。
StableBuild の SBOM に含まれる情報
対象は、ビルド ID を付けて StableBuild 経由で取得した Docker イメージ、OS パッケージ、Python パッケージ、ファイルです。
SBOM は CycloneDX 1.7 の JSON 形式で出力され、各項目にはコンポーネントを識別する package URL（purl）などが含まれます。
| 記録する対象 | CycloneDX のコンポーネント種別 |
|---|---|
| Docker イメージ | container |
| OS パッケージ | library |
| Python パッケージ | library |
| ファイル | file |
記録範囲には条件があります。ビルド ID を付けないダウンロードや、StableBuild を経由しない取得は、この SBOM には含まれません。また、Docker イメージを一つのコンポーネントとして記録することと、その内部の全パッケージを個別に列挙することは異なります。
製品の構成を把握する際には、必要に応じて成果物のスキャン結果や供給元の構成情報と組み合わせて利用します。
日本企業の SBOM 導入と CRA への対応
日本では、経済産業省が2023年に SBOM 導入の手引を公開し、2024年の改訂で、脆弱性管理の具体的な手順、導入範囲を判断する方法、委託先との契約で定める事項を追加しました。ソフトウェアサプライチェーンに関わる企業が、構成情報をどう共有し、管理するかを検討するための資料になっています。
EU 市場に対象となるソフトウェアやデジタル製品を提供する日本企業では、Cyber Resilience Act（CRA／EU サイバーレジリエンス法）への対応も検討する必要があります。
CRA の附属書 I・第 II 部では、製品に含まれるコンポーネントと脆弱性を特定・文書化するため、少なくとも製品のトップレベルの依存関係を含む SBOM を、一般的に使用される機械可読形式で作成することを求めています。
主要な義務の適用は2027年12月11日からです。それに先立ち、製造者には、2026年9月11日から、実際に悪用されている脆弱性や、製品のセキュリティに影響する重大なインシデントを報告する義務が適用されています。
CRA 対応に向けて構成情報を整備する際は、製品に含まれるコンポーネントと、ビルド時だけに使うものを区別する必要があります。CRA が、すべてのビルド依存関係を SBOM に含めるよう求めているわけではありません。また、ビルドで取得したものの一覧が、そのまま出荷製品の完全な構成表になるとも限りません。
StableBuild は、SBOM の作成と依存関係の追跡を支援します。CRA には、リスク評価、脆弱性への対応、セキュリティ更新、技術文書、適合性評価などの要件もあります。StableBuild の導入だけで CRA 全体への準拠が完了するわけではありませんが、対応に必要な構成情報の整備を進めるための一歩となります。
既存のミラー設定にビルド ID を追加する
StableBuild のミラーを利用している場合は、ミラー URL 内の API キーの直後に -- とビルド ID を追加します。PyPI ミラーなら、次のように指定します。your-prefix は、利用中の API キーに置き換えてください。
your-prefix--build-1234.pypimirror.stablebuild.com
CI では実行ごとに固有のビルド ID を割り当て、その実行で利用する各ミラーに同じ ID を設定します。これにより、Docker イメージや Python パッケージなどを、同じビルドで取得した依存関係としてまとめて記録できます。ビルド ID を追加しても、既存の固定日時、キャッシュキー、保存済みファイルは変わりません。
ビルド後は、ダッシュボードで次の操作を行います。
- 「レポート > SBOM」を開く
- 対象のビルドを選ぶか、ビルド ID を入力する
- 「SBOM を生成する」をクリックする
生成されたファイルは、sbom-<ビルドID>.cdx.json という名前でダウンロードされます。取り込み先の管理ツールが対応する形式や必要な項目を確認し、既存の管理プロセスで利用できます。
依存関係の取得と記録を同じ流れに組み込めるため、一覧を手作業で集める負担を減らせます。ビルド ID の文字数制限や CI での設定例は、公式ドキュメントに掲載されています。
Enterprise プランで利用する
StableBuild では、依存関係の固定・保持と SBOM 生成を同じサービスで扱えます。取得したものの記録に加え、保存済みの依存関係を後の調査や再ビルドに利用する運用も組み立てられます。依存関係の保持とビルドの再現性については、こちらの記事で詳しく説明しています。
SBOM 機能は Enterprise プランで利用できます。まずは一つの CI ビルドで試し、記録された依存関係と自社で把握したい範囲を照合すると、運用への組み込み方を検討できます。
設定方法と出力例は、StableBuild の SBOM ドキュメントをご覧ください。
