“在本环节中，已经不再涉及到SDL中的“工具”，转而向“流程”。产品发布前的最后一道关卡，做最终的安全验收。无论是否能满足安全质量要求，产品均有可能发布上线，但一定得有兜底的措施。”
01
—
安全目标
对于符合安全部门要求的产品，放行发布上线；对不符合安全要求的产品，理论上则不允许上线。然而在实际的场景中，业务和安全孰轻孰重一直是热议的话题，即使是在大型互联网公司也会存在部分业务优先。但在放行不达标产品前，需要将安全风险降低和安全责任抛出，并制定一系列的第二或第三选择安全方案进行兜底，切实起到公司安全投入有产出、安全赋能产品的初衷。
02
—
安全活动
在发布审核阶段，安全活动主要围绕最终安全评审、安全绿色通道开展。
1）最终安全评审
最终安全评审内容包括：安全设计checklist自检报告、静态代码扫描报告、web漏洞扫描报告、人工安全测试（前三项在安全测试阶段已经完成check，且为人工安全测试的充分条件），以及人工安全测试发现的高中危漏洞是否有遗留。
2）安全绿色通道
面对不同情况下的“业务优先”，安全部门需要预留特殊通道为不符合安全要求的产品做好准备。此时，需要关注以下三点：
- 制定漏洞修复计划：指定漏洞整改责任人，并明确完成漏洞修复的时间点，交由项目管理人员跟进
- 明确已知安全风险：对业务方声明已知安全漏洞可能带来的风险与隐患，并要求其确认造成的损失或影响由业务方承担
- 报备上级领导审批：将上述两点进行详细描述，发送邮件上报业务方领导备案，请求“带病”上线
03
—
安全实践
1）简单的最终安全审核
上线前的安全审核，往往会提前开始于测试阶段进行，到发布上线前的审核工作相对简单很多，比如仅看该项目是否包含安全提测工单、安全提测是否通过。除此之外，审核后需要手工或自动配置域名转发、边界防火墙映射等，故这部分工作一般由非安全测试人员负责，最终安全评审实际意义上也就是最终安全审核。
2）绿色通道具体流程
在实际的产品研发中，无论是因为产品经理没有预留足够的时间，还是发现漏洞较多或修复成本较大，难以在一定时间内修复，总会碰到申请绿色通道。一般有以下流程：
- 报备：产品经理根据安全测试结果，制定漏洞修复计划和时间，须明确“漏洞1 - 开发A - xx时间”完成修复，并声明由已知安全漏洞带来的风险由业务方自己承担，发送邮件给业务方老大请求批准，并抄送安全部和项目管理报备
- 审批：须由业务方老大在明确风险后，敲定最终是否上线
- 放行：安全审核人员在收到业务方老大批准的邮件后，点击安全通过按钮，进入后续发布环节
- 上线：随即产品在基础防护范围内上线，比如配置https、只允许经过waf后访问等基础安全防护。
04
—
持续优化
该环节的需要关注点在已知风险告知，难点在遗留漏洞跟进闭环，可能存在绕过的点在安全审核。其中需要优化和加强的便是安全审核，建立一定的机制进行check，确定业务方是否：
- 有意识或无意识的使用历史安全提测单，蒙混过关
- 暂时悄悄的修改漏洞状态为已修复，强行安全达标
- 在线系统功能迭代或更新，不走SDL相关流程…
然而，最终安全审核是否被“旁路”，很大程度上取决于现有的研发流程。因为SDL并不是要求业务方一起来玩一套新的流程，而是在现有研发流程中适当加入必要的安全活动。针对已经存在的问题和难题，如果从流程上难以解决，可以通过立规矩、技术手段发现特例、依据进行处罚等方式进行补强。然而，这些都不是一蹴而就，需要循序渐进的发现和优化。
