网站漏洞整改跟踪表

网站漏洞整改跟踪表一、漏洞分类与定级标准定级是安全团队与业务团队博弈的焦点，统一的量化标准是杜绝“讨价还价”和资源错配的前提。本标准依据《信息安全技术网络安全漏洞分级分类指南》（GB/T30279-2020），结合网站实际业务场景制定，所有录入跟踪表的漏洞必须先行定级。1.1高危漏洞判定标准为：攻击者可远程无需用户交互直接获取系统控制权、核心敏感数据或导致核心业务瘫痪。

具体场景包括但不限于：•SQL注入（可拖取或篡改数据库核心业务表）•反序列化命令执行（RCE）•未授权访问导致的全量用户个人隐私数据（PII）泄露•任意文件上传导致GetShell•核心业务接口拒绝服务（如通过单接口并发打满数据库连接池）1.2中危漏洞判定标准为：攻击者需特定条件或间接交互方可利用，或造成局部数据泄露、普通业务受影响。

具体场景包括但不限于：•存储型跨站脚本攻击（XSS）（需诱导用户点击，可窃取会话凭证）•水平越权（可查看或操作同级其他用户的非敏感数据）•重要敏感信息泄露（如源代码备份、数据库结构暴露于前端）•业务逻辑漏洞（如无限试发短信验证码导致短信通道被封锁）1.3低危漏洞判定标准为：利用难度极大或仅能获取极少非敏感信息，对核心业务无直接影响。

