信息安全发展到新阶段，大家对应用安全本身越来越重视，主要原因大致是下面这几点：

          上医治未病 – 《黄帝内经》中有“上医治未病，中医治已病，下医治大病”的说法。也就是信息安全事件的事前、事中、事后的三个阶段。聪明的我们一定是事前做好各种预防措施，才能起到事半功倍的效果。在软件开发的整个生命周期来重视开发安全，就如同安全问题在源头给予了积极的解决，这样不单单是安全问题可以得到比较彻底的解决， 同时也节省了解决安全问题的成本。所以我们希望通过开发安全的实践来解决原来头疼医头、脚痛医脚的习惯，把安全问题消灭在萌芽状态。

          开发安全的理论基础和实践日趋成熟 – 软件开发到当前为止，经历了三次危机，第一次是上世纪60年代 – 日益庞大和复杂的程序对开发管理要求越来越高，解决的办法是“软件工程”，第二次是上世纪80年代 – 软件规模扩大、可维护性困难，解决的办法是“面向对象语言”，第三次是本世纪头10年 – 软件安全问题，解决的办法是“软件开发安全生命周期管理”。目前软件开发安全生命周期管理以微软SDL的模型领头，其他主要的还有BSIMM、CLASP、SAMM等，这些理论模型日趋成熟和被业界普遍采纳实践，使得我们的实践活动有了一个很好的参考。软件安全检测技术的普及 – 软件安全检测技术由原来对语言规范性的检查，发展到对代码质量的检查，再到安全缺陷的检查，从最简单的结构流到控制流、数据流等复杂的检查，逐步深入；检测的工具也由原来简单的单人使用的命令行工具到目前多人协同工作的系统平台；从原来的白盒到现在白盒、黑盒、灰盒等等，整个检测技术的广度、深度、精度都得到了极大的提高。上面所说的这些主要理由，都使得在当前阶段软件开发安全的工作开展变得顺理成章。为了软件开发安全的实践活动能够科学地、系统化地、有效地落地，也是需要遵循一定的建设框架作为我们行动的指南。

          PPT和PDCA两个框架应该是我们IT圈内最最有名的行动模型，PPT框架中人、流程和技术也称之为黄金三角。

一、人

          这里的人主要包含了两个层面的意思，一个层面指的是我们软件开发安全中的各个角色，尤其是和开发安全相关的角色以及这些角色的职责，另外一个层面指的是人员的安全意识和技能。

          我们先就一个项目的范围来看下开发安全团队的角色的变化。

