安全发布是产品或项目的正式发布或正式上线活动，这意味着一旦发布完毕，所有的用户都可以看到和使用产品，如果被发现有安全漏洞或遇到安全攻击，其影响可能会涉及到所有的用户，轻则影响产品或公司形象，重则影响公众对于产品或公司的信任，甚至产生财产损失。

在SDL模型中，安全发布涉及到三个活动，分别是事件响应计划、最终安全评析、发布/存档。

事件响应计划是公司安全部门应当具备和准备的能力和方案，不仅仅和产品发布相关，其中涉及到安全攻击，也涉及到业务连续性，因此需要公司层面由高层牵头成立应急响应小组或委员会，其中的成员涉及到各个业务线、部门的负责人或指定的负责人，确保一旦发生安全事件可以快速上报、协调相关部门的资源进行响应，其中也包括安全部门、运维部门、开发部门等核心技术部门的技术对接人，能够协调技术人员进行事件分析和处置。

所有联系人应当都具有姓名、部门、岗位、手机等联系信息，对于关键岗位还需要预留多一个人的联系人和联系方式，避免联系人无法联系到而造成事件无法及时处理。

作为安全部门，应当设立应急响应制度和计划，通过制度明确上述的应急响应小组或委员会的合法性，通过计划明确小组成员的职责，以及发生安全事件后不同部门和人员协同的方式。

对于安全事件而言，安全部门尤其需要熟悉每一条业务线和每一个产品的业务模式、业务逻辑、受众对象、产品定位以及业务和资产的对应关系，在事件发生后可以第一时间判断事件影响的目标、范围和相关的部门及人员，安全漏洞和安全攻击事件发生后的很多时间和精力都往往花费在确认业务-资产-部门/人员的三方关系上，而这又会增加抑制手段的选择成本和处理时间。

业内常用的应急响应模式是PDCERF模型，即准备（Preparation）、检测（Detection）、抑制（Con-tainment）、根除（Eradication）、恢复（Recovery）、跟踪（Follow-up）六个阶段：

  1. 准备。在事件未发生时的准备工作，包括策略、计划、规范文档及具体的技术工具和平台。
  2. 检测。初步判断是什么类型的问题，受影响的系统及严重程度。
  3. 抑制。限制攻击、破坏所波及的范围，通俗地讲叫“止血”。
  4. 根除。对事件发生的原因进行分析，彻底解决问题，避免在同一个问题上再次犯错。
  5. 恢复。把业务恢复至正常水平。
  6. 跟踪。落实整改措施并监控是否有异常，即安全运营中的持续改进。

最终安全评析（FSR，Final Security Review）是对应安全需求阶段的质量门槛或Bug门槛设置的检查，检查最终产品的安全状况和安全问题是否能够通过质量门槛或Bug门槛。实际工作中，常常由于能够将业务、产品、安全结合思考或理解的人员很少，所以很少有严格意义上的最终安全评析。能否进行产品发布或产品上线，是由安全部门工程师根据安全测试阶段的结果，和业务或开发人员沟通、确认的，在完整的产品研发周期中，发布和上线需要产品经理、测试人员、安全人员签字确认或确认之后才能够正式发布到生产服务器。

安全人员与业务人员沟通、确认的结果大致分为三种情况：

  1. 允许发布，即待发布的产品没有严重、高、中等级的安全漏洞或风险，且低等级的安全漏洞或风险可以接受；
  2. 允许发布，但部分漏洞可以留下一个迭代修复，即待发布的产品中存在中等级的安全漏洞或风险，但影响有限，所以可以在下个迭代中修复；
  3. 是否能够发布存在争议，即安全人员和业务人员对于能否发布或能否容许漏洞存在或风险留下一个迭代解决存在争议，则需要向上汇报到业务负责人或者更高管理层确认，并解决争议，通常安全部门负责人和业务线负责人就可以确定这点；

通过上述的工作后便可以通过安全部门的确认正式上线产品或项目，在当前的软件开发过程中，相关的源代码、组件、许可证等等通常已然都会有留存或存档，方便一旦发生安全事件后可以快速定位漏洞、开发和发布hotfix，但文档的留存是当前诸多开发团队中所欠缺的，文档更多是产品开发后的补充结果，但很难保持持续更新和维护，这导致的结果是当发生安全漏洞需要做修复时，往往只能由当时开发这部分代码的开发人员进行修补或修复，当人员存在变更或交接时，便会存在由于人员更替导致的修复时间增长。

因此，安全开发生命周期的根本是开发生命周期，只有在确保有足够完整、健康的开发周期和手段之上，构建安全的开发手段才能够稳定、可靠、可衡量，否则越多的安全工作反而会增加产品开发的难度和周期，甚至造成产品研发的混乱。