阻止惡意軟體存取生產環境。

---

開發者無需編寫任何可疑程式碼，即可將惡意程式碼注入專案。僅僅安裝一個軟體包就可能構成威脅。該依賴項可能看起來合法，名稱也似曾相識，但卻會在安裝過程中執行惡意程式碼。

這使得軟體包安全問題在應用程式上線生產環境之前就已經存在。首次嚴重安全事件可能發生在Windows開發人員的工作機器上、持續整合 (CI) 運作環境中，或在自動化建置流程中。如果僅在部署階段附近設定控制措施，則整個安全路徑的大部分環節仍會暴露在外。

危險始於開發者的設備。

現代專案依賴龐大的依賴關係樹。開發者可能有意安裝十個軟體包，而套件管理器卻會自動取得數百個傳遞依賴項。很少有人會仔細檢查這條依賴鏈中的每個軟體包，而手動檢查會使正常的開發過程變得緩慢而繁瑣。

攻擊者會利用這種信任。有些惡意軟體套件會試圖竊取環境變數、憑證、瀏覽器資料或驗證令牌。另一些軟體包則會在開發者開啟軟體包之前，透過安裝腳本下載額外的有效載荷或執行程式碼。

在 Windows 系統中，受影響的環境可能包括 PowerShell 會話、套件管理器憑證、SSH 金鑰、雲端工具以及目前使用者帳戶可存取的檔案。 WSL 只是在同一台機器上增加了一個額外的開發環境，並沒有消除潛在的供應鏈風險。

有害的依賴行為並不總是看起來很糟糕。

當惡意元件與開發者預期看到的元件非常相似時，捆綁攻擊就很難被偵測出來。這些攻擊入口點多種多樣：

• 域名搶註： 該軟體包使用的名稱與常見的依賴項僅相差一兩個字母；
• 依賴關係混亂： 通用軟體包與內部相依性衝突，可能會被自動建置過程選取；
• 被竊的管理員帳號： 攻擊者取得部署權限後，受信任的軟體包會收到惡意版本；
• 惡意更新： 一個先前安全的項目在後續版本中改變了其行為，這可能導致 有些工作崗位已經停止運作。؛
• 隱藏的、短暫的後果： 開發者選擇的軟體包下方多個層級都插入了危險代碼。

受歡迎程度並不能保證安全性。一個被入侵的專案可能憑藉先前安全版本累積了多年的良好聲譽，而一個新的惡意軟體包可能在被發現任何可疑行為之前就已經獲得了大量的下載量。

延遲考試可能為時已晚。

許多團隊已經開始進行依賴性檢查，而且這些檢查仍然至關重要。軟體組件分析可以識別已知的漏洞。程式碼庫掃描工具可以發現暴露的機密資訊或危險程式碼。持續完整性安全 (CI) 檢查可防止部署任何問題版本。

但時機在決定這些控制措施能夠預防什麼方面起著至關重要的作用。

如果開發人員在 Windows 終端機中執行安裝命令，而要求的軟體包包含惡意安裝腳本，則該程式碼可能在執行第一個重要的持續完整性 (CI) 檢查之前就在本機執行。即使擁有乾淨的生產環境，也無法完全排除從建造起始機器竊取憑證的可能性。

掃描已知漏洞回答的是完全不同的問題。它能有效找到與已知安全性問題相關的版本，但新發布的惡意軟體包可能還沒有 CVE 編號或已記錄的漏洞資訊。

在允許包裹通過前進行檢查。

一種方法是在開發者或建置系統與軟體包註冊表之間實現控制機制。此控制機制不會允許每個請求的軟體包直接進入環境，而是先對其進行評估，並阻止符合可疑標準的軟體。

這就是依賴防火牆概念背後的基本想法。

關鍵在於決策的時機。可以在安裝前對軟體包進行評估，而不是在軟體包進入環境後才發現問題。相關指標可能包括可疑的部署模式、模仿現有軟體包的新創建軟體包，或其他需要進一步調查的行為。

但這並不意味著控制機制萬無一失。誤報同樣重要。新發布的軟體包可能是合法的，異常的部署活動不一定意味著惡意行為。如果軟體包檢查持續幹擾合法的更新，開發者可能會開始尋找繞過檢查的方法。

Windows 開發也有其自身的弱點。

Windows 開發環境通常會將 Git、Node.js、Python、PowerShell、Visual Studio Code、Docker Desktop、WSL、雲端命令列工具 (CLI) 以及本機儲存的憑證整合到單一工作站上。這使得帳戶權限和本地安全性對於資料包風險至關重要。

幾個簡單的選擇就能縮小潛在的攻擊範圍：

• 盡可能將日常開發工作納入非行政帳戶；
• 避免使用提升的 PowerShell 權限來執行不熟悉的安裝指令；
• 將生產環境憑證與本機開發人員憑證分開；
• 檢查軟體包是否突然插入安裝腳本或安裝後腳本；
• 對於尚未獲得信任的程序，請使用隔離環境。

Windows 安全功能可以在作業系統層面提供協助，但它們無法確定依賴樹中的每個第三方軟體包是否屬於特定項目。

鎖定文件有所幫助，但它們無法確定什麼是安全的。

鎖定檔案使軟體包版本更可預測，並減少安裝之間意外的變更。然而，它們並不能回答鎖定的版本本身是否有害。

單獨使用其他控制措施時，也存在同樣的限制。版本鎖定可確保一致性。程式碼審查可偵測開發人員已能看到的變更。漏洞掃描可發現已知漏洞。端點保護可監控設備上的活動。

團隊還可以要求多因素身份驗證 (MFA) 來部署內部軟體包、刪除已棄用的依賴項、監控 Lockfile 更改、限制不必要的安裝腳本以及調查關鍵第三方專案所有權的突然變更。

最穩健的方法是多層級的。沒有任何單一的控制措施能夠覆蓋從軟體包註冊表到開發人員機器、建置系統和生產環境的整個路徑。

儘早攔截包裹。

生產安全始於生產階段之前。當有害依賴項出現在已發布版本中時，它可能已經經過了開發人員的筆記型電腦、軟體包快取、建置系統和持續整合 (CI) 基礎架構。

將軟體包檢查提前到安裝過程附近，可以縮短檢查窗口期，但並不能消除後續檢查的必要性。對於基於 Windows 的團隊而言，工作站安全至關重要，因為開發設備通常位於原始程式碼、憑證、雲端工具和內部系統附近。

實際問題不在於單一工具能否保證每個軟體包的安全性，而是開發過程能否以多快的速度拒絕一個本不該運行的軟體包。