注解

          安全评估人员 – 该角色的职责在于对项目安全和隐私进行监督管理，有权接受或拒绝软件研发项目团队的安全和隐私计划和方案。而该角色又可以细分成两个子角色：

        审计官 – 此角色人员必须监控软件开发过程的每个阶段，并证明每个安全规范要求的成功实施。该角色必须能够自主证明过程是否符合安全和隐私方面的要求，二不受项目团队的干扰。

         专家 – 此角色人员必须在软件安全技术方面拥有可靠的相关专业知识。

          项目安全负责人 – 一般由项目团队的安全专家担任。主要负责协商、接受和跟踪最低安全和隐私要求，并在软件开发项目过程中与安全评估人员保持通畅的沟通渠道。此角色可由项目研发团队中的项目经理、开发主管、QA、测试工程师、开发工程师等兼任。

          安全需求工程师 – 主要负责运行环境的安全需求，识别全局的安全策略，识别资源和信任边界，识别用户角色和资源权限，编写安全相关需求文档，明确软件误用的情况。

          安全设计工程师 – 主要负责识别攻击面，威胁建模，应用安全设计原则制定和遵循，标注类设计的安全属性，明确数据库的安全配置，处理报告出现的安全问题，编写安全操作指南，安全问题归零处理过程管理等。

          代码审计人员 – 主要负责安全编码规范的指定， 白盒扫描的客制化规则的编写，白盒扫描结果的审计，核心代码的安全人工审计等。               

          安全测试人员 – 主要负责系统的安全测试用例的编写， 黑盒、渗透等的测试工作，安全问题归零处置等。

          我们需要明确的是，这里的角色可以是多个项目共享的资源

          关于人的安全意识和技能方面，包括国家信息安全相关的法律、法规的熟悉，本行业上级管理部门发布的指导意见和业务规范，合规标准和业界的最佳实践；掌握了这些安全知识使得我们容易对应用系统进行合适的定级分类；另外对于需求、设计、开发、测试人员还需要掌握软件开发安全全生命周期管理的知识，安全需求识别的能力，威胁建模、攻击面分析的能力，安全控制项的选择和设计能力，安全编码规范的制定能力，信任边界的识别能力，代码审计能力，各类检测工具的有效使用能力，安全测试用例的编制能力，安全运维的能力，安全处置的能力等等。

          如果我们企业要去开展软件开发安全的实践活动，在“人”的建设方面需要积极培养企业自身的人才。譬如，可以从原来的开发队伍中来培养安全测试人员，代码审计人员等。

          适当引入第三方的专家。可以在各个关键节点引入第三方的安全专家，更加全面的提高安全性。

          不是日常性的安全实践活动的外包。譬如，渗透测试，可以寻找实战经验丰富的外包团队进行相关的测试。

          定期、周期性地进行安全培训活动。在项目开始的培训阶段，针对不同角色可以开展内训和外聘专家培训的方式进行集中式的培训；在项目进行过程中， 遇到任何安全问题进行“即时式”的安全培训。同时我们也可以采用线上的方式， 通过视频、博客、阅读等多种方式进行自主、自助式的培训。最后强调的是，学以致用，我们可以通过考核的方式来验证培训的效果， 同时我们更加可以在项目进行过程中通过跟踪人员的KPI指标来进一步验证培训的成果。

           以上这些我们简要说明了“人”这个要素。

二 、流程

          当我们谈到软件开发安全，首先浮现在我们脑海里的一定是‘流程’。譬如，下图的典型的微软的SDL流程。

这里一共定义了7个阶段17个任务。

          目前除了微软的SDL流程，另外两个比较流行的就是BSIMM和OPEN SAMM。

          其中BSIMM模型比较特殊，这是一种描述性模型， BSIMM的唯一目标就是观察和报告。这种“只说事实”的方法在科学和工程领域比较常见，但在软件安全领域如此大规模地采用这种方法却是前所未有的。

          BSIMM SSF包含四个领域 – 治理、情报、SSDL触点和部署。这四个领域又包括了12个实践模块共119项具体的活动，而其中有12项活动是目前参与调研的公司都在实践并且发现是行之有效的，如下图：

         

         

         

 

         

 

         

 

          OPEN SAMM是大名鼎鼎的OWASP组织的一个开源项目，该软件成熟度模型提供了一个开放的框架，用以帮助软件公司制定并实施所面临来自软件安全的特定风险的策略。

          

          目前该模型已经有2.0版本发布。

          鉴于篇幅的问题， 对流程中的各个安全实践活动在本篇我们就不再一一展开。

   我们来看一下这么多不同的流程模型到底分别适用于哪些场景。我做了一个粗略的比较如下图所示：

          

          大家有兴趣的话可以找些其他的参考资料进行深入地了解，我们后面有机会也将更加深入具体地对这些模型以及如何落地和潜在的问题做更深入地探讨。

三、 技术

          我们前面谈了“人”和“流程”，最后我们来谈下“技术”。             

          如果我们给予项目开发的每个阶段有且仅有一个核心的安全实践活动，那么我们认为是这样的：  

需求阶段 – 安全需求：（1）设计阶段 – 威胁建模（2）开发阶段 – 代码审计（3）测试阶段 – 安全测试（4）部署阶段 – 安全加固（5）运营阶段 – 事件响应（6）下线阶段 – 资源回收

          在这里我们简单分析应该使用什么样的技术来落地这些核心的安全实践活动。

