依賴鎖定實戰：lockfile 能防住什麼，防不住什麼
一個被過度信任的機制
「我們用了 lockfile，依賴是鎖定的。」這句話在安全評審裏出現的頻率很高，而它通常被當作一個終止討論的答案。
lockfile 確實重要。但它解決的是構建一致性問題：讓今天的構建和三個月後的構建裝到完全相同的依賴樹。這和「依賴是安全的」之間，隔着好幾個問題。
lockfile 擋得住什麼
版本漂移。 沒有 lockfile 時，^1.2.0 這樣的語義化版本範圍會在每次安裝時解析到最新的兼容版本。這意味着兩個開發者、或者開發環境與 CI，可能裝到不同的代碼。lockfile 消除了這種不確定性。
間接依賴的意外變化。 你的直接依賴沒變，但它的某個傳遞依賴發了新版本——沒有 lockfile 時這會靜默進入你的構建。這類變化正是很多「昨天還好好的」故障的來源。
部分投毒場景。 如果攻擊者是通過發佈一個新的惡意版本來投毒（這是最常見的手法之一），那麼鎖定在舊版本的項目不會自動受影響。這是 lockfile 提供的真實安全價值——但它是被動的、有條件的。
lockfile 擋不住什麼
已經鎖在裏面的漏洞。 這是最直接的一點：如果你鎖定的那個版本本身有漏洞，lockfile 會忠實地、可復現地、每次都把這個漏洞裝進來。鎖定不等於安全，它只等於「一致」。而且 lockfile 會讓你更不容易注意到——因為不再有版本變化觸發你去看一眼。
首次引入時就是惡意的包。 lockfile 鎖的是你已經決定要用的東西。如果引入決策本身就錯了（裝了一個 typosquatting 包、裝了一個 AI 幻覺出來的包名），lockfile 只會把這個錯誤固化下來。
同版本號內容被替換。 多數生態的 lockfile 會記錄完整性校驗值（如 npm 的 integrity 字段），這能防止內容被篡改。但如果你的 lockfile 是從一個已被污染的環境生成的，或者校驗值本身就是基於惡意內容計算的，鎖定就失去了意義——信任鏈的起點必須是乾淨的。
構建環境與依賴之外的攻擊面。 構建腳本、CI 配置、鏡像源、編譯器本身——lockfile 對這些一概不管。SolarWinds 式的構建環節攻擊，完全不需要碰依賴樹。
過期本身的風險。 諷刺的是，lockfile 用得太好會帶來新問題：依賴長期不更新，安全補丁進不來。鎖定和更新之間需要平衡，而不是選一個極端。
配套實踐
一、鎖定 + 持續掃描，不可分開。
lockfile 提供了一份精確的依賴清單，這恰恰是持續漏洞比對的理想輸入。把 lockfile 作為 SCA 的掃描對象，新漏洞情報到達時就能立即回答「我們受不受影響」。鎖定的價值只有配合監控才能完全兑現——否則它只是把風險固定住了。
二、lockfile 變更進代碼評審。
每一次 lockfile 變動都意味着依賴樹發生了變化。這應當是一個顯式的、被人看到的決策，而不是構建時的副產品。評審時要問：誰引入的、為什麼、傳遞依賴帶進來了什麼。
三、分級的更新策略。
補丁版本可自動更新（安全修復通常在這一級）、次版本需測試通過、大版本必須人工評估。配合 Dependabot 或 Renovate 這類工具，讓更新成為日常小步走，而不是一年一次的大掃除。
四、內部鏡像 + 完整性校驗。
所有依賴經由內部製品倉庫獲取，配合 lockfile 的完整性校驗，構成「內容確定 + 來源可控」的雙重保障。這也順帶解決了依賴混淆攻擊。
五、區分開發依賴與運行時依賴。
lockfile 通常兩者都包含，但風險性質不同：運行時依賴直接進入生產攻擊面，開發依賴影響的是構建環境。分別設定更新節奏和審查強度，能把有限的注意力放在更要緊的地方。
正確的期待
lockfile 是可復現構建的基礎設施，是依賴管理的必要條件——但不是充分條件。把它理解為「確定性工具」而非「安全工具」，你就會自然地去補上真正缺的那部分：持續的漏洞監控、顯式的引入決策、以及對構建環境本身的保護。
一句話概括：lockfile 保證你每次裝到同樣的東西，SCA 才告訴你那個東西有沒有問題。
---
