最近這段時間，不知道大家有沒有發現，資安漏洞好像突然變得特別多？

幾乎每天都有新的 CVE 被揭露，而且動不動就是高風險漏洞，甚至可能讓攻擊者直接取得系統權限。

看起來好像整個軟體世界突然變得非常不安全。

但我一直在想一個問題：

到底是我們的軟體突然變得不安全了，還是那些原本就存在的問題，現在才開始被大量發現？

其實，我比較傾向後者。

很多漏洞可能已經存在五年、十年，甚至更久。只是過去沒有人發現，或者發現的人根本沒有公開。

所以，過去我們認為系統很安全，有時候可能只是因為問題還沒有被看見。

而現在，隨著 AI 技術快速進步，程式碼分析、漏洞挖掘與自動化測試的成本大幅降低，這些隱藏多年的問題，也開始一個接著一個浮現。

這些漏洞，真的有那麼高深嗎？

其實不一定。

資安專家 Alisa Esage 等人對於資安產業的漏洞炒作、技術敘事與實際安全問題，曾提出值得反思的觀點。

而從美國資安機構 CISA 長期推動的 Secure by Design（安全設計）原則，也可以看到類似的問題。

許多嚴重的安全風險，不見得來自什麼高深莫測的駭客技術，而是非常基礎的工程問題。

例如：

  • 把密碼或 API Key 直接寫死在程式碼裡。
  • 使用預設帳號密碼，卻沒有適當管理。
  • 防火牆或存取控制沒有正確設定。
  • 原本不應該暴露在公網上的服務，卻直接開放連線。
  • 本來應該採用更安全的認證或授權機制，最後卻選擇了比較簡單的實作方式。

甚至有些重大漏洞，背後只是一個沒有被妥善處理的錯誤回傳值，或是某個沒有人測試過的邊界條件。

這些問題其實都不是 AI 發明的。

它們早就存在於我們的軟體與系統之中。

而我自己也是工程師，所以對這件事有另一種感受。

很多時候，我不認為這些問題全部都能簡單歸咎於工程師偷懶。

因為真實的軟體開發現場，永遠存在交付時間、預算、人力與商業壓力。

有時候，我們明明知道某個架構應該設計得更完整，但因為時間不夠，只能先選擇比較簡單的方式。

有時候，我們知道某些邊界條件還沒有測試完整，但專案已經到了必須上線的時候。

也有時候，我們告訴自己：「這個問題下個版本再處理。」

結果一個版本接著一個版本，五年、十年就這樣過去了。

這些當年為了交付、成本與效率所做出的妥協，最後都可能變成整個軟體產業累積下來的技術債。

SSH 漏洞：一個特殊環境組合下的認證問題

就拿最近資安社群討論的 SSHole 漏洞來說。

這個案例特別有意思。

SSH 是很多工程師每天都在使用的遠端登入工具，但研究人員發現，在某些特定的 Linux 環境裡，竟然可能透過一段超長密碼，繞過原本的身分驗證機制。

問題涉及使用 musl libc 的系統、OpenSSH 的密碼驗證流程、PAM 設定，以及特定的帳號密碼狀態。

在符合漏洞條件的環境裡，輸入特定長度的超長密碼，就可能讓原本應該失敗的認證被誤判為成功。

這不是所有 SSH 伺服器都會發生的問題。

它必須是幾種比較特殊的環境與設定，剛好組合在一起，才有可能觸發。

更值得注意的是，這並不是什麼高深的密碼學攻擊。

問題出在不同軟體元件之間，對於錯誤回傳值的處理方式。

簡單來說，密碼驗證函式遇到異常長度的輸入時，可能回傳一個特殊的星號字元。

而系統裡某些帳號的密碼欄位，剛好也使用星號作為無法正常使用密碼認證的標記。

結果，兩個原本應該代表不同意義的特殊值，在某些驗證流程中被當成相同的密碼結果。

於是，一個原本不應該通過的認證，就有機會被錯誤地放行。

這個漏洞最值得思考的地方，不是它有多離譜。

而是，為什麼這樣的問題可以存在這麼多年，卻一直沒有被充分發現？

不是工程師不知道要測試，而是沒辦法測試所有組合

