```html

某省级政务云平台去年底的国产一次安全巡检，暴露出一个老问题：核心业务区有37台服务器运行着某国产Linux发行版，化操系统内核版本停留在两年前，作系而官方早已发布了修复提权漏洞的统漏补丁。运维团队不是洞修没收到通知，是国产流程卡住了——补丁要经过厂商适配、集成商测试、化操甲方审批，作系一圈走完，统漏三个月过去了。洞修

这不是国产孤例。我接触过一家做国产化替代集成的化操公司，他们的作系技术负责人说得直白：“客户买了系统，但没买服务。统漏漏洞修复？洞修等下一个大版本升级吧。”这话听着刺耳，却点中了国产操作系统生态里的真实痛点——修漏洞这件事，在商业逻辑里排不上优先级。

为什么排不上？先看钱。国产操作系统的营收大头在License授权和定制开发，后期安全运维的合同金额往往不到总项目的5%。厂商的研发资源自然向新功能、新适配倾斜。一个给系统打补丁的工程师，KPI里可能都没有“漏洞修复及时率”这一项。反观红帽、微软，安全响应是订阅服务的核心卖点，不修就没人续费。国产系统还没走到那一步。

再看技术债。不少国产系统基于较老的Linux内核或开源版本二次开发，上游社区修了漏洞，往下游移植不是复制粘贴那么简单。某麒麟版本的操作系统，因为改动了内存管理模块，一个上游的脏页回收漏洞补丁移植过去，测试发现跟自家文件系统冲突，又得回炉。这一来一回，两周没了。厂商的补丁发布节奏，往往跟上游社区脱节，有时落后一两个月，有时干脆跳过某些中间版本。

用户的处境更尴尬。一家银行的数据中心负责人跟我抱怨，他们用的国产系统，厂商给的补丁包是“累积更新”，不能单独打某个漏洞的修复。要修一个高危漏洞，得把整个系统升级到最新SP版本，而那个SP版本又引入了新的兼容性问题。IT部门只能权衡：是冒着业务中断的风险升级，还是先扛着漏洞？多数时候选后者。扛着扛着，就成了习惯。

监管也在推，但推得有点偏。等保2.0、关基保护条例都要求“及时修复已知漏洞”，可“及时”的定义模糊。检查时看的是有没有漏洞扫描报告、有没有修复计划，至于计划执行了没有、执行得多快，缺少硬性约束。厂商交一份“已制定修复方案”的文档就能过关，实际打补丁的时间线没人深究。

更麻烦的是责任边界。系统是厂商的，业务是集成商部署的，运维是用户自己做的。漏洞爆出来，厂商说“补丁已发布，是用户没打”；用户说“集成商没通知我”；集成商说“厂商没给适配文档”。一圈扯皮下来，漏洞还在那儿。我见过最离谱的案例，一个中危漏洞从披露到实际修复，用了11个月——因为中间跨了年度预算周期。

当然，也有做得好的。统信UOS在某些关键行业客户那里，尝试了“安全响应SLA”，承诺高危漏洞72小时内提供补丁。但代价是客户得额外买安全订阅服务，一年费用不低。这模式能不能铺开，取决于有多少用户愿意为“及时”买单。目前看，愿意掏钱的不多。

说到底，漏洞修复不及时不是纯技术问题，是商业模型、生态成熟度和责任机制搅在一起的结。厂商没动力，用户没压力，中间环节能拖就拖。要解开这个结，光靠发文件、搞检查不够，得让“不及时”真正疼起来——要么合同里写死赔偿条款，要么监管把修复时效纳入硬性考核。否则，那些带着已知漏洞跑着的国产系统，还会继续跑下去。

```