Swift 6.4 SBOM 和 macOS CI 產物對不上？2026

CI 已產生 SBOM，但清單中的依賴與交付檔案對不上。
最快的處理方式：先確認生成命令讀取的是套件解析圖還是建置圖，再核對 Package.resolved、產品範圍及生成時點；格式通過不等於清單已與交付物綁定。

Swift Package 維護者：需要把 Swift 6.4 產生的 SBOM 納入依賴審核或交付流程。
Apple 平台 CI 工程師：要確認清單涵蓋的是實際建置的產品，而非整個套件或不同目標。
研發安全與合規負責人：需要判斷現有生成、封存及追溯資料是否足以支持團隊審查。

最後更新於 2026 年 10 月 26 日；資料依據為 Swift 6.4 發布說明、SwiftPM SBOM 文件及 SE-0509 提案。

SECTION 01 先定位差異：格式正確，不代表範圍正確

Swift 6.4 已加入 SwiftPM SBOM 生成功能，這項功能已在官方發布資料中確認；但你仍須分開驗收兩件事：檔案能否依格式解析，以及檔案內列出的元件是否對應本次實際建置、準備交付的產品。發布資料與提案說明了功能狀態與設計範圍，不能替代專案本身的交付核對。

發現不一致時，先把問題分成四種證據：依賴圖來源不同、目標產品不同、清單生成時間不同，以及檔案無法追溯至同一建置。元件數目較多或較少，本身都不能證明 SBOM 完整或錯誤；你需要找到是哪一項輸入或流程不同。

Swift Package Manager SBOM 為何可能比實際建置範圍更廣？

Swift Package Manager SBOM 可能根據解析後的套件資訊產生；而建置流程可掌握建置系統實際使用的依賴圖。兩者回答的問題並不相同：前者偏向「套件解析了哪些相依項目」，後者著重「這次建置依賴哪些項目」。SE-0509 說明了兩種資料來源及可選用的建置系統資訊，應依你採用的生成方式核對，而不是直接把元件列表當成相同範圍。SE-0509 的依賴圖與選項說明

這也解釋了為何條件式依賴、產品依賴及建置條件可能影響清單與建置結果的比較。若只看解析結果，清單可能包含本次產品沒有使用的依賴；若只看建置結果，也不能據此宣稱已涵蓋整個套件所有可能的產品與組態。你應先訂出驗收邊界：要交付的是某個產品、某個建置組態，還是整個套件的依賴概況。

多產品專案的 SBOM 範圍要怎樣核對？

在多產品專案中，生成「整個套件」的清單，不等同於針對某一個產品生成或核對清單。逐一比對產品名稱、CI 建置命令和輸出的 SBOM 檔案；不要把某個產品的清單當成整個應用程式的依賴聲明。關於產品描述與套件相依關係，可參考 PackageDescription 的 Package Dependency 文件。

同時確認你檢視的是產品層級還是 target 層級資訊。target 是套件中的建置單位，產品則是套件提供給使用者或其他套件使用的輸出邊界；兩者不必然一對一。若某個 SBOM 顯示了你預期之外的元件，先確認它是否來自同一產品所需的其他 target，而不是先刪除該元件或斷定生成器出錯。

swift package generate-sbom 與 swift build 的清單差在哪裡？

不要只依命令名稱推斷清單範圍。獨立執行 swift package generate-sbom 時，應按你使用的 SwiftPM 版本及選項，確認它取用的套件解析資訊和可用的建置圖資訊；從建置流程取得的清單，則要確認它對應的是哪次建置、哪個產品與哪個建置條件。SwiftPM 生成 SBOM 文件與命令文件可用來核對當前命令行介面。

避免把不同時間執行的兩條命令輸出直接比較。先以目前工具鏈執行 swift package generate-sbom --help 和 swift build --help，再對照該版本的官方文件確認選項語義；不要把其他 Swift 版本的參數直接複製到 Swift 6.4 CI。若生成步驟無法取得本次建置圖，就要把它標記為套件解析範圍的清單，而非宣稱它精確呈現該次建置的產品依賴。

SECTION 02 依時間線取證：解析、建置、生成、封存

第一個檢查點：鎖定同一提交與解析狀態

