許多工程師在思考軟體供應鏈安全（Software Supply Chain Security）時，直覺會想到的是保護 Git 倉庫、CI/CD 流水線或是 Docker Registry 等集中式平台。我們習慣認為，只要這些「共享設施」夠安全，程式碼在進入生產環境前就能被攔截掉惡意變更。
然而，最新的攻擊趨勢顯示，這種思維存在巨大的漏洞。攻擊者的目標已經從單純的「篡改程式碼」轉向「竊取存取權限」，而最容易獲取這些權限的地方，正是開發者的本地工作站（Developer Workstation）。
開發者工作站：被忽略的供應鏈起點
在現代的開發流程中，程式碼在被 push 到 Git 之前，已經在開發者的電腦上經歷了撰寫、安裝依賴套件、測試 API 金鑰以及透過 AI 助手生成代碼等過程。這意味著工作站才是供應鏈的真正起點。
如果我們將開發機僅僅視為一個普通的終端設備（Endpoint），而忽略它與軟體交付權限的關聯，就會在端點安全、身分驗證與供應鏈治理之間留下危險的縫隙。
從程式碼篡改轉向憑證收割
近期發生的 TeamPCP 與 Shai-Hulud 等攻擊事件揭示了一個核心事實：攻擊者利用中毒的套件（Poisoned Packages）或惡意工具，其最終目的往往不是為了在軟體中植入後門，而是為了進行憑證收割（Credential Harvesting）。
他們目標明確地鎖定開發環境中的機密資訊，例如： API Keys：存取雲端服務或第三方 API 的金鑰。 SSH Keys：用於遠端伺服器登入的私鑰。 .env 檔案：存放環境變數與機密設定的本地檔案。 Tokens：GitHub 或 npm 等平台的人機認證權杖。
一旦攻擊者拿到了這些憑證，他們就不需要辛苦地去破解防火牆，而是可以直接以「受信任身分」進入系統，修改程式碼、發布惡意版本或直接操控雲端基礎設施。
為什麼開發機對攻擊者如此有價值？
開發機不僅僅是存放檔案的地方，它更像是一張「權限地圖」。單獨一個 Token 可能權限有限，但如果攻擊者能同時獲取 Git 遠端設定、部署腳本、雲端設定檔與 Shell 歷史紀錄，他們就能迅速拼湊出整個公司的基礎設施圖譜。
開發者為了工作效率，通常擁有較高的權限（例如能推送到特定分支、能發布 npm 套件、能存取 Staging 環境）。這種「交付權限」使得開發機的風險遠高於一般行政人員的筆電。
自動化與 AI 縮短了攻擊路徑
現代開發工具的演進，無意中加速了攻擊的傳播速度：
自動化工具（Automation）：依賴更新機器人（Dependency Bots）可能會在極短時間內自動合併惡意更新，讓攻擊在人類審核之前就已完成部署。 AI 助手（AI Coding Assistants）：AI 在讀取本地檔案、執行指令或生成代碼時，可能會不經意地將敏感資訊（如金鑰）納入上下文（Context）或日誌中，增加了機密外洩的表面積。
雖然下游的控制措施（如分支保護、產出物簽名、運行時監控）依然重要，但這些是在事情發生後的補救。當攻擊者利用 AI 快速掃描並使用憑證時，這些防線往往來不及反應。
實務上的安全思考轉型
對於安全團隊與工程主管來說，我們需要將開發工作站視為「本地供應鏈邊界」。這意味著安全防禦不能只在雲端，而要前移到 IDE、終端機（Terminal）與套件管理器中。
在實務上，我們可以思考以下幾個問題來強化防禦： 哪些憑證允許在開發機上使用？是否能限制其生命週期（TTL）？ 能否在機密資訊進入 Git 歷史或 CI 日誌之前就攔截到？ 當懷疑工作站被入侵時，能否快速撤銷並輪替（Rotate）所有相關權限？ 如何區分低風險的本地洩漏與具有管理權限的高風險洩漏？
目標不是要增加開發者的摩擦力（Friction），而是建立一套能區分「阻斷」、「警告」與「紀錄」的成熟機制，在不影響開發效率的前提下，將風險控制在最小範圍內。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。