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