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 方法、测试责任和交接文件。合约不用写得很复杂,但责任要清楚。