先記錄 CI 使用的提交識別資訊、工具鏈版本與 Package.resolved，再確認建置和 SBOM 生成發生在同一工作目錄、同一套依賴解析狀態。Package.resolved 用於記錄已解析的套件版本資訊；如果它在建置與清單生成之間被改動、重新解析，或來自另一個工作目錄，兩份輸出便可能並非同一組輸入。PackageDescription 對 Package.resolved 的說明

第二個檢查點：核對產品和實際建置命令

把 CI 中的產品名稱、建置命令及輸出路徑記下來，確認 SBOM 生成選取的範圍與交付項目一致。若管線同時建置多個產品，應逐個留下對應關係；只保存一份沒有產品標識的清單，會讓後續審核者無法判斷它代表哪個輸出。

第三個檢查點：排除建置後重新解析

比對 SBOM 生成步驟前後的 Package.resolved 與套件狀態。若生成命令在獨立步驟中重新解析依賴，或使用另一份檢出內容，清單可能呈現後續解析狀態，而不是已建置產物使用的狀態。命令是否會使用建置圖、可以選取哪些產品，應以當前版本的 SwiftPM SBOM 文件和提案選項說明為準。

第四個檢查點：分開驗證格式、內容與來源

CycloneDX 或 SPDX 檔案可以先做格式解析，但這僅驗證序列化內容是否符合相應格式規則，不會自動證明依賴範圍正確，也不會證明它來自某個已封存的二進位產物。CycloneDX 提供 SBOM 驗證指南；SPDX 的序列化與驗證要求則見官方規格文件。

再檢查清單內的產品與依賴關係是否符合專案預期，並為檔案命名或附加可追溯資訊，使其能對應提交、CI 工作及產品。不要宣稱 SwiftPM 會自動替 SBOM 簽章，或自動把清單綁定至二進位檔；若團隊需要這種關聯，必須由自己的交付流程保存並驗證相應資料。

第五個檢查點：把 macOS 建置與封存證據留在同一流程

涉及 Apple 平台工具鏈的建置、測試或發布流程，應在符合專案需求的 macOS 與 Xcode 環境執行；其他環境可以協助檢查格式、保存檔案或執行一般資料比對，但不能取代必須使用 Apple 工具鏈的步驟。若交付內容包含應用程式封存或發布，將 SBOM 與建置記錄、封存輸出及提交資訊一起保存，並參照 Apple 的應用程式測試與發布流程確認交付環節。

這裡的驗收重點不是「清單成功輸出」，而是日後能從清單回到相同的提交、解析狀態、產品和建置結果。若團隊正在整理 macOS CI 的產物保存方式，可參考遠端 Mac 上的 Xcode 專案備份與產物留存方向，再依自身的封存與存取要求調整。

SECTION 03 交付前可勾選清單

• [ ] 記錄本次 CI 的提交識別資訊、Swift 工具鏈版本與執行環境。
• [ ] 保存建置使用的 Package.resolved，確認生成前後沒有被替換或重新解析。
• [ ] 寫明 SBOM 是基於套件解析圖、建置圖，或該工具版本實際提供的其他範圍。
• [ ] 對照產品名稱、建置命令與清單檔案，確認每份清單對應正確的產品。
• [ ] 分開記錄格式解析結果、依賴內容審核結果及產物追溯結果。
• [ ] 將 SBOM、建置記錄與交付輸出一併封存，讓審核者能從清單追溯至同一建置。

以下對照表適合用來定位差異，但不能取代前述同一提交的驗收。尤其不要以清單大小、格式驗證成功或檔名看似正確，作為範圍一致的單一證明。

若目前用 Linux 節點承擔整條流程，Apple 工具鏈相關建置無法由它取代；若改由本地 Mac 共用，則需自行處理節點可用性、環境一致性與交付留存。長期固定、高負載且需要實體介面的工作，購買並維護自有 Mac 可能更合適；但若你只需在特定開發或驗收階段取得真實 macOS 環境，租用 VPSNIX 的遠端 Mac 可免去先購置硬體，並將環境取得與 CI 驗收分開規劃。你可先按工具鏈、存取方式及使用週期核對VPSNIX 的租用方案，再決定是否將 SBOM 復現工作移至遠端 Mac。