供應鏈攻擊者不僅試圖將惡意程式碼植入可信任軟體，還試圖竊取維持可信任軟體運作所需的存取權限。最近，在短短 48 小時內，npm、PyPI 和 Docker Hub 就遭遇了三次攻擊，這三次攻擊的目標都是開發者環境和 CI/CD 流水線中的機密信息，包括 API 密鑰、雲憑證、SSH 密鑰和令牌。這是一個持續存在且具有自我傳播性的威脅，正如「迷你 Shai Hulud」攻擊活動所展現的那樣。

這種模式應該會改變安全團隊對軟體供應鏈的看法

傳統上，安全重點在於共享系統，例如原始碼庫、CI/CD 平台、製品註冊表、套件管理器和雲端環境。其目標是保護生產工作負載和資料。我們當然仍然需要關注這些領域，但這只是冰山一角。現代軟體交付始於程式碼到達 Git 倉庫之前。它始於開發人員的工作站，在那裡編寫程式碼、安裝依賴項、測試憑證、呼叫 AI 助理、建置容器，並開始執行可信任操作。

開發人員工作站是軟體供應鏈中不可或缺的一部分，如果僅僅將它們視為普通的終端設備，就會在終端安全、身分安全、應用程式安全和供應鏈治理方面留下漏洞。

供應鏈攻擊已演變為憑證竊取行動

近期發生的事件不斷印證著同一個操作真相。攻擊者可能使用被植入惡意程式的軟體包、被篡改的鏡像、依賴機器人、惡意工作流程或存在漏洞的開發者工具，但他們的最終目標始終是獲取存取權限。

TeamPCP 和 Shai-Hulud 等攻擊事件表明，供應鏈攻擊日益趨向於憑證竊取。在 TeamPCP 攻擊中，攻擊者利用被入侵的軟體包和開發者工具竊取令牌、雲端憑證、SSH 金鑰、npm 設定檔和環境變數。

Shai-Hulud 將這種模式推向了極致，把受感染的開發者環境變成了憑證收集點，從而暴露了 GitHub、雲端服務、軟體包註冊表和內部系統中的數千個秘密。這不僅僅是軟體篡改，而是在開發人員和自動化系統已經建立信任的關鍵節點上竊取憑證。

當攻擊者取得了能夠篡改、發布、建置、部署或冒充受信任軟體系統的憑證和上下文資訊時，供應鏈就會暴露無遺。在現代供應鏈攻擊中，被篡改和發布的軟體包可以持續存在數小時，而自動化工具只需幾分鐘就能合併惡意更新。

最近發生的許多攻擊都有一個共同點，那就是秘密，無論是作為初始存取途徑還是作為收集目標。

攻擊者的攻擊路徑現在會經過開發者端的上下文

開發者工作站之所以重要，是因為它集中了上下文資訊。它通常包含本機程式碼倉庫、.env 檔案、shell 歷史記錄、SSH 金鑰、套件管理器憑證和配置、建置腳本、偵錯日誌以及瀏覽器會話。當這些資訊集中在一起時，其危險性會大大增加。

單一存取令牌單獨來看可能權限有限。但如果令牌與 Git 遠端倉庫、部署腳本、README 檔案、雲端設定檔和 CI 配置等檔案放在一起，攻擊者就能知道該令牌的用途以及它可能解鎖的功能。例如，在 Shai-Hulud 2.0 攻擊活動中，GitHub 憑證在洩漏的憑證中佔絕大多數，每個憑證都可能擁有對程式碼庫和 CI 工作流程的管理員權限。

本地安全漏洞不僅僅是設備問題。它還可以作為原始碼控制、雲端帳戶、軟體包發布工作流程、CI/CD 系統、內部 API 以及生產環境相關基礎架構的藍圖。

開發者機器集中軟體交付權限

普通員工筆記型電腦可能會洩漏公司資料，開發人員工作站則可能具備修改軟體的能力，在考慮終端安全時，這種差異至關重要。

開發人員通常需要廣泛的存取權限才能完成工作。他們克隆私有程式碼庫、對雲端服務進行身份驗證、發佈軟體包、存取測試環境，並與多種內部工具互動。他們的機器成為原始碼、憑證、自動化和交付權限的交匯點。

