先掌握實際交付物，而不只是原始碼
企業系統使用的程式碼，只有一部分由內部團隊撰寫。套件管理器會帶入大量直接與間接依賴，容器映像檔還包含作業系統套件、執行環境與建置工具。若團隊只檢查 Git 儲存庫，卻不知道正式環境實際執行哪個映像檔、映像檔由哪個基底建立，就很難在漏洞公開或套件遭竄改時快速判斷影響範圍。
第一步不是購買更多掃描工具，而是定義責任與資料流。每個服務都應有負責團隊、原始碼位置、建置流程、映像檔儲存庫與部署環境。正式交付物要能回溯到提交版本與建置紀錄；反過來，也要能從某個有問題的元件查出哪些服務正在使用。這種雙向追溯能力，才是後續弱點管理、事件應變與稽核的基礎。
套件管理要兼顧可重現性與更新速度
應用程式依賴應透過鎖定檔固定完整版本，並在 CI 中使用可重現的安裝模式。只在設定檔中指定寬鬆版本範圍，可能讓同一份原始碼在不同日期產生不同結果。另一方面，永久鎖死版本也會累積漏洞與相容性債務，因此團隊需要固定的更新節奏，由自動化工具提出變更，再經測試與審查後合併。
公開套件庫方便，但不應被視為無條件可信。對核心系統而言，可使用受控的套件代理或私有鏡像，保留已核准版本並降低外部服務中斷的影響。不過，私有鏡像本身也成為關鍵基礎設施，需要權限控管、完整性驗證、備援與清理政策。若沒有維運能力，盲目複製整個公開套件庫，通常只是把風險搬進內網。
- 來源：限制允許使用的套件庫，防止名稱相近套件、未知來源與未受控下載。
- 版本：提交鎖定檔，禁止正式建置自行解析浮動版本，並保留套件雜湊值。
- 審查：新依賴需檢查維護狀態、授權、發布紀錄、權限需求與間接依賴規模。
- 更新：將安全更新分成可立即處理、需相容性測試與暫時接受風險三類。
- 移除：定期找出未使用或功能重疊的依賴；最安全的套件，往往是根本不需要引入的套件。
把容器映像檔視為不可變的正式產品
容器部署應以映像檔摘要識別，而不是只依賴可被重新指向的標籤。建置完成後，同一個已驗證映像檔應從測試環境一路晉升到正式環境，避免每個環境重新建置而產生內容差異。團隊也應固定基底映像檔版本，使用多階段建置排除編譯器與暫存檔，並讓程序以非 root 身分執行。
映像檔越精簡，攻擊面與掃描雜訊通常越少，但極度精簡的映像檔也會增加除錯成本。Distroless 類型適合行為穩定、可觀測性完整的服務；需要現場診斷的工作負載，則可保留最低限度的工具，並透過偵錯容器處理臨時需求。重點不是追求最小容量，而是清楚知道每個元件為何存在。
掃描應同時涵蓋作業系統與應用程式套件，但不能只用嚴重度分數決定是否阻擋發布。團隊還要判斷漏洞是否存在於執行路徑、是否能被外部觸發、是否已有修補版本，以及服務本身的暴露程度。對可利用且有修補版本的問題設定發布門檻；對無法立即修補者，記錄風險接受期限與補償控制。映像檔簽章與建置來源證明則可用來確認交付物確實來自受信任的流水線。
讓 SBOM 成為事件應變資料，而不是稽核附件
SBOM 應在每次建置時自動產生，採用 SPDX 或 CycloneDX 等可由工具處理的格式，並與映像檔摘要、提交版本及建置紀錄綁定。若 SBOM 與實際部署版本分離，即使內容完整，也無法可靠回答某個環境是否受影響。產出的清單應保存於可查詢的位置，並設定與交付物一致的存取權限與保留期限。
當新漏洞出現時，處理流程應先查詢受影響元件及版本，再定位相關映像檔、服務、環境與負責人。接著結合掃描結果、執行環境與 VEX 資訊判斷可利用性，而不是要求所有團隊對每一筆掃描結果立即升級。這能減少無效工作，也能把注意力集中在真正暴露的系統。
最後，應定期演練從一個套件名稱追查到正式服務，並驗證能否重建、修補、重新簽章與部署。SBOM 本身不會阻止攻擊；它的價值取決於資料是否準確，以及工程、維運與資安團隊是否能用它採取行動。若系統橫跨雲端、ERP、CRM、LINE 或 IoT 平台，整合團隊可協助建立共同的產物識別與治理流程，但各服務的風險責任仍應清楚歸屬。