驗證進入發布版本的內容

先確認是否需要相依項目

代理程式可能建議使用看似能解決問題的套件。這是提案，不能證明套件存在或適用。安裝前，驗證確切的套件儲存庫、發布者、套件名稱和版本。

以虛構 CSV 匯出為例，執行環境可能已提供所需行為。新套件仍可能適用，但會增加維護責任與執行路徑。比較實作所需投入，以及相依項目帶來的持續責任。

審查授權條款與支援的執行環境。檢查維護活動和相關資安公告。熟悉的名稱，在另一個套件儲存庫可能代表不同套件。安裝成功只能說明安裝已完成。

檢查安裝與建置行為

相依項目可能在安裝或建置期間執行程式碼。限制這些環境的存取憑證與網路存取。處理不可信 PR 的工作，不應取得正式環境的機密值。

生態系支援時，使用已提交的鎖定檔，並要求建置遵循它。隨原始碼變更一起審查鎖定檔變更，包括非預期的間接相依套件。固定版本有助於重現建置，但不會讓有弱點的版本變安全。

NIST 的 SSDF 涵蓋整個生命週期中的軟體保護與開發實務。設計建置環境時，採用這個較完整的觀點。閱讀框架。

區分元件清單與來源證明

軟體物料清單（SBOM）記錄軟體中的元件。元件出現疑慮時，它能協助找出受影響版本；但單靠清單，無法證明元件安全。

來源證明（provenance）說明建置產物如何產生。SLSA 定義了記錄建置及其輸入資訊的來源證明格式。驗證時，必須將資訊連結到可信的產生者，以及打算使用的建置產物。只有一個名為「provenance」的檔案並不足夠。SLSA 來源證明。

為匯出服務記錄可檢查的證據鏈：

1. 已審查的 commit 指出已接受的原始碼。
2. 建置記錄指出輸入與執行環境。
3. 建置產物有穩定的摘要值。
4. 檢查記錄指出受檢的產物或原始碼。
5. 部署記錄指出放入目標環境的產物。

核准後，避免在沒有明確驗證流程的情況下，以不同方式重新建置。latest 這類可變標籤，之後可能指向不同映像檔。

判斷發現的問題代表什麼

判斷弱點需要上下文：受影響版本、受影響行為能否被觸發、暴露程度、可用修補和後果。記錄每項暫時例外的依據，指定負責人、到期日和複查觸發條件。

不要因為一項發現不適用，就停用整個掃描器。掃描未完成時，不要宣稱結果沒有問題。逾時、不支援的套件或無法取得的資安公告來源，都代表缺少證據。

最後，規劃發布後的更新。新公告可能影響昨天已接受的產物。服務負責人需要元件清單、應變流程，以及產出修正版所需的資源。

繼續閱讀持續弱點管理，了解如何將反覆掃描連結到經過驗證的正式環境修補。