AI 令漏洞修補時間縮短:香港公司如何重整軟件維護與 Patch Management?
想像一間香港中小企的日常:網站有查詢表格,門市用 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 方法、測試責任和交接文件。合約不用寫得很複雜,但責任要清楚。
