AI 時代該具備的資安意識 (1) 個人預防篇

最近軟體業界資安議題頻傳，不僅是在個別軟體產品層級，有許多業界主流的程式語言、執行環境與框架，也陸續傳出漏洞案例。舉例來說，PHP、Node.js 都出現相當嚴重的漏洞。

當年 Ilya Sutskever 離開 OpenAI，創辦以安全為目標的 SSI（Safe Superintelligence）時，曾經引起業界廣泛討論。老實說，當年看到這個新聞時，我們還很難理解這件事的迫切性，但隨著 AI 能力持續提升，以及近期資安攻擊手法的演變，我們也開始更加理解，為什麼 AI 時代下的安全問題需要受到高度重視。

在過去，一位懂資安攻擊的駭客，因為個人時間有限，能去找漏洞攻擊的時間也有限。然而，現在當同一位駭客能夠指揮數十、上百個 AI 代理去找漏洞，漏洞被找出的速度會比過往快很多。

在近期在軟體資安領域還有看到一個觀點，是值得大家更加警惕的：目前 GPT 與 Claude 等模型的廠商，針對安全對齊有相當程度的投入，讓模型會遵守安全規範、避免協助有害行為。換句話說，當駭客想要使用這類模型從事資安攻擊行為時，模型會傾向拒絕。

然而，有部分開放權重模型 (open-weight models) 在安全對齊上並沒有對應的投入。這讓攻擊者更容易繞過安全限制，而隨著開放權重模型的能力持續提升，攻擊者取得強大 AI 的門檻也可能隨之降低。在這個背景下，可以預期接下來的攻擊事件可能會發生得更頻繁。

對此，我們接下來預計會有三篇系列文。第一篇會從個人預防的角度切入，談工程師平常能做什麼來預先降低攻擊風險。第二篇會從個人應對角度切入，談假如真的出事了，可以如何快速回應、縮小損失。最後一篇則會從團隊的角度切入，談資深工程師可以為團隊導入哪些制度與措施，讓安全不只是依賴個別工程師的小心謹慎。

工程師平常可以養成哪些安全習慣？

回顧近期發生的資安事件，從軟體工程師的角度來說，有許多能夠做的事，不論在個人專案，或是在工作上都能夠嘗試 (假如在工作上，目前的公司還沒有做，可以試著成為那個推動改變的人)。以下讓我們逐一來討論。

依賴套件版本鎖定

近期許多重大軟體資安事故之所以波及範圍廣泛，是因為這些事故發生在軟體供應鏈的上游。先前我們在透過 API 避免重複造輪子 有談過這個比喻，比起重複造別人已經製作過的輪子，過去在軟體業界普遍存在重複利用的習慣；而這就像供應鏈一樣，不是什麼都自己做，有些東西從上游直接用。

在軟體供應鏈的時代背景下，過去軟體工程的最佳實踐之一，是持續更新依賴套件，避免使用過時、有已知漏洞的版本。相信大家在工作上或多或少用過的 Dependabot、Renovate 等工具，就是在這個背景下普及的。

在過去，假如使用的某個版本，後來被發現有漏洞，假如平常沒有持續更新版本的習慣，很可能要一次升到修正後的版本會困難重重，甚至讓許多開發者覺得痛苦。

然而，近年來幾起重大供應鏈攻擊，不是在舊有版本找漏洞，而是攻擊者直接透過奪取權限等手段，直接發布植入惡意程式碼的新版本，然後在那些沒有發現的人更新後趁虛而入。甚至也有出現 PHP 的 Laravel-Lang 供應鏈攻擊中，攻擊者直接改寫既有版本的 Git 標籤，將惡意程式碼覆蓋到某個既有版本的狀況。

不管是哪一種模式，都推薦要有版本鎖定的習慣；與此同時，除非是緊急安全相關修正，版本更新要在更新冷卻期到了後再進行。舉例來說，先前的 Axios 漏洞出現在 1.14.1 版，在新版本出來沒多久就被辨別出是帶有惡意攻擊的新版本，這時如果沒有馬上更新，基本上不會受到立即影響。

2026 年 7 月，GitHub 宣布 Dependabot 預設對一般版本更新會有 3 天冷卻期，因為 GitHub 研究 2018 至 2026 年間受到廣泛報導的供應鏈攻擊，認為三天等待期可以避開其中多數短時間內被發現、撤下的惡意版本。當然，這不是說 3 天就一定能避免，但至少就目前社群資安研究人員偵測的速度來說，3 天冷卻期能降低自己成為第一批受害者的機會 (有其他研究認為要更久，例如 Google Cloud 的安全研究推薦要 7 天冷卻期)。

與此同時，在做版本鎖定時，要搭配鎖定檔 (lockfile)。因為鎖定檔會依套件管理器的設計，記錄對應 Git 提交的完整性雜湊，以 PHP 的 Composer 為例，使用既有鎖定檔執行 composer install，可以避免重新解析依賴版本，避免不知不覺取得遭到替換的套件。

但透過鎖定檔，當攻擊者修改已經發布的版本，讓同一個版本號指向不同的程式碼，由於 Git 提交的雜湊不同，所以能夠辨別出是不同的程式碼，降低意外更新的風險。

減少第三方依賴，必要時自行維護

上面一段我們討論了針對依賴套件的預防措施，對比起持續依賴第三方套件，近期業界也出現更激進一點的觀點。舉例來說，開源社群知名工程師 Mitchell Hashimoto 主張，比起直接用第三方套件，他認為更好的做法，是把依賴套件分支出來自行維護，刪除不需要的功能，除非使用者真的受到影響，否則不要更新。每次更新都應該能指出具體需要哪一筆程式碼變更。

這個觀點背後除了對軟體供應鏈利弊的挑戰 (例如明明只用一個小功能，卻要裝一個巨大的依賴，很可能弊大於利)，更重要的是把依賴套件的控制權拿回來。在他的主張下，如果目前自己維護的版本夠用，沒有必要去升級或追加功能，這樣能夠減少被漏洞影響的可能。

過去他的這個主張，經常會被抨擊不實際，因為自行維護分支需要一定程度的成本，特別是對於那些比較複雜的套件來說，要自行維護有時幾乎不太可能。然而，在 AI 代理大量參與開發實作的時代，這個成本變得不如過往大，所以近期有看到越來越多團隊朝這個方向走。

加入 E+ 會員方案

如果你覺得這篇分享有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。

許多 E+ 會員透過所任職公司的教育訓練補助 (E+ 會開立有統編的發票)，不用花自己的錢，也能每週透過深度主題文與社群交流，拓展技術視野、加速職涯成長。