建議先在隔離流水線試點 Swift 6.4 SBOM，並優先於建置時產生、隨建置產物歸檔；只有生成成功、內容可核驗、清單能追溯至產物，才逐步推廣。若改在建置後單獨產生，還要額外確認依賴圖與實際建置狀態一致。Swift 6.4 的 SBOM 功能及格式已由官方發布說明確認；功能細節則應對照SE-0509 實作說明。
適合企業安全或合規負責人：將軟體物料清單要求落實為 Swift 專案交付證據。
適合 CI 平台負責人：準備把 Swift 6.4 SBOM 接入既有 macOS 建置流水線。
適合 iOS／macOS 技術負責人：確認 Swift Package 依賴清單是否對應實際建置產物。
最後更新於 2026 年 10 月 7 日；功能狀態核對自Swift 6.4 發布說明及SwiftPM 官方文件。企業仍須以自身 CI 紀錄驗證產物關聯，不能把官方功能描述當成自己的驗收結果。
[ SECTION_01 ] 階段一：界定 SBOM 要證明的範圍
SBOM 是軟體物料清單，不等於完整的供應鏈安全證明。生成成功只代表工具輸出了清單；是否包含預期依賴、是否對應實際建置，以及能否回溯到發布產物，都需要另外驗收。
開始接入前，先決定團隊要採用 SPDX、CycloneDX，或因下游工具需求保留兩種格式。Swift 6.4 為 SwiftPM 提供這兩種 SBOM 生成功能，實際輸出與使用方式須依發布說明和提案文件核對。也要界定清單代表的是 Swift Package，還是某個具體發布產品；兩者的範圍不可混為一談。
Swift 6.4 SBOM 應不應作為 CI 建置產物保存？應保存，並與同一次建置的產物及紀錄建立明確關聯。只把 SBOM 留在暫存目錄，或以套件名稱相似作為對應依據，都不足以支援後續稽核與事件追查。
[ SECTION_02 ] 階段二：盤點專案輸入與交付邊界
先整理專案實際使用的工具鏈、SwiftPM 呼叫方式、依賴鎖定檔管理規則，以及最終發布產品。尤其要查清 Package.resolved 是否納入版本控制、建置工作是否會更新解析結果，以及 SBOM 產生時讀取的是哪一份依賴狀態。
Swift Package Manager SBOM 的範圍須配合專案結構檢查。SwiftPM 管理的套件，不必然涵蓋應用程式引入的所有元件；例如不由 SwiftPM 管理的依賴、外部工具、預先編譯的二進位檔與發布流程另行加入的內容，可能需要其他清單或核驗方式。可參考SwiftPM 新增依賴的文件和套件結構說明，逐項標記哪些屬於本次 SBOM 的涵蓋範圍。
分工也要在試點前寫清楚：應用團隊提供專案、產品及依賴鎖定狀態；CI 平台團隊提供工具鏈版本、執行方式及歸檔位置；安全或合規團隊定義格式、必要欄位與放行條件。缺少任何一方的輸入，最後都可能只得到一份「有檔案、無法證明範圍」的清單。
[ SECTION_03 ] 階段三：選擇生成路徑
Swift 6.4 支援在 swift build 建置流程中產生 SBOM，也支援透過 swift package generate-sbom 單獨生成；命令能力與實際限制應以SE-0509 實作說明為準。以下比較的是流水線驗收取捨，不代表任何未經測試的相容範圍。
| 路徑 | 主要輸入與優點 | 驗收風險 | 流水線適配評分 |
|---|---|---|---|
| 建置時生成 | 與建置流程同時執行，較容易把 SBOM 綁定到該次建置的依賴狀態與產物 | 仍須確認實際涵蓋的產品、依賴及輸出檔案，不能只看命令成功 | 對發布流水線適配度高 |
| 建置後單獨生成 | 可在建置完成後按需要補產生清單，較方便用獨立工作處理輸出 | 依賴包圖可能與建置時狀態不同，需證明解析狀態未改變 | 適合有額外比對證據的流程 |
SwiftPM 單獨生成 SBOM 與建置時生成有何差別？差別不只在工作放在哪個 Job。建置時生成較容易與當次建置脈絡一併留證；單獨生成則要記錄生成所用提交、鎖定檔與解析狀態，再與已建置產物的依賴圖比對。官方文件說明功能邊界，並不替企業確認兩次操作讀取的是同一份輸入。
[ SECTION_04 ] 階段四：在隔離流水線固定輸入
先從非生產分支或隔離 CI 工作開始，不要直接把新檢查設為生產發布的阻擋條件。固定該工作使用的 Swift 工具鏈與提交狀態，並在執行前檢查依賴鎖定檔；若流程會重新解析依賴，需把解析結果和變更一併留存。
依官方支援的命令與參數選定 SPDX 或 CycloneDX 輸出，再逐項驗證：
- 命令是否在預期的工作目錄執行，生成程序是否回傳成功。
- SBOM 是否寫入約定的輸出位置，檔案是否確實進入 CI 歸檔。
- 清單是否涵蓋選定的套件或產品，格式能否由下游工具讀取。
- 生成失敗、清單缺漏或歸檔失敗時，流水線要停止、隔離產物，還是交由人工判定。
SwiftPM 的套件描述與依賴宣告方式可參照PackageDescription 文件。基礎設施團隊可以評估集中設定，但不能未經專案驗證就把警告模式視為合規通過；否則命令報警仍可能一路放行。
[ SECTION_05 ] 階段五：核對內容並綁定建置產物
Swift 6.4 SBOM 怎麼確認對應實際建置產品？以同一提交、同一筆建置紀錄及同一份歸檔產物為核對對象，檢查 SBOM 內的套件、產品與依賴關係是否符合預期。只比對分支名稱或套件名稱，不能證明清單與產物出自同一次建置。
建置後才生成的清單，還要比對生成前後的依賴鎖定狀態與解析結果。若無法證明狀態一致，就不能把該清單標記為原建置產物的可靠對應證據。保存提交識別、工具鏈資訊、生成命令與輸出檔案的關聯，讓稽核人員能從產物回查生成輸入。
以下條件用來決定是否准入：
- 若建置時生成成功，內容涵蓋已定義的產品範圍，且 SBOM 與產物、提交均能對應，則可進入試點驗收。
- 若採建置後生成，但有保存並核對前後依賴狀態的證據，則可有條件驗收；否則回退到建置時生成。
- 若清單缺漏、命令失敗、歸檔不完整，或無法證明與產物關聯，則暫停放量，回到輸入固定與生成路徑排查。
[ SECTION_06 ] 階段六：灰度驗收並安排 Mac CI 承載
先以試點結果決定逐倉庫推廣、由平台統一加入流程，或暫緩接入。驗收紀錄至少應能查到工具鏈、提交識別、SBOM 檔案、對應的建置產物，以及生成失敗後的處置結果。這些是企業自己的流水線證據，不是 SwiftPM 生成命令成功就自動具備的保證。
在 Mac CI 上，工具鏈一致性、執行權限、依賴鎖定檔存取與產物保存路徑，都會影響清單能否穩定重現。先用實際工作檢查執行環境是否符合團隊要求，再比較現有自管 Mac 與遠端 Mac。需要評估遠端執行環境時，可先查看遠端 Mac 建置環境選項；也可從NOVAKVM 服務入口了解承載方式。本文未取得本站實際配置、交付週期或節點資料，因此不對性能、成本或地域作推定。
若現有方案靠開發者個人 Mac，常見問題是工具鏈與權限難以統一、產物歸檔分散，而且人員設備未必能長時間穩定執行 CI。若改為臨時新增自管節點，則要另行承擔採購、維護與閒置容量管理。對需要暫時補足 macOS 執行環境的團隊，租用 NOVAKVM 遠端 Mac 可作為與現有節點並行評估的選項；但若工作負載長期穩定且高密度，或必須使用特定實體介面，自購 Mac 可能更合適。無論選哪種承載方式，都應先用實際流水線驗證工具鏈、權限與 SBOM—產物歸檔鏈，再決定是否擴大使用。