成熟的软件安全建议方案应允许有限例外, 但每个例外都必须有业务理由、风险评估、补偿措施、审批人和失效日期。
先判断是否允许例外
涉及已利用高危漏洞、弱口令、公网暴露后台、明文密钥和重大数据泄露风险的问题, 原则上不应长期例外。确需短期放行时必须先采取止血措施。
写清补偿控制
如果漏洞暂时无法修复, 可以通过访问控制、WAF策略、限流、监控告警、配置隔离或功能降级降低风险。补偿措施需要被验证, 不能只写计划。
建立审批和失效机制
例外申请应包含影响资产、风险等级、业务影响、责任人、到期日期和复核频率。到期未处理必须升级, 防止临时例外变成长期隐患。
用数据复盘例外趋势
管理团队关注例外数量和逾期率, 安全保障团队关注补偿措施有效性, 研发团队关注重复例外的根因, 共同推动能力改进。
落地检查清单
- 高风险问题不长期例外
- 补偿措施已验证
- 例外有到期日期
- 逾期自动升级复核
方案建议将本文控制项写入软件安全建议方案, 并分别指定研发负责人、管理审批人和安全保障复测人, 形成可追溯闭环。
常见问题
这类文章适合放在项目方案还是组织基线?
通用规则建议进入组织级软件安全基线, 项目方案只保留与当前系统风险、业务范围和上线节奏直接相关的控制项。
如何判断措施是否真正落地?
看是否同时具备责任人、执行记录、工具或人工验证结果、例外审批和复盘改进记录。缺少证据的措施不宜作为已完成项。