核心命題： 你花錢加固自己的機房，但攻擊者可能根本不從那裡進來。現代企業的攻擊面，有很大一部分位於別人的系統上。 本文角度： 風險機制拆解與檢查清單。不含任何操作細節。
為什麼「自己的門鎖好」不等於安全
傳統的防守思路是：把自己的邊界收緊。但在今天的技術堆疊裡，一個企業的執行路徑是這樣的：
自己寫的程式 → 呼叫幾十個開源套件 → 跑在雲端服務上 → 靠 CI/CD 自動部署 → 用 SaaS 工具做協作 → 由外包團隊維護部分系統
這條鏈上任何一環被控制，攻擊者就等於拿到了進入你環境的鑰匙——而且不需要突破你自己的任何一道防線。
四個環節，四種風險機制
環節一：開源套件——「你沒寫的那部分程式碼」
現代應用程式中，自家編寫的程式碼通常只佔很小一部分，其餘來自開源套件。這帶來三種風險：
風險一：被偷換。 攻擊者取得套件發布權限（例如竊取維護者的憑據），在原套件中植入惡意邏輯，所有依賴它的專案在下一次更新時一併中招。
風險二：名稱混淆。 發布一個與熱門套件名稱相似（拼寫略有差異）的假套件，誘使開發者誤裝。
風險三：長期潛伏。 先發布一個看似正常、有用的套件，累積使用者之後再在某一版加入惡意行為。
防守含義： 「鎖定版本 ＋ 校驗指紋」是最基本的一步。成熟的團隊會把依賴版本的雜湊值寫進設定檔，安裝時自動比對——確認拿到的確實是原版，而不是被掉包的版本。
環節二：外包與服務商——「你信任的人也被信任著」
很多企業把系統開發、維運、客服外包出去。這帶來兩個問題：
問題一：權限過大。 服務商為了方便，往往要求比你內部員工更大的權限——而且長期不撤。
問題二：橫向傳染。 服務商同時服務多家客戶。如果它被攻破，攻擊者可以以它為跳板，一次接觸多家企業。
防守含義： 服務商的存取應該遵循與內部員工相同的原則——最小權限、即時授權、完整記錄。而且要問一個關鍵問題：它被攻破時，你能多快撤銷它的存取權？
環節三：雲端依賴——「你看不見的那一層」
把系統搬上雲端之後，一部分安全責任轉移給了雲廠商（共享責任模型）。但這帶來一個常見誤解：「上了雲就自動安全」。
實際上，雲端安全事件絕大多數不是雲廠商被攻破，而是客戶配置錯誤：儲存桶公開、權限過寬、日誌未開、密鑰洩漏。
防守含義： 雲端環境需要的是「配置治理」，而不是「買了服務」。持續檢查設定、自動化偵測異常配置，比事後補救重要得多。
環節四：工具鏈與 CI/CD——「自動化把風險也自動化了」
自動化部署讓「改一行程式碼就上線」成為常態。但如果 CI/CD 系統本身被控制，攻擊者可以：
- 在構建過程中植入惡意程式碼（而且不留下原始碼層面的痕跡）；
- 讀取部署時用到的密鑰與憑證；
- 直接部署任何想要的版本。
防守含義： CI/CD 系統應該被視為最高價值的資產之一——它的權限、密鑰、存取記錄都需要特別對待。
攻擊方為什麼喜歡供應鏈
從攻擊者的角度看，供應鏈有三個明顯優勢：
- 一次攻擊、多方受害——效率遠高於逐家突破；
- 繞過既有防線——從「你信任的來源」進來，很多檢查不會觸發；
- 隱蔽性高——惡意行為可能藏在正常更新中，長時間不被發現。
一份可直接使用的檢查清單
開源依賴
- 是否有完整的依賴清單（含版本與雜湊）？誰維護？
- 是否自動掃描已知漏洞？掃描結果由誰跟進？
- 新增依賴是否有審批流程？
第三方服務商
- 是否清點過所有可存取你系統的外部方？
- 它們的權限是否最小化、是否有到期時間？
- 被攻破時，撤銷存取的流程需要多久？
- 合約中是否有安全義務條款與稽核權？
雲端環境
- 是否定期檢查公開儲存桶與過寬權限？
- 是否啟用雲端審計日誌，並有人定期查看？
- 長期密鑰是否存在？能否改用臨時憑證？
CI/CD 與工具鏈
- 部署系統的存取權限有哪些人持有？
- 構建過程中使用的密鑰如何管理？
- 是否有「部署內容與原始碼不一致」的偵測能力？
治理
- 是否有負責供應鏈風險的明確角色？
- 最近一次第三方風險檢視是什麼時候？
三個一句話
- 攻擊面已經不在你的機房內。 只加固自己的系統，等於只鎖了一道門。
- 供應鏈風險的核心是「信任的傳遞」。 你信任服務商，攻擊者只需信任一次就能借道。
- 檢查清單比恐慌有用。 大部分供應鏈事件源於基本項目未做，而不是高深攻擊。
下一步
- 想了解雲端環境的憑據形態變化，可閱讀雲端身分與權限
- 想了解憑據在攻擊鏈中的位置，可閱讀憑據與 AD 概念層
- 想從整體防禦視角檢視，可閱讀從紅隊復盤看防禦