雖然並非所有開發者都擁有生產環境存取權限，但許多開發者確實擁有足夠的權限來影響最終產生生產結果的系統。註冊表令牌可以影響軟體包，GitHub 令牌可以影響程式碼庫或工作流程。雲端設定檔可以暴露基礎架構，CI/CD 憑證可以影響建構行為。

董事會和審計人員並不關心開發人員是否將機密資訊儲存在本地。真正的業務風險在於，本地外洩會使攻擊者有機可乘，入侵建置、修改、發布或運行軟體的系統。這種轉變改變了安全團隊應該提出的問題：

✔  您能否確定哪些憑證可用於開發人員工作站？

✔  能否限制這些憑證的價值和有效期限？

✔  能否在敏感資訊進入 Git 歷史記錄、CI 日誌、工單、工件或聊天記錄之前將其檢測出來？

✔  當懷疑工作站遭到入侵時，能否快速撤銷並輪換存取權限？

✔  你能區分低影響的本機暴露和具有管理員權限的憑證嗎？

這些問題涉及應用程式安全、端點安全、身分安全、平台安全和雲端安全等多個面向。無論貴組織選擇何種協調方式，都必須了解開發人員的行為與交付系統之間的連結。

自動化和人工智慧技術使曝光錶面更薄、更快

自動化縮短了妥協與影響之間的時間。依賴項更新機器人可以快速開啟和合併變更。持續整合/持續交付 (CI/CD) 系統可以自動執行可信任的工作流程。軟體包管理器可以運行安裝腳本。人工智慧代理和編碼助理可以讀取檔案、呼叫工具、產生命令、檢查輸出並在系統間傳遞上下文資訊。

自動化本身並非不安全，但通常情況下，任何自動化程序都會建立在信任之上，尤其當它以代理形式出現時更是如此。如果惡意依賴項更新看似例行公事，自動化工作流程可能會使其快速推進，而人工審核人員可能根本來不及理解發生了什麼。

人工智慧在循環

AI輔助開發增加了一系列交接點。敏感資料可能出現在提示資訊、終端輸出、工具呼叫、產生的程式碼、代理記憶體、日誌以及複製到偵錯會話中的本機配置。問題不僅限於模型提供者是否儲存提示資訊，更重要的問題是，本地開發情境現在會流經更多半自動化系統。

安全團隊應採用與評估供應鏈風險相同的視角來評估人工智慧編碼風險。團隊需要解答以下問題：該工具可以讀取哪些資料來源和資料？它可以執行哪些操作？輸出結果會送到哪裡？附近有哪些憑證？或許最重要的是，該工作流程繼承了哪些信任關係？

下游管控仍很重要，但僅靠下游管控為時已晚。

程式碼庫掃描、分支保護、CI/CD策略、工件簽章、依賴關係分析和執行時間控制仍然至關重要。它們創建了共同的執行點，並幫助團隊大規模地管理軟體。

如今的問題在於時機，這要歸功於現代攻擊的速度。攻擊者現在利用人工智慧工具，在發現任何秘密後幾秒鐘內就能將其全部利用。

護欄可以減少潛在的暴露風險和爆炸半徑。當開發人員編輯文件、準備提交、執行本機命令、安裝依賴項或與人工智慧助理互動時，護欄可以攔截敏感資料，從而將影響降至最低。

成熟的程序會區分哪些操作應該被阻止，哪些操作應該發出警告，以及哪些操作僅僅應該產生遙測資料以供深入調查。其目標並非讓開發人員陷入繁瑣的作業中。

將工作站視為本地供應鏈邊界

現代軟體供應鏈並非始於程式碼推送之時，而是始於程式碼、憑證、自動化和信任最初匯聚之處。現在是時候將開發者工作站視為本地供應鏈的邊界了，這個邊界涵蓋了整合開發環境 (IDE)、終端、Git 用戶端、套件管理器、容器工具、雲端命令列介面 (CLI)、本機建置系統、金鑰管理規範、人工智慧助理和自動化代理。在這裡，開發者的個人行為會轉化為組織軟體交付的風險。

資料來源：https://thehackernews.com/2026/05/developer-workstations-are-now-part-of.html