去年冬天，漏洞原声我在一个安全会议上碰到老张。漏洞原声他端着咖啡，漏洞原声眼睛熬得通红，漏洞原声说刚从客户现场回来。漏洞原声那是漏洞原声一家做智能门锁的厂商，固件里藏了个后门——不是漏洞原声故意的，是漏洞原声开发时留的调试接口忘了删。攻击者能直接解锁任何一把联网的漏洞原声锁。老张说这话时声音压得很低，漏洞原声像怕被旁边的漏洞原声厂商代表听见。

这就是漏洞原声漏洞的原声。不是漏洞原声教科书里那种“由于输入验证不足导致缓冲区溢出”的冰冷描述，而是漏洞原声凌晨三点被电话叫醒、对着十六进制转储发呆、漏洞原声最后在某个不起眼的函数里找到那行if (debug_mode) return true;时的骂娘声。

我干这行八年，见过太多漏洞的“第一现场”。它们很少像电影里那样被天才黑客用一行命令攻破。真实情况是：某个外包程序员赶工期，把密码硬编码在APK里；某次代码合并冲突，有人手滑把认证中间件注释掉了；某台测试服务器忘了关，上面跑着带完整数据库权限的脚本。漏洞不是被“发现”的，是被“撞见”的。

去年有个案例让我印象很深。一家做跨境电商的小公司，数据库被拖了。老板一开始不信，说我们用了云服务商的安全组，防火墙规则写得严严实实。我去看的时候，发现他们有个内部报表系统，用的是同一个数据库的只读账号。那个账号的密码是report123。更离谱的是，这个系统部署在公网，登录页面连验证码都没有。攻击者根本没碰防火墙，直接从报表系统里把用户表导走了。

你说这算技术漏洞还是管理漏洞？我觉得算“人漏洞”。安全圈有句话：你可以把系统设计得滴水不漏，但总有人会把钥匙插在锁孔里。我见过运维把生产环境SSH密钥传到GitHub个人仓库，见过产品经理用公司邮箱注册第三方图床然后上传内部架构图，见过实习生把包含客户数据的Excel发到微信文件传输助手。这些都不是CVE编号能覆盖的东西。

但“人漏洞”这个词本身就有问题。它把责任推给个体，掩盖了系统性的懒惰。为什么开发环境能直连生产数据库？为什么密钥管理靠人肉记忆？为什么一个只读账号能导出全量用户数据？这些问题的答案通常是：“一直这么干的，没出过事。”直到出事。

老张后来在那家智能门锁厂商待了三天。他删了后门，加了签名校验，写了份报告。厂商老板问他：“这算严重吗？”老张说：“你现在去楼下五金店买把锁，都比你们家联网的结实。”老板笑了笑，说下周发个固件更新就行。老张没再说话。他知道，那个调试接口是两年前一个离职员工留的，代码注释里写着“临时用，上线前删”。没人删。因为没人记得。

漏洞的原声，说到底就是遗忘的声音。是某次提交时没写清楚的commit message，是某次评审时跳过的安全 checklist，是某次“先这样吧回头再改”的妥协。它们安安静静地躺在代码仓库里，直到某天被一个脚本小子用公开的exp打穿。然后所有人开始问：怎么会这样？

答案早就写在那些没人看的日志里了。

(责任编辑：百科)