漏洞产生的原因

缓冲区溢出能霸占漏洞榜几十年，漏洞原因简单得让人无语：程序员写代码时少算了一个字节。产生1988年Morris蠕虫利用fingerd的漏洞gets()函数溢出，放今天看那代码简直像故意留的产生后门——但当时写它的人真没觉得有问题。这就是漏洞漏洞最讽刺的地方：它往往不是“错误”，而是产生“合理但不够合理”的产物。

需求催生复杂度，漏洞复杂度埋下裂缝。产生一个登录功能，漏洞最初只是产生比对用户名密码。后来要支持手机号、漏洞邮箱、产生第三方OAuth、漏洞记住我、产生多设备同步。漏洞每加一层逻辑，就多一组状态组合。开发周期没变，测试资源没变，但代码路径翻了三倍。漏掉的那条分支，就是漏洞的温床。

时间压力是更直接的催化剂。2014年Heartbleed爆发时，OpenSSL的代码审计报告显示，那段有问题的逻辑分支几乎没人 review 过。为什么？因为整个项目靠志愿者维护，而企业用户白嫖了十几年。一个被全球半数HTTPS流量依赖的库，长期只有两三个全职开发者。漏洞不是“不小心”写出来的，是“没空仔细看”攒出来的。

语言和框架也在推波助澜。C语言把内存管理的责任全甩给程序员，一个strcpy就能让整个系统沦陷。PHP早期的register_globals默认开启，把用户输入直接变成全局变量，等于给攻击者递钥匙。这些设计在当时都有“提高开发效率”的合理理由，代价是安全边界模糊得像雾天开车。

人的认知偏差同样致命。开发者习惯用自己的思维模拟攻击者，但攻击者根本不按套路出牌。你防了SQL注入，他搞SSRF；你加了WAF，他绕编码。更常见的是“这不可能发生”心态——某电商后台的密码重置接口，开发觉得“只有管理员能访问”，结果路由没做权限校验，任何人抓包改个ID就能重置别人密码。漏洞报告提交后，开发的第一反应是“你怎么找到这个接口的”，而不是“我为什么没加校验”。

第三方依赖是另一个黑洞。你写了两百行代码，引入的npm包有三百个传递依赖。某个犄角旮旯的包两年前就停止维护了，里面有个原型链污染。Log4j2的JNDI注入能炸穿半个互联网，就是因为没人想到日志库会去加载远程类。供应链攻击越来越流行，不是攻击者变聪明了，是软件组装的复杂度已经超出任何人能完整理解的范围。

还有一类漏洞纯粹来自“抄作业抄错”。某政务系统直接复制了开源项目的示例代码，连示例里的测试后门都一起上线了。开发觉得“官方demo肯定安全”，但demo的注释里写着“生产环境请删除此路由”。

漏洞不会消失。系统越复杂，抽象层越多，人和代码之间的信息损耗就越大。每加一个功能，每赶一个deadline，每引入一个依赖，都在给未来的CVE添砖加瓦。能做的只有承认这个现实：安全不是“修完漏洞就完事”，而是持续跟复杂度赛跑。跑不赢的时候，至少别把钥匙插在门上。