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 方法、測試責任和交接文件。合約不用寫得很複雜，但責任要清楚。