AI 加快漏洞發現與攻擊：企業如何縮短風險應對時間

AI 加快漏洞發現與攻擊：企業如何縮短風險應對時間

想像一間香港中小企的日常：網站有查詢表格，門市用 booking form 接預約，銷售團隊用 CRM 跟進客戶，網店靠 payment plugin 收款，辦公室電腦由 antivirus 或 security console 管理。這些系統平日看似「正常運作」，但其實都像公司車輛一樣，需要定期保養。

以前很多公司會等到供應商通知，或者系統出問題才更新。現在這個做法越來越危險。AI 工具令安全研究員可以更快找出漏洞，攻擊者也可以更快測試哪些公司未修補。換句話說，公司可用來慢慢處理更新的時間正在縮短。

2026 年 5 月的幾件事正好說明這個趨勢。IBM 在 2026 年 5 月 21 日談到 AI-powered security 與 Project Glasswing，重點是用 AI 加快漏洞發現和回應。同一週，Trend Micro Apex One on-premise 漏洞 CVE-2026-34926 被列入已知遭利用漏洞資訊；GovCERT.HK 亦在 2026 年 5 月 22 日發出 high threat alert，指向相關 HKCERT bulletin。CISA 同期把 Langflow CVE-2025-34291 和 Trend Micro Apex One CVE-2026-34926 加入 Known Exploited Vulnerabilities catalog，修補限期為 2026 年 6 月 4 日。

這些名稱聽起來很技術，但對管理層的意思很簡單：如果公司依賴 website、mobile app、CRM、booking system、eShop、AI tool 或內部系統，就要有一套清楚的更新和維護方法，而不是靠記憶或臨時補救。

先知道公司有甚麼系統

Patch management 即是「知道哪些系統要更新、誰負責更新、更新後怎樣檢查」。第一步不是買新工具，而是列出公司正在使用的系統。

一間 40 人的貿易公司，可以先列出幾個最常用系統：公司網站、eShop、CRM、email、file sharing、會計系統、security console、VPN、雲端 server、內部報表工具。每個系統旁邊寫上三件事：誰負責、供應商是誰、壞了會影響哪個部門。

實務例子：如果 eShop payment plugin 出問題，受影響的是收款和訂單；如果 CRM 出問題，受影響的是銷售跟進；如果 file sharing 出問題，受影響的是合約和報價文件。這樣當有漏洞通知時，IT manager 不需要到處問「我們有沒有用這個」，而是可以直接查清單。

這個清單也有助管理層分清優先次序。客戶資料、付款、預約、email、身份登入和安全管理工具，通常比普通宣傳頁更重要。不是所有更新都一樣急，但公司要知道哪些系統一出事就會影響收入、服務或客戶信任。

漏洞分級要用業務語言

安全新聞常見 CVE、CVSS、KEV 等字眼。可以簡單理解：CVE 是漏洞編號；CVSS 是嚴重程度分數；KEV 是已知被攻擊者利用的漏洞清單。這些資訊有用，但 SME 不應只看分數。

更實際的問題是：這個系統是否對外開放？是否有客戶資料？是否可以改訂單、發 email、收款或管理多部電腦？如果答案是 yes，就算技術分數不是最高，也應該優先處理。

實務例子：物流公司有一個內部 route planning server，只有辦公室網絡可用；同時有一個客戶查件 API，公開在 internet，又連接會員資料。即使兩者都有更新通知，客戶查件 API 通常要先檢查，因為它面向外部客戶，而且影響資料和服務。

更新前後要檢查甚麼

很多公司不敢更新，不是因為不重視安全，而是怕更新後系統壞掉。所以更新流程一定要簡單、可重複，而且有檢查清單。

每次重要更新前，ticket 至少要寫清楚：受影響系統、要更新甚麼、誰批准、甚麼時間做、更新前要備份甚麼、更新後要測試甚麼。如果更新後出問題，rollback 即是「回復到更新前狀態」的方法，也要先準備好。

實務例子：教育中心要更新 booking system 的其中一個 library。不要只寫「update package」。清單應該寫明：學生能否報名、付款 callback 是否正常、老師排班是否正常、管理後台是否看得到新預約、confirmation email 是否寄出。這些檢查不複雜，但能避免更新後才發現 checkout 或預約流程壞了。

