供應鏈
軟體供應鏈安全最佳實務
一份實用的檢查清單，從第一個 commit 到版本發布後該做的事。每個段落都從投入最少、保護最多的步驟開始，因此您隨時可以停下來，而且狀況都會比原本更好。
更新日期
原始碼
- 要求強式驗證。每個程式碼託管帳號都要使用多重要素驗證。
- 保護主要分支。合併前必須經過審查，並且不允許任何人直接推送到發布分支。
- 不要把機密放進程式碼。每次推送都掃描機密，並輪替任何已外洩的機密。
- 把工作流程檔案當成程式碼看待。對管線的變更可能觸及您的機密，因此要求由負責人審查。
相依套件
-
提交鎖定檔（lockfile）並據以安裝。使用
npm ci及其他生態系的對應指令，避免建置意外引入新版本。鎖定檔有其限制，但它是起點。 - 為新版本設定等待期。惡意版本通常在出現後不久就會被發現，因此不在版本發布當天就採用，能給這件事發生的機會。
- 限制安裝腳本。能停用就停用。安裝時執行的腳本正是 npm 蠕蟲的散播途徑。
- 審查新的相依套件。檢查名稱是否為錯字搶註套件，並留意維護狀況與熱門程度。OpenSSF Scorecard 可將其中一部分自動化。
- 保護內部套件名稱。使用 scope 與套件登錄庫設定，避免公開套件透過相依性混淆取代內部套件。
- 移除不需要的套件。每個相依套件都是另一個需要監控的對象。
建置與 CI/CD
- 將 GitHub Actions 釘選到完整的 commit 雜湊值。標籤可以被移動，tj-actions 遭入侵事件已證明這一點。
- 限制每個作業的權限。只給工作流程權杖所需的最低權限，並使用短效憑證取代長期有效的機密。
- 限制對外流量。建置只需要從已知來源取得套件，並發布到已知位置。封鎖其他一切連線，遭竊的機密就無處可去。請參閱 GitHub Actions 對外連線政策。
- 在全新、隔離的環境中執行每個作業。任何東西都不應從一個作業延續到下一個作業，尤其是外部貢獻者的 pull request。
- 把快取視為一種輸入。遭汙染的快取會在建置之間持續存在，而它還原的內容很容易被忽略。請參閱 GitHub Actions 快取。
完整清單請參閱 CI/CD 管線安全檢查清單，以及 執行器安全性比較。
版本發布
- 每個版本都從建置產生 SBOM。將它與建置產物一起保存。請參閱 SBOM 最佳實務。
- 簽署建置產物並發布來源證明（provenance）。使用者便能查證版本的來源。 SLSA 定義了各個等級。
- 只在 CI 中建置正式版本。從筆電發布的版本背後沒有可靠的紀錄。
- 從測試到正式環境使用同一個建置產物。推進您測試過的產物，而不是重新建置，讓紀錄保持真實。
版本發布後
- 監控您已出貨的內容。持續以新漏洞比對仍受支援版本的 SBOM。
- 排定優先順序時不只看 CVSS。請結合 CISA KEV、EPSS 與實際情境。請參閱如何排定漏洞優先順序。
- 掌握您曝險了多久。建置歷史會顯示哪些版本包含某個套件，以及從何時開始。
- 在需要之前就備妥計畫。決定由誰研判、由誰修正、由誰與客戶溝通。請參閱 漏洞管理生命週期。
- 以真實情境演練。問問自己：找出所有包含某個套件的版本需要多久？如果答案是好幾天，就從這裡開始。
該先做什麼
| 時程 | 要做的事 |
|---|---|
| 本週 | 多重要素驗證、在 CI 中使用鎖定檔、釘選 GitHub Actions、最低權限的工作流程權杖 |
| 本月 | 每個發布建置都產生 SBOM、有負責人的相依套件警示、機密掃描 |
| 本季 | 建置的對外流量規則、已出貨版本的監控、經過演練的應變計畫 |
| 下一步 | 經簽署的來源證明、正式檢視 SLSA 或 NIST SSDF 的涵蓋程度、供應商 SBOM |
CRACI 涵蓋其中哪些項目
CRACI 涵蓋建置及其後的一切。作為您的 GitHub Actions 執行器，它在各自隔離的虛擬機器中執行每個作業，將作業下載的每個套件記錄到 SBOM 中，標示從 CI 快取還原的套件，並執行對外連線政策，封鎖建置不需要的連線。之後它會持續檢查已出貨的內容，顯示哪些建置包含有漏洞的套件，並可透過政策關卡阻擋建置。
其餘部分仍由您的其他工具負責：CRACI 不掃描原始碼或機密，不會依行為偵測新的惡意套件，也不簽署 SBOM 或來源證明。請參閱 軟體供應鏈安全工具比較，了解各項缺口由哪些工具填補。
軟體供應鏈安全最佳實務：常見問題
如何保護軟體供應鏈？
透過每個發布建置產生的 SBOM 掌握您出貨的內容，以鎖定檔與審查控管引入的套件，藉由限制機密與對外流量保護建置，並持續監控已發布的版本。
小型團隊應該先做什麼？
啟用多重要素驗證、在 CI 中從鎖定檔安裝、將 GitHub Actions 釘選到 commit 雜湊值，並只給工作流程權杖所需的最低權限。這些步驟只需幾天，就能封住常見的攻擊途徑。
如何防範惡意套件？
沒有任何單一步驟能做到。延後採用新版本、限制安裝腳本並審查新的相依套件。限制建置的對外流量，可在惡意套件闖關成功時降低損害。
為什麼要將 GitHub Actions 釘選到 commit 雜湊值？
因為版本標籤可以被移到不同的程式碼上。完整的 commit 雜湊值永遠指向同一份程式碼，因此遭劫持的標籤不會進入您的管線。
應該多久檢視一次供應鏈？
監控應該持續進行。相依套件政策、工作流程權限與應變計畫至少每年檢視一次，且在您的技術堆疊發生任何資安事件後也要檢視。