一个可执行的SLA需要同时规定发现来源、风险分级、响应时限、修复时限、复测责任和延期备案条件。
统一漏洞来源和分级
漏洞可能来自代码扫描、依赖检查、基线核查、渗透测试、众测、日志告警和外部通报。不同来源应进入同一漏洞台账, 用统一标准标记高危、中危、低危和信息项。
设置可执行时限
弱口令和公网暴露类问题通常需要小时级止血, 高危漏洞需要优先修复并复测, 中危问题应在约定周期内完成闭环。方案中必须写清逾期升级和业务负责人确认机制。
复测比修复声明更重要
漏洞关闭不能只看研发口头反馈, 应由安全保障人员或自动化工具复测确认。复测记录要包含漏洞编号、版本、验证方式、结果截图或日志。
把延期纳入管理能力
确实不能按期修复时, 需要临时缓解措施、风险说明、审批人和最终修复日期。延期不是放弃整改, 而是纳入可追踪的管理闭环。
落地检查清单
- 漏洞来源统一入库
- 不同等级有明确时限
- 关闭前必须复测
- 延期有审批和补偿措施
方案建议将本文控制项写入软件安全建议方案, 并分别指定研发负责人、管理审批人和安全保障复测人, 形成可追溯闭环。
常见问题
这类文章适合放在项目方案还是组织基线?
通用规则建议进入组织级软件安全基线, 项目方案只保留与当前系统风险、业务范围和上线节奏直接相关的控制项。
如何判断措施是否真正落地?
看是否同时具备责任人、执行记录、工具或人工验证结果、例外审批和复盘改进记录。缺少证据的措施不宜作为已完成项。