具体场景包括但不限于：•反射型XSS（需复杂构造URL且依赖特定浏览器内核）•目录遍历（仅可获取系统配置文件等非敏感路径）•安全配置不当（如未设置HttpOnlyFlag、Banner信息泄露）二、整改时效与响应要求时效要求不是建议而是红线，超时未修复意味着系统将持续暴露在攻击面下，必须以SLA强制驱动修复动作。不同等级漏洞的响应及整改时效如下表，安全团队将按时效节点自动触发督办机制。漏洞等级响应时效修复时效复测时效临时缓解措施要求高危15分钟内确认24小时内修复修复后2小时内发现即刻执行WAF阻断或下线接口中危2小时内确认3个自然日内修复修复后1个工作日内评估是否需限流或增加鉴权低危1个工作日内确认15个自然日内修复随下一版本迭代复测无强制要求，按迭代计划处理对于依赖第三方组件且官方未发布补丁的漏洞，责任方必须在修复时效到期前1个工作日提交延期申请，并附带临时缓解方案（如网络隔离限制访问源）。三、漏洞整改全流程管理漏洞管理不是单向提交工单，而是一个包含验证、复测、驳回、复盘的闭环，任何缺乏复测的修复都应视为未修复。全流程遵循PDCA机制运转。3.1漏洞发现与录入(Plan)安全团队通过自动化扫描器、人工渗透测试或外部威胁情报发现漏洞后，必须于1小时内复现验证。确认后录入《网站漏洞整改跟踪表》，同时通过内部工单系统派发至系统第一责任人。漏洞描述必须包含完整的“风险演化叙事”，而非简单罗列漏洞名词。例如：不可仅写“存在SQL注入”，必须写明“/api/user/info接口的id参数未过滤单引号->攻击者构造UNION查询->绕过应用层鉴权->拖取user_account表全量数据->导致平台核心用户资产泄露”。3.2整改执行与自测(Do)开发人员在接单后，需依据安全团队提供的整改建议进行代码修复。整改动作必须讲清动作机理，严禁使用“黑名单过滤”等表面修补手段。典型漏洞修复规范要求：1.SQL注入漏洞：必须使用预编译语句参数化查询，绑定变量；严禁通过正则黑名单过滤特殊字符（黑名单易被大小写、编码绕过，无法根除注入风险）。2.越权访问漏洞：优先采用基于会话身份的从属校验，在后端服务层校验当前用户与请求资源的所属关系；严禁仅在前端隐藏菜单或按钮（攻击者可直接构造接口请求绕过前端限制，直接越权访问）。3.XSS漏洞：必须根据输出上下文进行HTML实体编码或JavaScript编码；严禁使用replace('<script>','')等硬编码替换（无法处理<imgonerror>等变种，极易被绕过）。开发人员修复后，必须在测试环境完成自测，并在工单中附带修复前后的对比截图及测试用例，方可流转至安全团队复测。3.3复测与闭环(Check)安全团队接到复测请求后，按复测时效要求进行验证。•若复测通过：在跟踪表中记录“已闭环”，系统恢复线上正常状态。•若复测失败：直接驳回工单，在跟踪表中记录“修复未通过（原因：如仅修复主键未修复外键参数）”，并重新计算修复时效（原SLA计时器不停止，计入延期考核）。•若二次复测仍失败：自动升级至技术总监级别进行督办。3.4延期与异常处置若计划修复时间内确因架构限制、厂商配合等无法完成修复：1.责任人必须在修复期限截止前4小时提交延期申请，附带未修复的技术原因、临时缓解措施及预计完成时间。2.业务方负责人及安全主管审批后，在跟踪表中更新状态为“延期处理中”。3.严禁隐瞒不报或直接拖期，隐瞒不报一旦被安全审计发现，直接按重大违规处理。四、责任划分与追责机制责任不清会导致漏洞在开发、运维、安全之间“踢皮球”，明确责任主体并绑定绩效考核是推动整改的唯一手段。责任划分遵循“谁主管谁负责，谁运行谁负责”原则。4.1角色与职责边界•漏洞发现方（安全团队）：负责漏洞定级准确性、整改方案可行性评估、复测时效达标。若因整改方案误导导致修复失败，安全团队承担连带责任。•漏洞修复方（研发团队）：负责按SLA时效与整改规范完成代码级修复及自测。对代码修复质量负责，严禁虚假整改（如仅修改前端展示不改后端逻辑）。•系统运维方（运维团队）：负责网络层策略调整、WAF规则下发、系统补丁安装。若因WAF规则配置不当导致已被通报的漏洞再次被利用，运维团队承担主责。4.2追责标准对于严重违反SLA及整改规范的行为，按以下层级追责：1.虚假整改：在复测中判定为虚假整改（如删除前端报错但未修补后端逻辑），直接扣除当事人当月绩效分数，并全公司通报批评。2.超期未修复且无延期申请：高危漏洞超期24小时未修复且无审批记录，自动触发红色预警抄送至CTO；累计超期3次，取消年度评优资格。3.导致安全事件：因漏洞未及时修复导致真实安全事件（如被勒索、数据被脱库），依据《信息安全事件管理办法》启动定级问责，直至解除劳动合同，保留追究法律责任的权利。五、网站漏洞整改跟踪表标准模板表格是整个流程的载体，必须确保每列字段具有不可篡改的追溯性和明确的填写口径。本模板可直接导出为Excel或通过工单系统字段配置实现。漏洞ID系统名称URL及参数漏洞类型风险等级发现时间漏洞描述与演化路径整改方案与机理指导责任人计划修复时间实际修复时间复测结果当前状态延期说明VW-2024-001用户中心/api/v1/profile?uid=SQL注入高危2024-05-1010:00uid参数未过滤，可通过UNION注入获取user_account表全量数据，导致大规模PII泄露必须改为预编译查询；严禁黑名单过滤张某某2024-05-1110:002024-05-1114:00通过已闭环无VW-2024-002订单查询/order/detail水平越权中危2024-05-1214:30修改order_id参数可遍历他人订单，导致商业机密泄露后端强制校验order_id与当前session用户归属关系李某某2024-05-1518:002024-05-1610:00未通过复测中无（重开计时）VW-2024-003资讯门户/search?q=反射型XSS低危2024-05-1509:00q参数未编码，构造闭合标签可执行任意JS，可窃取非敏感Cookie输出层进行HTML实体编码王某某2024-05-3018:00待定待测修复中需排期附件：漏洞整改自测与复测检查清单本清单供修复方提交复测前对照自查，确保修复有效性，避免无效流转。5.1通用自测清单•[]是否已在测试环境完整模拟攻击载荷并验证不再触发漏洞？•[]除了报告指出的特定参数，同一接口的其他参数是否也已采用相同修复标准？（横向覆盖检查）•[]修复代码是否引入了新的安全风险（如正则表达式引发的ReDoS）？•[]是否仅修改了前端展示？（若是，请打回