診所亦可以用同一方法。更新 server package 後，不需要檢查每一個畫面，但至少要確認病人預約、前台改期、醫生查看日程、SMS 提醒、invoice 產生和資料備份正常。這些就是最基本的 smoke test，即快速確認核心流程沒有壞。

外判系統也要有答案

很多香港 SME 的 website、app、CRM、ERP 或 IoT 系統由不同供應商維護。系統不是內部開發，不代表公司可以不用管理。出現漏洞或安全通知時，企業仍然要知道供應商會怎樣處理。

最少要問四個問題：我們是否受影響？甚麼時候修補？修補後怎樣測試？如果出問題怎樣回復？

實務例子：零售品牌把 eShop 外判給供應商。當 payment plugin 或 website framework 有漏洞時，品牌方不應只接受「已通知技術部」這種回覆。較好的回覆應該包括：目前版本是否受影響、預計更新時間、是否需要短暫停機、會測試哪些付款和訂單流程、完成後會提供甚麼記錄。

這些要求應該逐步寫入維護合約，例如 critical vulnerability response time、定期更新範圍、backup 方法、測試責任和交接文件。合約不用寫得很複雜，但責任要清楚。

AI 工具也要當成正式系統

不少公司現在會試用 AI workflow、AI agent、RAG knowledge base 或自動化工具。初期可能只是 prototype，但只要它連接 API key、客戶文件、CRM、email 或 database，就已經不是普通 demo。

Langflow CVE-2025-34291 被加入 CISA KEV，是一個很好的提醒：AI workflow tool 也可能有漏洞，也需要更新、權限管理和停用方法。CORS、cookie、secret manager 這些詞可以先不用深入理解；管理層只要問：這個 AI 工具是否對外開放？誰可以登入？API key 放在哪裏？如果平台有漏洞，我們能否暫停 workflow？

實務例子：公司用 AI agent 整理客戶查詢，並連接 Gmail、CRM 和內部知識庫。即使只是內部試驗，也應該放在受控網絡，用 SSO 或 VPN 登入，API key 不應貼在共享文件或 workflow 畫面。若平台要更新，IT 要知道哪些流程會受影響，以及如何暫停自動回覆。

管理層每月看三個數字

管理層不需要記住每個漏洞編號，但應該每月看三個簡單指標。

第一，重要系統多久沒有更新。第二，高風險通知由收到到完成處理用了多久。第三，更新後有沒有完成測試和記錄。

實務例子：每月 management meeting 加一頁 security maintenance summary：本月收到幾個高風險通知、哪些系統受影響、哪些已完成、哪些等供應商、下月需要多少維護時間或預算。這比出事後才追問「為甚麼沒有更新」實際得多。

一個 4 週起步計劃

第一週，列出公司最重要的系統，包括 website、eShop、CRM、email、file sharing、booking system、security console、cloud server 和 AI tool。每個系統寫上負責人和供應商。

第二週，為這些系統訂閱供應商安全通知，或指定一個 email 收集 update alert。重點不是收很多消息，而是不要錯過真正相關的通知。

第三週，為三至五個核心流程寫簡單測試清單，例如下單、付款、預約、登入、發 email、查看報表、備份。這些清單要短，讓同事真的會用。

第四週，建立固定 ticket template：系統名稱、問題來源、影響範圍、處理期限、測試清單、完成記錄。從此之後，每次重要更新都按同一方法處理。

結語：維護能力就是營運能力

AI 令漏洞發現和攻擊節奏加快，但企業不需要被技術名詞嚇怕。真正要做的，是把軟件維護變成日常營運流程：知道有甚麼系統、誰負責、甚麼最重要、更新後怎樣檢查、供應商要交代甚麼。

當公司越依賴 booking system、CRM、mobile app、cloud server、AI workflow 和 custom software，維護能力就越直接影響收入、客戶信任和服務連續性。

下一步可以先整理現有系統清單，標記每個系統的負責人、更新頻率、測試方法和供應商維護責任，讓 patch management 變成可追蹤的日常工作。