1. 需求阶段的核心任务就是通过业务需求，结合法律、合规、行业要求、业界最佳实践来获得对应用进行风险评估进而获得该项目的安全需求。在这个阶段我们需要一套风险评估的模型，结合我们经验累积的知识库，通过诸如场景式地问卷调查方式来推导出该项目的安全需求。

2. 在设计阶段我们主要做的就是威胁建模， 这是在设计阶段我们主要做的就是威胁建模， 这是安全设计的基石，我们最基础的可以利用微软的威胁建模工具，STRIDE方法论来识别潜在的威胁，另外我们OWASP也有相应的工具提供我们在线进行威胁建模。

3. 开发阶段的代码审计我们可以利用白盒检测工具，根据安全左移的理念， 我们提倡开发人员可以利用优秀的代码审计平台进行自主、自助式的白盒代码检测，同时我们也可以和DevOps中的CI/CD工具进行无缝集成，做到源代码的自动化检测，这里的代码审计包含了利用工具进行软件成分分析也就是开源组件的安全漏洞检测等，当然我们企业内部或者借助外部的第三方专家也可以开展人工代码审计。

4. 测试阶段的安全测试主要利用到我们的黑盒检测工具、IAST检测工具对构建的应用系统进行全面的主动式、被动式的安全检测，这些目前业界都有比较好的工具可以使用， 无论是商业化的或者是开源的都可以方便地找到。同时我们也可以将黑盒、IAST检测工具和DevOps的自动化工具进行集成，去组建安全的冒烟测试， 这将更深入地落地我们的安全测试工作。

5. 部署阶段的安全加固主要是基于安全漏洞检测、安全基线检测对于我们应用系统正常运营所依赖的主机操作系统、数据库、中间件等发现的问题进行有针对性的加固措施，提高我们整体应用系统运行环境的安全性。

6. 运营阶段的事件响应是基于对应用系统及其运行环境的持续监控，我们通过我们自己的“鼎赛慧眼”安全运营平台给予企业全方位的安全事件PDRR闭环处理大数据平台，从安全日志的收集、规约化，综合分析到安全事件的有效提取，事件的告警，基于KillChain和ATT&CK框架的安全告警事件的分析以及和情报、流量结合的资产风险和风险评估等一系列大数据分析来缩短用户事件响应的时间，提升分析的有效性和高效性。

7. 下线阶段的资源回收我们是通过“鼎赛慧眼”开发安全质量治理中心来监控和某个应用整体相关的一系列的资源的回收过程、状态来保证应用系统合法、合规的下线。例如和应用相关的所有网络资源、网络配置、服务器资源、商用软件的许可证、应用数据的脱敏、加密归档，应用日志符合网络安全法的归档和保存期限的监控、以及相应的代码仓库软件分支的清理、代码仓库相关账户的清理和测试、开发环境的清理等等。

          上面我们回顾了项目开发过程中每个阶段主要的安全实践活动所涉及的技术落地措施。其中分别提到了鼎赛的慧眼安全运营中心和慧眼开发安全质量治理中心两大平台这两大平台很好地帮助企业快速有效地开展安全运营和开发安全质量治理。

结束语

          软件开发安全的PPT我们简单介绍完了，想在这样一篇小短文中介绍完整的软件开发安全这个主题确实非常困难，本篇作为一个引子和铺垫为我们下来介绍鼎赛开发安全质量治理中心这个大平台打下一个前期的知识准备，同时这个PPT框架也是指导我们设计和构建开发安全质量治理中心这个平台的理论支撑之一，所以了解了本篇介绍的内容为接下来更好地了解开发安全质量治理中心这个大平台打下了基础。

          让我们尽情期待开发安全质量治理中心的详细介绍。