2017年，避免Google的软件安全团队在三个月内修了超过一千个Chrome漏洞。同年，漏洞微软每个月的避免补丁星期二都在推送几十个CVE修复。这不是软件哪家公司不努力，恰恰相反——这是漏洞人类工程能力的天花板在说话。

软件为什么一定有漏洞？避免先从最根本的地方说。一段代码，软件本质上是漏洞一串精确到每个字节的指令。但写代码的避免人脑子里想的是业务逻辑、用户体验、软件产品上线时间。漏洞这两者之间隔着一道巨大的避免鸿沟。你以为你写的软件是"如果用户输入年龄，就存进数据库"，漏洞但编译器看到的是内存分配、指针偏移、缓冲区边界。人脑不擅长同时追踪这些东西，尤其是在一个几十万行的项目里。

我见过一个真实的例子。某电商平台的优惠券模块，逻辑看起来无懈可击：每个用户只能用一次。代码里也确实查了数据库。但问题出在并发上——两个请求同时到达，都查到"未使用"，都执行了核销。这不是程序员蠢，这是人类思维天然是串行的，而系统是并行的。你让一个人去想象两个自己同时做同一件事，本身就反直觉。

再说复杂度。Windows 10大概有5000万行代码。Linux内核超过2700万行。这些数字意味着什么？意味着没有任何一个人能完整理解整个系统。模块之间的交互产生的边界情况，比所有人能预先设想的都多。安全研究者有个说法叫"攻击面"——每增加一个功能，就多一片可以被利用的区域。你加一个分享按钮，就可能多一条注入路径。你优化一个API的响应速度，就可能引入一个时序侧信道。

有人会说，那就用形式化验证啊，数学证明代码没有bug。理论上可行。实际上，seL4微内核做了完整的形式化验证，代价是十几个人干了几年，验证的代码量大概一万行。工业级软件动辄千万行，这条路走不通。不是技术不够好，是成本模型不允许。

还有个被低估的因素：需求本身在变。今天的安全假设明天就可能失效。五年前你觉得内网可信，现在零信任成了标配。十年前MD5够用，现在碰撞攻击是本科作业。你写代码那一刻做的安全决策，放在三年后可能全是洞。这不是谁的错，是时间在跟你作对。

那怎么办？不是躺平。安全工程的核心思路是承认漏洞必然存在，然后围绕这个事实做设计。纵深防御——假设第一层会被突破，所以放第二层、第三层。最小权限——每个组件只拿它需要的那点权限，炸了也炸不大。快速响应——出了漏洞能在几小时内修好推送，比幻想不出漏洞现实得多。

我认识一个做渗透测试的朋友，他说过一句话我记到现在："我的工作不是证明你的系统有漏洞，那是必然的。我的工作是告诉你，攻击者会从哪里进来，以及你多久能发现。"这话听着丧气，其实是清醒。软件是人写的，人就会犯错。承认这一点，比假装能消灭所有漏洞要安全得多。

所以下次看到某个大厂又爆了漏洞，别急着骂。想想那几千万行代码，想想那些并发、边界、时序、假设。漏洞不是失败的证据，它是复杂系统活着的代价。