某省级政务平台被扫出47个高危漏洞那天，网络运维团队负责人老周在会议室摔了茶杯。安全不是漏洞气安全公司报告写得烂，是整改整改气自己——三个月前就收到过同源漏洞的预警，当时只改了对外端口，报告内网那台存着200万条公民信息的措施数据库连补丁都没打。攻击者从测试环境一个未授权的网络API接口摸进来，横移到核心库，安全整个过程只用了11分钟。漏洞这份整改报告后来我看了，整改整改第一页写着"已完成全部漏洞修复"，报告附件里却夹着三台服务器的措施延期整改申请。

漏洞整改最怕的网络就是这种"表面清零"。扫描器报的安全洞补上了，业务逻辑里的漏洞坑还在。去年某电商平台修了个SQL注入，参数化查询改得挺规范，但订单查询接口没做越权校验，换个用户ID照样能看别人的收货地址。安全团队和开发团队各说各话：一个盯着CVSS评分，一个觉得"能跑就行"。整改措施要是只写"升级组件版本""增加WAF规则"，跟贴创可贴治内出血没区别。

先说漏洞定级这事。很多单位直接照搬扫描工具的"高危""中危"标签，这偷懒偷得离谱。一个只在内部测试环境、需要物理接触才能触发的漏洞，和公网可直连的远程代码执行，能是一个优先级？我见过最离谱的定级表，把"HTTP响应头缺失"标成高危，把"越权访问全部用户数据"标成中危——因为扫描器给前者打了7.5分。整改措施第一条得写清楚：由安全负责人牵头，结合资产重要性、暴露面、利用难度重新定级。别让工具替人做判断。

修复方案要落到具体文件和人。别写"加强输入验证"，写"在/api/v1/order/query接口的orderId参数处增加白名单校验，由后端组张工在3月15日前提交代码合并请求"。某银行吃过亏，整改报告写"已修复反序列化漏洞"，结果只改了Java端的，Python写的报表服务里同一个库还在用。后来他们学乖了，每个漏洞后面跟三列：涉及文件路径、责任人、验证方式。验证方式必须包含"攻击模拟"——不是点一下页面没报错就算过，得用Burp Suite重放攻击载荷确认返回包正常。

延期整改得有硬约束。那三台服务器为什么延？老周后来跟我讲，其中一台跑着十年前的老系统，厂商早就不维护了，打补丁直接蓝屏。这种就得走临时缓解措施：网络层封禁该服务器所有外联，只允许特定管理终端访问，同时启动系统替换立项。临时措施不是"不管了"，是给根治争取时间。报告里要写明临时措施的有效期和替代方案时间表，安全团队每周复查一次封禁策略有没有被业务部门偷偷放开。

最后说验证环节。很多单位修完漏洞自己测一遍就结案，这跟学生自己批改作业一样不靠谱。引入第三方复测，或者至少让没参与修复的人来打。某运营商的做法值得抄：修复人员提交报告后，安全团队随机抽30%的漏洞做黑盒复测，发现一个未修复或修复不彻底的，整个项目组当月绩效扣10%。这招下去，修复率从72%跳到98%。不是人变勤快了，是糊弄的成本变高了。

整改报告别写成表功材料。把没修完的、修得勉强的、临时措施顶着用的，都列清楚。老周后来那份报告我帮着改过，第一页就写"47个漏洞中，完全修复39个，临时缓解6个，延期2个（附延期审批单）"。上级单位反而批得快——知道底细才敢签字。遮遮掩掩写"全部完成"，下次出事第一个被追责的就是签字的人。