まず今週、SBOM生成がパッケージの解決済み依存グラフを使ったのか、ビルド時の依存グラフも反映したのかを確認してください。次にPackage.resolved、対象製品、生成タイミングを照合します。ファイル形式の検証に通っても、納品物との一致は証明できません。同じコミットと再現可能なCI環境で生成・保存・再確認するのが基本です。
Swift Packageの依存監査にSwift 6.4のSBOMを取り入れるメンテナー向けです。
macOS CIの製品範囲とSBOMの一致を確認するCIエンジニアにも役立ちます。
SBOMの生成・保管・追跡手順を点検する開発セキュリティ担当者も対象です。
最終更新：2026年10月26日。 Swift 6.4の公開状況とSBOMの仕様は、Swift 6.4のリリース情報、SwiftPMのSBOM生成ドキュメント、SE-0509を照合しています。以後、SwiftPMの仕様や文書が更新された場合は、手元のツールチェーンで挙動を再確認してください。
SECTION 01 最初に、何を「一致」と判定するか決めます
生成されたSBOMの存在は、ファイルが出力されたことを示すだけです。SBOMの依存範囲が適切か、特定のアプリ製品に対応するか、手元のバイナリと同じビルドから作られたかは、別々に確認する必要があります。
調査を始める前に、CIが納品する対象を特定します。アプリ本体、補助ツール、複数の実行ファイルをまとめて出すのか、それともSwift Package単体を公開するのかを明確にし、比較対象となるアーカイブや配布ファイルも記録します。Xcodeを使う配布工程は、Appleのアプリのアーカイブと配布手順を参照し、どの成果物が実際の納品物かを先に決めてください。
なぜswift package generate-sbomとビルド時のSBOMで範囲が変わるのでしょうか。
生成方法によって、参照される依存情報が同じとは限らないためです。swift package generate-sbomによる独立した生成と、ビルドに結び付いた生成について、利用した依存グラフとオプションを記録してください。SE-0509のオプションとサブコマンドの説明を確認し、実行環境に導入されたSwiftPMのヘルプとも突き合わせます。
パッケージ全体を対象にした依存一覧と、特定製品のビルドで使われた依存一覧は、目的が異なります。構築条件や製品依存、フィルタリングによって対象範囲が変わるため、記載されたコンポーネントの件数だけで「漏れなく含まれている」と判断しないでください。依存範囲の根拠を、コマンド、オプション、ビルド対象と一緒に残すことが重要です。
SECTION 02 製品と依存グラフを分けて調べます
Swift Package ManagerのSBOMは、macOS CIでビルドした製品の依存関係をどう反映させますか。
パッケージ全体とビルド対象の製品を区別し、生成時にどの依存グラフを参照したかを確認します。SwiftPMのSBOM生成仕様では、ビルド関連の情報を扱う方法や生成範囲が定められています。必要な情報が独立生成コマンドだけで得られると仮定せず、ビルドに結び付いた生成方法が現在のツールチェーンでどう記載されているかを確認してください。
次に、CIが選択した製品名と、実際のビルド命令、出力先の対応を調べます。複数製品を持つPackageでは、一製品のSBOMをアプリ全体の依存一覧として扱うと、対象範囲を誤認するおそれがあります。製品ごとに、生成されたファイル名、対象製品、ビルド成果物を対応付けてください。
依存解決の状態も記録対象です。PackageDescriptionの依存関係に関する説明を確認し、CIが使ったPackage.resolvedが対象コミットのものか調べます。ロックファイルとSBOMの取得元が異なる、あるいは生成コマンドがビルド後の別ステップで実行されている場合は、依存解決が再実行されていないかも確認してください。
生成ステップをビルドの後ろに置いただけでは、同じ状態を見たとは限りません。CIログで、コミット、依存解決、ビルド、SBOM生成の順番が追えるようにしてください。
複数製品のPackageでは、どこを見ればSBOMの対象違いを見つけられますか。
各製品について、ビルド命令の対象、生成時の対象指定、ファイル名、出力された成果物をひと組で比較します。パッケージ単位のSBOMが存在していても、納品対象である特定のアプリ製品に対応するとまでは言えません。
SECTION 03 形式検証、範囲確認、追跡を混同しない
SBOMの確認は、少なくとも三つの問いに分けます。ファイルが規格に沿って読み取れるか、必要な製品と依存関係が含まれるか、どのコミットとCIビルドから得られたか、です。ひとつの検査に合格しても、残りの確認が済んだことにはなりません。
SwiftPMのドキュメントが扱う形式として、CycloneDXとSPDXがあります。ファイルがパーサーで読めることは形式面の確認です。CycloneDXのSBOM検証ガイドやSPDX 3のシリアライズと検証ルールを使って形式を確認した後、製品名や依存関係が意図した範囲と一致するかを別途レビューしてください。
さらに、SwiftPMがSBOMの生成に対応していることと、生成ファイルが自動でバイナリに署名・結合されることは同じではありません。コミットID、CIジョブの識別情報、製品名、生成時点、成果物の保存場所を記録し、ファイル名だけに由来の追跡を任せないでください。SBOMと成果物の対応が外部のレビュー担当者にも追えるよう、ビルド記録とともに保管します。
SECTION 04 同じコミットで照合する受け入れ手順
次の項目を上から実行してください。差異が出た場合は、形式の修正より先に、対象範囲と生成元を確定します。
- [ ] CIで対象とするコミットIDとブランチを記録し、作業ツリーに未コミット変更がないことを確認する。
- [ ] そのコミットの
Package.resolvedを保存し、CIログに同じ依存解決状態が使われたことを残す。 - [ ] 納品する製品名とビルド命令を記録し、パッケージ全体と製品単位のどちらを確認するか明記する。
- [ ] SwiftPMの現在のコマンド文書と実行環境のヘルプを確認し、依存グラフの種類と生成オプションを記録する。コマンド文書も参照し、独立したSBOM生成とビルド工程の境界を確認する。
- [ ] ビルドとSBOM生成を同じCIジョブ内で行い、どちらが先か、依存解決を再実行する処理が間に入っていないかをログで確かめる。
- [ ] 生成ファイルをCycloneDXまたはSPDXとして検証した後、製品、依存関係、コミットID、ビルド成果物との対応をレビューする。
- [ ] 成果物、SBOM、
Package.resolved、実行ログを同じジョブの記録にまとめ、CIの外へ取り出した後にも対応関係が保たれているか再確認する。
この検証では、SwiftPMのSBOM生成とAppleのビルド工程が必要な箇所をmacOS CIで実行し、形式検証や記録のレビューは要件に応じて別工程に分けられます。Linuxなど別環境を使う場合でも、Appleのビルド成果物が必要な工程まで置き換えられるとは限りません。まず現行のCIで各工程の実行場所を明示し、再現条件を記録してください。
SECTION 05 今週の判定基準
次回の配布前に、対象製品、Package.resolved、依存グラフ、SBOM生成時点の四点が同一コミットに結び付いているか確認してください。形式検証だけが済み、製品範囲や生成元を追えない場合は、SBOMを納品物と一致した証拠として扱わず、同じCIジョブで再生成・再確認するのが安全です。
macOS CIを一時的に再現するだけなら、専用機を購入する方法のほか、Macのリモート利用も比較対象になります。Linux環境だけではAppleのツールチェーンを使う工程を完結できず、手元のMacは常時稼働するCIノードとして保守が必要です。一方、長期間の連続負荷や物理接続が前提なら、レンタルより自社保有機が適する場合もあります。短期の検証環境が必要なときは、VPSNIXの料金と利用条件を確認し、接続や利用上の確認事項はヘルプセンターで先に照合してください。