我認為，這其實反映了一個很現實的工程問題。

我們不是不知道應該要做測試。

而是在實際的軟體開發過程中，受到時間、人力與成本的限制，很難把所有可能的環境組合、邊界條件與例外情況，全部測試一遍。

尤其像 SSHole 這樣的漏洞，問題可能根本不在單一程式裡。

每一個元件獨立看起來，都可能有自己的設計理由。

但當不同版本的函式庫、認證機制、帳號狀態與特殊輸入組合在一起時，就可能產生完全沒有預期到的結果。

而我們在設計測試案例時，通常會優先確認正常流程，以及一些比較常見的異常情況。

但對於極端的輸入長度、少見的帳號狀態，或者跨元件的特殊組合，未必有足夠資源進行完整的探索。

這些不是我們完全不知道風險存在，而是過去要把這些組合全部找出來，成本可能非常高。

而這次真正讓我感興趣的，其實不是 SSH 漏洞本身，而是它被發現的方式。

一個研究人員加上 AI，開始挑戰過去的測試成本

這次研究的特點，是研究人員利用 AI Agent 與自動化測試工具，探索大量不同的環境及異常登入組合。

原本需要人類工程師花費大量時間規劃、執行與分析的測試，現在可以透過 AI 輔助，更有效率地進行。

AI 可以協助閱讀程式碼、分析不同元件之間的互動，提出可能的異常條件，再結合自動化工具進行驗證。

研究人員則負責設定方向、檢查結果，以及確認問題是否真的可以被重現。

這正好展現了 AI 的價值。

過去需要投入大量人力、時間與成本才能完成的探索，現在透過一個人搭配 AI 與自動化工具，就可能以相對低得多的成本完成。

這代表什麼？

代表過去那些不是因為工程師偷懶，而是因為資源有限、測試成本太高，導致一直沒有被充分檢查的問題，現在都有機會被重新挖掘出來。

我們以前沒有足夠資源去測試的邊界條件，AI 可以協助我們測試。

我們以前沒有時間仔細閱讀的歷史程式碼，AI 可以協助分析。

我們以前無法窮舉的複雜組合，現在可以透過 AI 與自動化工具，更大規模地探索。

當然，AI 並不能保證找到所有漏洞，也不代表所有測試都可以完全交給 AI。

但它正在明顯降低尋找問題的成本。

而這件事情，我認為對整個軟體產業的影響，可能比單一漏洞還要深遠。

從負面來看，AI 可能把過去所有的技術債一次抖出來

從比較負面的角度來看，這件事確實會讓資安產業面臨很大的壓力。

因為我們過去累積的技術債，可能比想像中還要多。

那些當年因為時間不夠而沒有測試的邊界條件。

那些因為成本考量而選擇的簡化設計。

那些因為擔心影響既有系統，而一直不敢修改的老舊程式碼。

甚至是那些從來沒有人認真檢查過的函式庫與系統元件。

現在，都可能透過 AI 被重新挖掘出來。

所以未來一段時間，我們可能會看到更多 CVE、更多高風險漏洞，以及更多資安事件。

但這不一定代表新寫出來的軟體變得更差。

它也可能代表，我們終於開始有能力，大規模檢查過去那些沒有被充分驗證的系統。

換句話說，AI 可能正在加速清算整個軟體產業，過去十年甚至更長時間累積下來的技術債。

但從正面來看，我反而認為這是一件好事

因為我一直在想另一個問題。

過去沒有被公開的漏洞，真的代表沒有人發現嗎？

其實不一定。

有些漏洞可能真的從來沒有人發現。

但也有些漏洞，可能早就被某些有經驗的駭客掌握，只是他們選擇不公開。

對攻擊者來說，一個還沒有被公開、也沒有被修補的漏洞，反而可能是非常有價值的資產。

因為只要其他人不知道這個問題存在，他就可能持續利用它。

慢慢滲透、慢慢取得資料，甚至長期維持對某些系統的存取能力。

而防守方呢？

防守方可能完全不知道自己有這個問題。

甚至還以為自己的系統相當安全。

當然，這不代表這次 SSH 漏洞已經被證實遭到秘密利用，也不能直接認定這些問題是駭客刻意留下的後門。

