去年冬天，漏洞我帮一家小公司处理了一次数据泄露。责任他们的漏洞用户数据库被拖走，三万条记录挂在境外论坛上叫卖。责任老板急得连夜打电话，漏洞问能不能“把漏洞补上就没事了”。责任我告诉他，漏洞补漏洞是责任技术问题，但谁为这次泄露负责，漏洞是责任另一回事。他沉默了几秒，漏洞说：“那签个责任书行不行？责任”

责任书这东西，在安全圈里很微妙。漏洞它不像劳动合同那样有法律强制力，责任更像一张心理契约。漏洞出了事，大家翻出这张纸，指认谁该背锅。可现实是，漏洞从来不是单点产生的。写代码的人、审代码的人、部署的人、甚至拍板“先上线再说”的人，都在这条链上。把责任压给一个人，不公平，也不管用。

我见过一份真实的漏洞责任书，某金融公司内部用的。开头写着“本次漏洞由开发人员张三未做输入校验导致”，下面列了整改措施和处罚。张三签了字，扣了季度奖金。三个月后，同一个系统又出了SQL注入，这次是李四。责任书换了个名字，流程照旧。没人问：为什么代码审查没拦住？为什么测试环境没覆盖？为什么安全培训只走了个过场？

问题出在责任书的写法上。大多数责任书只写“谁犯了错”，不写“系统哪里失灵”。这就像足球比赛里，前锋射丢单刀，你只罚他跑圈，却不看中场有没有传球、教练战术是否对头。漏洞是系统缺陷的显影，不是某个人的道德污点。把漏洞责任书写成检讨书，等于放弃了真正的修复机会。

另一类责任书更常见：外包开发时，甲方要求乙方签“安全责任承诺书”，大意是“出了漏洞你全赔”。乙方为了拿项目，闭眼签。真出了事，乙方赔不起，甲方照样损失。这种责任书是纸糊的盾牌，挡不住任何攻击，只用来在事后推诿。我见过一个案例，甲方拿着责任书去法院告乙方，法官问：“你们自己的安全验收报告呢？”甲方拿不出来。责任书成了废纸。

那漏洞责任书到底该怎么写？我的观察是，它不该是追责工具，而该是协作记录。具体点说，写清楚三件事：这个漏洞是在哪个环节被发现的？发现时已经存在了多久？谁在什么条件下能阻止它？比如一个越权漏洞，开发没做权限校验，但测试用例里有没有覆盖？上线前的渗透测试有没有扫到？如果都没做到，那责任书就该写“测试用例缺失”和“渗透测试范围不足”，而不是只写“开发粗心”。

我认识一个安全负责人，他设计的责任书很有意思。每次漏洞复盘，他不让任何人签字，而是让相关角色各写一段“如果重来一次，我会在哪个节点做不同的事”。开发写“我会加校验”，测试写“我会补用例”，产品写“我会把安全需求写进PRD”。这些段落拼在一起，就是一份活的责任书。没人被罚，但所有人都知道下次该在哪用力。他们团队后来的漏洞重复率降了七成。

当然，这不是说个人责任可以忽略。故意绕过安全流程、明知有漏洞还上线，该罚就罚。但大多数漏洞是能力问题、流程问题、资源问题，不是态度问题。一份只盯着态度的责任书，只会让员工学会甩锅和隐瞒。真正有用的责任书，是让每个角色看到自己在系统里的位置，以及那个位置上的盲区。

回到开头那个老板。我最后没让他签责任书，而是拉了个清单：数据库权限谁管的、日志谁在看、备份谁在测。他看完说：“原来这么多地方没人负责。”对，漏洞责任书的第一页，不该写“谁错了”，而该写“哪里没人管”。管好了，责任书自然就薄了。