文章前言
按照<产品安全开发流程规范>中的安全流程制度规范，在所有项目在立项时都必须要通知到安全团队，安全团队需要在项目立项时就产品安全评估流程进行贯宣，同时需要对产品最终上线前的安全质量要求进行贯宣并引导输出安全需求，尽早的规避因为后期安全评审阶段无法通过评审导致业务系统无法正常上线
安全需求
安全需求是考虑到产品上线后由于产品自身潜在的安全问题而带来的经济损失以及时间成本等问题而将安全工作进一步进行左移的SDL关键环节，在安全需求分析阶段安全团队需要对产品自身潜在的安全风险进行风险评估并建立与之对应的安全需求表
安全活动
在安全需求阶段的主要安全活动包括以下三个方面：
安全评估流程宣贯
在项目立项之初安全团队需要对安全评估流程进行贯宣，在此阶段安全团队需要重点告知项目组成员应该要关注的安全流程，尤其是把控项目进度的项目经理和负责产品功能需求变更的产品经理，在安全评估流程贯宣期间需要注意以下两个维度：
- 安全评估持续性：安全评估是一个持续循环的动态过程，需要对安全风险评估的结果及时进行跟踪监控、定期更新、建立信息反馈与沟通、互动与共享机制
- 安全评估覆盖率：安全评估需要覆盖产品需求、产品设计、产品研发、产品测试等阶段，每当有新的业务功能需求的引入或者变更往往都会带着新的安全问题的出现
- 安全评估文档输出：安全评估期间需要输出与之对应的安全评估文档，例如：在产品需求和产品设计阶段通过对产品自身的安全风险进行威胁分析并输出与之对应的安全需求checklist，之后在最终的安全评审之前对安全需求设计Checklsit进行验收，检查其实现程度并以此作为安全评审的评审文档之一；在产品研发期间对代码进行静态扫描后的扫描报告；在产品测试期间对产品安全的测试报告(渗透测试报告、代码审计报告、漏洞扫描报告等)
安全需求表格输出
从以下三个维度对安全需求进行考虑并输出安全需求CheckList(在安全评审阶段需要对安全需求设计表中提出的安全需求进行检查并作为上线前的安全评估依据之一)：
- 法律法规：从法律法规角度检查在软件需求分析阶段是否有可能牵涉的法律法规需求问题未考虑到
- 隐私安全：从隐私安全角度检查在软件需求分析阶段是否有考虑到用户使用软件产品时的隐私安全
- 业务安全：从业务安全角度检查软件需求分析阶段是否有考虑到软件自身业务功能设计的安全问题
安全质量要求声明
在项目立项之初安全团队需要就项目对外发版的安全质量要求进行贯宣，不同的企业可以结合自身特性(金融机构、政府单位等)制定适合自己的安全质量要求，针对不同类型的软件产品制定不同的软件安全质量衡量标准：
- 内部系统：企业研发的内部使用的系统只需要满足主机漏扫无高中危漏洞、Web漏扫无高中危漏洞
- 外部系统：企业研发的对外发布的系统需要满足Web漏扫、人工渗透、代码安全审计均无高中危漏洞、安全设计checklist达标
- 采购产品：第三方需要提供产品安全证明材料并在签订合同时须包含安全责任协议和应急止损售后服务，这里的安全证明材料一般是指第三方安全公司出具的报告，包括代码审计报告、主流扫描器漏扫、渗透测试报告、开源组件清单(依赖的开源组件类型和版本信息)
常见难点
安全需求阶段时常会遇到以下问题：
- 安全需求挖掘深度：有些业务产品的安全需求挖掘深度不够，导致后期出现新的非常见类型的安全需求需要重新对业务功能做变更加入安全设计，增加成本
- 安全需求覆盖广度：产品业务需求会有不断的新增、变更等情形，最初的安全需求清单往往不会包含后期因为业务变化而带来的安全风险需要增设的安全需求项，当然也不排查后期新业务功能未做安全风险评估和忘记将安全需求纳入需求列表中
文末小结
安全需求作为SDL的第二个环节实施时需要特别注意安全评估流程制度的贯宣和安全评审阶段对安全质量的要求声明，如果前期不重视安全后期安全评审时要么就是因为种种原因导致产品无法上线，要么就是走绿色通道使得产品"带病"上线，增加安全风险
