安全评审该不该拥有"上线一票否决权"？

背景： 我做了 3 年安全加固与风险防范，最常被产品/研发问的一句话就是："安全评审到底能不能卡上线？" 这背后其实是安全与交付速度的长期拉扯。今天想借这个帖子把几种做法摆出来，听听大家在真实项目里怎么选。

常见分歧 / 几种做法：

1. 一票否决派：安全不签字就不发版。逻辑是"安全是底线，出一次 0day 数据泄露，前面赶的进度全归零"。优点是责任边界清晰；缺点是安全团队容易变成瓶颈，甚至被绕过（私下发、走后门）。
2. 风险分级放行派：按风险打分，高危阻断、中低危记录后放行 + 限期整改。优点是兼顾效率，缺点是"分级标准"本身经常扯皮——谁来定级、谁拍板。
3. 事后追责派：安全不卡流程，出事再复盘。优点是开发体验好，缺点是把风险攒到爆发，且复盘往往找不到当初为什么放。

我的倾向与理由： 我偏向"风险分级 + 高危一票否决"的混合模式，理由有三：

• 安全的目标是"可接受的风险"，不是"零风险"，一刀切否决既不现实也浪费安全团队精力；
• 但高危项（明文凭据入库、未鉴权的敏感接口、已知可远程利用的 CVE）必须有硬卡点，否则等于没有底线；
• 关键是把"谁有权把高危降级为可接受"这个权力明确写进流程并留痕，而不是口头豁免——留痕既是审计需要，也是安全团队自我保护。

想听大家在什么场景下怎么选：

• 你们是初创小团队还是有大安全团队的组织？流程差异有多大？
• 高危项的"定级 + 降级"你们是怎么落地的？有没有可复现的清单/工具？
• 当业务方施压要"先上线再补"时，你们的安全团队靠什么守住底线（制度、工具、还是人）？
• 有没有踩过"安全被绕过"的坑，后来怎么收口的？

欢迎贴你们的流程、清单或反例，越具体越好。