但這種情況在資安攻防中，確實是一個必須考慮的可能性。

而這也是為什麼，我反而認為 AI 讓更多漏洞浮現，長期來看是一件好事。

因為以前，尋找這些問題需要很高的技術門檻，以及大量的時間與資源。

有能力發現漏洞的人，可能只有少數資安專家或特定攻擊團隊。

現在不一樣了。

當一個研究人員搭配 AI，就能更有效率地分析程式碼、探索異常組合並驗證漏洞時，代表白帽研究人員、開源社群與企業內部的資安團隊，也有機會以更低的成本進行同樣的工作。

這不代表防守方一定會比攻擊者更快。

但至少，我們有機會縮小過去那種巨大的資訊不對稱。

原本可能只有少數駭客知道的問題，現在有更多機會被公開發現、驗證並修補。

我寧願這些地雷現在被挖出來

想像一下，如果一個漏洞已經存在十年。

過去十年，系統可能一直在正常運作。

企業也沒有發現任何異常。

所以大家認為它很安全。

但如果這個漏洞其實早就被某些攻擊者掌握，只是他們選擇不公開呢？

那麼我們所謂的安全，可能只是因為我們不知道自己已經暴露在風險之中。

反過來說，如果今天透過 AI，我們終於把這個漏洞找出來。

短期內，確實可能造成一些混亂。

工程師要緊急修補。

企業要重新檢查系統。

資安團隊要處理新的告警與風險。

但至少，我們知道問題在哪裡，也終於有機會把它修好。

我寧願這些埋藏多年的地雷，現在就被 AI 一顆一顆挖出來，也不希望它們繼續隱藏在系統裡，成為少數攻擊者可以長期秘密利用的工具。

當然，漏洞被發現後，還需要負責任的揭露流程，以及足夠快速的修補與部署，才能真正降低風險。

但從長期來看，我認為這是軟體產業走向更成熟安全架構的一個機會。

AI 正在改變的，不只是找漏洞的速度

過去，我們在做軟體工程時，很多安全措施其實都是成本與風險之間的取捨。

因為測試資源有限，所以只能挑選重要的情境。

因為程式碼太多，所以不可能每一行都由資深工程師仔細審查。

因為系統太複雜，所以很難檢查所有元件之間的互動。

但 AI 正在逐步改變這些限制。

它讓我們有機會以更低的成本，進行更大範圍的程式碼分析、異常測試與安全驗證。

當這些能力逐漸普及，我認為企業也應該重新思考自己的安全策略。

不只是等 CVE 出來之後，再進行修補。

而是開始把 AI 輔助程式碼審查、自動化安全測試、依賴套件分析，以及不同環境的組合驗證，真正整合進日常開發流程。

更重要的是，對於密碼認證、存取控制與服務暴露這些基礎架構問題，應該盡可能從設計上減少風險，而不只是期待工程師永遠不會犯錯。

因為真正好的安全架構，不應該完全依賴每一個工程師都足夠細心。

而是即使有人犯錯，即使某個元件出現問題，整個系統仍然有足夠的防護能力。

結語：不是 AI 讓軟體變得千瘡百孔

所以，回到一開始的問題。

為什麼最近好像有這麼多資安漏洞？

我的看法是，這不一定代表軟體突然變得更不安全。

而是 AI 正在讓我們有能力，以過去難以想像的效率，重新檢查那些已經存在多年的系統。

當然，攻擊者也能利用同樣的技術，這確實會增加短期的資安風險。

但如果白帽研究人員、企業與開源社群能積極使用 AI，提前找出並修補這些問題，我認為長期而言，整個軟體產業反而會變得更安全。

過去那些因為時間、成本、交付壓力所留下的必要之惡，終究需要有人來處理。

而 AI 正在讓這件事情變得更容易。

不是 AI 讓我們的軟體突然變得千瘡百孔，而是 AI 讓我們終於有能力，看見那些原本就存在的問題。

這一波 AI 帶來的資安變革，某種程度上，就是整個軟體產業開始清算過去十年累積的工程技術債。

而我認為，這是一件值得正面看待的事情。