ビルドは成功しているのに、SBOMが実際のリリース成果物を表しているか説明できない。
最初は隔離したCIで試し、優先してビルド時に生成したSBOMを成果物と一緒に保管してください。生成後の別工程で作る場合は、依存関係がビルド時と一致することを追加確認します。
この手順は、ソフトウェア資材表の要件をSwiftプロジェクトの証拠に落とし込むセキュリティ・コンプライアンス担当者向けです。
macOSのビルドパイプラインへSwift 6.4のSBOM生成を導入するCI基盤担当者、依存パッケージとリリース成果物の対応を確認するiOS・macOS責任者にも役立ちます。
最終更新：2026年10月7日。Swift.orgのリリース情報、SwiftPMの公式文書、SE-0509の実装説明を照合しました。 導入後の適合性は、各社のCI記録と成果物を使って別途検証してください。
[ SECTION_01 ] 受け入れ基準を先に決める
SBOMの生成成功だけでは、ソフトウェアサプライチェーンの安全性を証明できません。証明したい対象が依存パッケージの一覧なのか、実際のビルドで使われた依存関係なのか、リリース製品の追跡情報なのかを、先に分けて定義します。
Swift.orgは、Swift 6.4が2026年9月15日に公開され、SwiftPMによるSPDXとCycloneDXのSBOM生成に対応したと発表しています。機能の公開状況と規格形式はSwift 6.4のリリース情報で確認できます。
受け入れ条件は、次の3点を別々に判定できる形にします。
- 生成できること： 対象のCIジョブでSBOMが出力され、形式と保存先が確認できる。
- 内容を照合できること： 対象製品、SwiftPMパッケージ、依存関係が設計上の範囲と合っている。
- 成果物を追跡できること： コミット、ビルド記録、SBOM、配布対象の成果物を結び付けられる。
SPDXとCycloneDXの両方が必要か、片方で足りるかは、セキュリティ部門や納入先の要件に合わせて決めます。また、SBOMがどの単位を記述するかも明記してください。パッケージ単位の一覧だけで、アプリケーション全体を網羅したと扱うのは避けます。
[ SECTION_02 ] 導入前にプロジェクトの境界を棚卸しする
最初に記録する入力は、CIが使うSwiftツールチェーン、SwiftPMの呼び出し方、依存関係の固定方法、リリース対象の製品です。Package.resolvedをどのブランチや工程で管理しているかも確認し、CIが参照する状態を記録します。
SwiftPMの依存関係は、公式の依存パッケージ追加文書とPackageDescriptionの仕様を参照し、実際のプロジェクト設定と突き合わせます。パッケージ構成の前提はSwiftPMのパッケージ概要でも確認できます。
棚卸しで見落としやすいのは、SwiftPMが管理する範囲と実際のアプリが使う全資材の範囲が一致するとは限らない点です。別の依存管理手段で導入するもの、外部工程で取得・生成するもの、SwiftPMの対象外にあるバイナリなどは、別途管理が必要か判断します。SwiftPMのSBOMだけで全依存関係を網羅したと断定しないでください。
責任分担も入力として確定します。アプリチームは製品範囲と依存関係を提示し、CI基盤チームは実行環境と保存先を用意します。セキュリティ担当者は形式、必要項目、受け入れ条件を決め、各チームがどの記録を残すか合意します。
[ SECTION_03 ] 生成経路を要件に合わせて選ぶ
Swift 6.4のSBOMを企業CIに入れる際は、ビルドと一緒に生成する方法と、swift package generate-sbomで別途生成する方法を分けて評価します。SE-0509はSwiftPMの生成機能とビルド時の生成経路を説明しています。具体的なオプションや制約はSE-0509の提案・実装説明に沿って確認してください。
- ビルド時に生成： 実際のビルド工程と同じ記録にまとめやすい経路です。成果物とSBOMを同じジョブで保管し、ビルド時の依存関係を確認したい場合に優先します。
- 別工程で生成： ビルドとSBOM生成を分けたい場合に使えます。ただし、生成対象のパッケージ情報が、成果物を作った時点の依存関係と一致することを追加で検証します。
SwiftPMのSBOM単独生成とビルド時生成は、どこが違いますか。
別工程の生成はパッケージの依存関係情報を基にした一覧になり得ます。一方、ビルド時生成では構築工程に結び付いた依存関係を確認できます。どちらを選んでも、実際の成果物との対応はCI側で照合しなければなりません。
生成経路を選ぶため、次の条件分岐で試験結果を判定します。
- ビルド時の依存関係と成果物を同じジョブで記録できる場合は、ビルド時生成を選びます。
- 生成工程を分離する必要があり、依存関係を固定して生成前後の状態を照合できる場合は、別工程で生成します。
- 依存関係の状態を固定・照合できない場合や、成果物とSBOMを関連付けられない場合は、どちらも本番採用せず、入力の固定と保管経路の整備に戻ります。
評価は次のように付けると、チーム間の判断をそろえやすくなります。ここでの「高・中・低」は一般的な性能評価ではなく、各組織の要件に対する適合度です。
- ビルド時生成：適合度 高 — ビルド記録と同じ工程でSBOMを出力・保管でき、検証責任者が明確な場合。
- 別工程の生成：適合度 中 — 依存関係を固定し、生成前後の状態を比較する証拠を保存できる場合。
- どちらも適合度 低 — 依存関係が変わり得るのに固定・照合できない、または成果物との関連記録を残せない場合。まず入力と保管経路を整えます。
[ SECTION_04 ] 隔離したCIで生成条件を固定する
本番の配布ジョブへ一括導入せず、非本番ブランチまたは隔離したCIジョブから始めます。ここでは、使用するSwiftツールチェーン、コミット、依存関係のロック状態、生成コマンド、出力先を記録します。公式のSwiftPM文書はSwiftPMのコマンドと機能の案内を起点に確認できます。
CIのビルド中にSBOMを出すには、何を確かめますか。
採用するSwiftPMの操作とオプションをSE-0509の説明で確認し、対象のSwift 6.4環境で生成結果を検証します。オプション名や利用条件を別バージョンの記憶で補わず、CIで実行したコマンドとツールチェーンの記録を残してください。
試験ジョブでは、少なくとも次を確認します。
- 指定したSPDXまたはCycloneDX形式でファイルが出力される。
- 出力先がアーカイブ工程から参照でき、別ジョブや後処理で上書きされない。
- 対象の製品とパッケージが、導入前に決めた範囲と一致する。
- 生成失敗時にジョブを成功扱いするか停止するかが、セキュリティ要件として明文化されている。
生成に失敗した場合、警告だけで通してよいですか。
警告モードを合格扱いにするのは、例外条件、承認者、期限、代替証拠を事前に定めた場合に限ります。生成失敗や対象外の依存関係が見つかったら、承認なしで配布工程へ進めず、原因と例外処置を記録します。
[ SECTION_05 ] SBOMを構築物と照合して同じ保管単位にする
照合対象は、同じコミットから作られたビルド記録、SBOM、リリース成果物です。SBOM内のパッケージと依存関係を、事前に合意した製品範囲と比較します。ファイルが生成されたという事実だけでは、対象のアプリを説明する証拠になりません。
SwiftのSBOMが実際の製品に対応しているか、どう判断しますか。
コミット識別子とビルド記録を起点に、SBOMの対象製品・依存関係とアーカイブ済み成果物を照合します。別工程で生成した場合は、生成前後で依存関係が変わっていないことを記録で確認します。差分を説明できない場合は、対応済みと判定しません。
CIの保管単位には、ツールチェーンの記録、コミット識別子、SBOM、成果物への参照、検証結果を含めます。権限設定では、ビルド担当者が成果物を扱える範囲と、SBOMを変更・削除できる範囲を確認します。保存後にファイルが差し替わった場合に追跡できる保管方式かも、社内の監査要件と照合してください。
不足、生成失敗、成果物との不一致があれば、配布を止めて依存関係の固定、生成工程、対象製品の指定を調べます。原因を直した後、同じコミットまたは再現可能な入力で再生成し、照合記録を更新します。
[ SECTION_06 ] 試験証拠から段階導入の可否を決める
試験が通ったら、各リポジトリへ個別導入するか、CI基盤で共通設定にするかを決めます。共通設定はばらつきを抑えやすい一方、プロジェクトごとの対象製品や例外を確認せず適用すると、範囲違いを見逃すおそれがあります。まず差分の小さいプロジェクトで検証し、同じ受け入れ基準を満たすものから広げます。
SBOMはCIの成果物として保管すべきですか。
リリースを後から追跡する要件があるなら、SBOMを対応するビルド成果物と同じ記録単位で保存します。別の場所に保管する場合でも、コミット、ビルド記録、製品との関連をたどれる参照を残してください。
段階導入の前に、次の受け入れリストを確認します。
- [ ] 使用したSwiftツールチェーンとコミット識別子を記録した。
- [ ] SBOMの形式と対象範囲を、セキュリティ要件に照らして確認した。
- [ ] SBOM内のパッケージと依存関係を、実際の構築物と照合した。
- [ ] 成果物、SBOM、ビルド記録を相互に追跡できる。
- [ ] 生成失敗、不一致、例外の扱いと承認者を定めた。
すべて確認できた場合は、同じ基準で対象リポジトリを広げます。生成は成功しても依存関係に差が残る場合は、差の説明と別工程の状態確認を加えて再判定します。成果物との関連を示せない、または失敗を検知できない場合は、展開を保留し、アーカイブと失敗処理を先に修正します。
受け入れ記録には、使用ツールチェーン、コミット識別子、SBOMファイル、対応する構築物、照合結果、失敗時の処置を含めます。これらがそろって初めて、生成機能の導入と企業CI上の運用確認を分けて説明できます。
Swift 6.4のSBOM導入で必要なのは、生成コマンドを足すことだけではありません。依存関係の境界、成果物との照合、保管と例外処理をCIの証拠としてつなぐ必要があります。Mac CIの実行環境を比較する際は、まずリモートMacの利用条件を確認し、社内のツールチェーン固定、権限、成果物保管要件に合うかを実ジョブで評価してください。
既存のMacを使い続ける方法は、機材管理や環境差の統制が必要です。汎用CI環境では、必要なmacOS実行環境を継続利用できるかを先に確認しなければなりません。専用機の調達も、導入後の保守と更新を含めて判断します。短期の試験や追加ノードが必要なら、Mac miniの調達・利用条件も比較対象にし、実際のSwift 6.4ジョブでツールチェーン、権限、SBOMと成果物の保存経路を確認してから選定してください。