软件安全中的内建安全
当今社会，信息技术已经成为人们生产生活中不可或缺的内容，世界大多数国家都把加快信息化建设作为发展战略。信息化建设涉及的范围、领域非常广泛，但大致可以分为国家层面和企业层面。其中，国家层面建设的主要是关键信息基础设施，指一旦遭到破坏，可能严重危害国家安全、国计民生、公共利益的信息系统；企业信息化建设指通过信息技术的部署来提高企业的生产运营效率，增加企业收益和持续经营的能力。因此，这些信息系统对于国家或企业的发展至关重要，其安全性更是不容忽视。
虽然信息化建设涉及的领域很多，但总体而言，主要包括硬件设备、软件程序和信息数据三大部分，但对于硬件设备的控制、对于信息数据的操作处理也需要软件来实现，因此软件是系统的“灵魂”，而程序代码是软件的具体呈现形式，难怪Gartner公司简意赅地指出：“基础设施即代码”。可见，代码是信息化建设中的核心要素，是信息系统或基础设施中安全防护的重点。
信息技术采购全球化的发展态势使得国家或企业信息系统的产品来源更加多元化，信息技术供应链更加复杂。软件构建方面更是如此。许多情况下，软件系统是来自世界各地的代码组合起来的，包括自主开发的、商业购买的、开源提供的、外包开发的等。VeraCode公司曾统计过，30%-70%包含自主开发软件的代码也含有第三方代码，并多以开源组件、商业或外包共享库/组件的形式存在。这种方式提高了软件开发的效率，但对其安全性和可控程度无疑是巨大的挑战。尤其近年来Struts2、OpenSSL等应用非常广泛的基础开源组件高危漏洞频现，伊朗“震网”、乌克兰“黑暗能量”等基于基础软件漏洞的恶意程序肆意侵入工控系统，让国家和企业对软件供应链、开源软件、关键信息基础设施中软件安全性的关注程度逐渐提高，某些内容在国家法规和战略中已有所体现。
为了保障软件安全，能够“尽早、尽快”发现并修复软件系统中漏洞的方法是急迫所需的，这正是内建安全（Build Security In，BSI）的开发方式提倡的。源码作为软件的原始形态，具备丰富的语义信息，对于它的保障能够尽早且较为全面的发现软件中的问题，符合BSI的原则，越来越多的机构和个人也意识到了其在高效保障软件系统安全方面的作用。
内建安全的体系化方法
目前，企业针对信息系统的安全措施仍主要集中在临近上线时的渗透测试或安全审计，以及上线后的防火墙等被动防御方法。这种方式使得漏洞发现的时机较晚，造成修复代价高昂，而且一些基于业务逻辑的攻击在上线后也难以发现。
上述将安全与开发割裂的做法被证明越来越不适应信息系统建设对安全性的需求，由于大量安全措施都应用在开发过程之外，问题不能及时反馈给开发人员。针对这些局限性，10多年前，BSI的思想被提出，具体而言就是把各种安全实践内建到软件开发的各个关键环节之中，利用自动化技术从源头上尽早、尽快、持续、以团队共同协作的方式发现安全缺陷，提高解决安全问题的效率。BSI通过开发团队中已有的角色实施安全措施，利用自动化安全分析和测试技术快速地发现安全问题，以达到全方位的安全开发。但是，由于资金和意识等方面的限制，目前能够深刻理解BSI并实际运用的企业还很少。
微软提出的安全开发生命周期（Security Development Lifecycle，SDL）无疑是BSI思路的最佳实践之一，微软已将其作为强制策略应用于自己产品的开发中。SDL从漏洞产生的根源上解决问题，通过对软件工程的控制，保证产品安全性。SDL将安全实践贯穿于软件开发和运维的7个阶段：在培训阶段，对开发、测试人员、项目经理、产品经理等进行安全知识培训；在需求分析阶段，确定安全要求、Bug列表，并进行安全风险和隐私风险评估；在系统设计阶段，详细考虑安全和隐私问题，进行攻击面和威胁建模分析；在编码实现阶段，选择安全性更高的编译器，禁用不安全的API，并在工具辅助下对源代码进行静态分析，对结果进行人工审计；在测试验证阶段，进行模糊测试、渗透测试等动态分析，并对之前的威胁模型和攻击面分析结果进行验证；在发布和响应阶段，将软件存档，确立事件响应计划，并进行最终的安全评析。具体如下图所示。
SDL是一种针对传统瀑布型开发方式的安全模型，随着对软件开发质量和效率要求的不断提高，以DevOps为代表的敏捷开发方法得到推崇。在此基础上，Gartner公司于2012年推出了DevSecOps的概念，旨在将安全融入敏捷过程中，即通过设计一系列可集成的控制措施，增大监测、跟踪和分析的力度，优化安全实践，集成到开发和运营的各项工作中，并将安全能力赋给各个团队，同时保持“敏捷”和“协作”的初衷，架构如下图所示。
DevOps的目的决定了其对“自动化”和“持续性”的要求更加突出，因此在将安全控制集成其中时，也应该尽量遵循“自动化”和“透明”的原则。为了将安全无缝集成到DevOps中，Gartner和一些专家从实践出发提出了一系列建议，主要包括：风险和威胁建模、自定义代码扫描、开源软件扫描和追踪、考虑供应链安全问题、整合预防性安全控制到共享源代码库和共享服务中、版本控制和安全测试的自动化部署、系统配置漏洞扫描、工作负载和服务的持续监控等。
根据上面的分析，在BSI及其相应模型中，无论基于何种开发方式，安全的位置都被提前，贯穿于开发运营的各个阶段，并强调团队协作，不再仅关注即将上线和运行时的后验性安全防护措施。不难看出，针对架构和源代码安全分析的重要性更加突出，在DevSecOps中更是涉及对开源软件、源码库、版本控制等的相关考虑。因此，从内建安全的现实需求而言，源码安全保障对提高软件的整体安全质量具有不可替代的重要核心作用。
源码安全保障具体实践
源码安全保障是软件上线前实施的重要安全措施，也是SDL、DevSecOps等BSI模型着重关注和要求的内容。源码安全保障并没有一个固定的范围和概念，概括来说，它是对上线前的开发文档、源代码等进行分析、测试、综合管理，以尽量“多、快、准”地发现其中安全隐患（如安全缺陷、违背安全规则的情况等），并修复的过程。根据我们团队多年的工作经验，好的源码安全保障应当至少完成“按照安全编程规范编写代码”、“使用经过安全确认的开源代码或第三方组件”、“对编写出的源代码进行缺陷检测和修复跟踪”等工作。结合具体应用，我们归纳出了如下的实践工作：
1、威胁模型分析
威胁模型分析原指设计阶段软件架构安全性分析的一种方法，用来发现软件中潜在的威胁点，主要判定是否可能存在对敏感数据的非正常操作。但是，现在威胁的范围更加广泛了，开发中因人或管理因素引入的安全问题也应属于建模范围，需尽早考虑。主要工作有：对开发人员进行安全编码、编写能够拦截常见攻击的代码等方面的培训；开发简单的自动化威胁和风险建模评估工具，如微软的STRIDE，并在安全设计中使用，特别针对处理敏感数据或者直接访问互联网的软件应进行深入的、多层次的建模分析。
2、源码缺陷分析
源码缺陷分析指利用自动化静态分析工具发现源代码中的缓冲区溢出、SQL注入、跨站脚本等安全缺陷的过程。目前静态分析工具的缺陷检测规则大多是基于CWE、OWASP Top10、CWE/SANS Top25等标准提取的，不同工具支持的语言多少不等，但对于主流的C/C++/JAVA/PHP等语言支持的较多。当前静态分析工具主要的问题仍然是误报较多，因此需要进行人工审计，该项工作需要一定的背景知识，一般由安全人员辅助开发人员来完成。
3、源码合规检查
源代码合规检查指利用自动化静态分析工具发现代码中不符合安全编程规范的内容，目前国际上比较主流的安全编程标准包括CERT C/C++/Java、MISRA C/C++等。软件开发企业应该根据主管部门监管要求和自身的开发现状，总结归纳符合自身特点的企业安全编程规范，并采用合适的工具，通过规则定制，实现自动化检查。
4、源码溯源检测
源码溯源检测是面向复杂的供应链现状提出的，主要是基于开源代码库，自动化地检测软件中是否引用了开源代码模块，引用的开源代码模块是否存在已知的安全漏洞，以及软件使用授权（License）问题。DevSecOps等开发方法中对开源软件和供应链安全的关注度较高，而源码溯源检测可以在很大程度上规避和降低开源代码引入的法律和安全风险。完善的开源代码库是溯源检测的基础。
5、开发流程对接
与开发流程对接主要是指，源码分析工具应当以最小代价透明地融入开发和测试流程中。如今开发流程越来越规范，为了方便版本控制，许多企业在开发时都使用代码管理系统，如SVN、Git等，而开发人员均使用自己习惯的IDE。因此，良好的对接应该是源码分析工具可以以插件的方式嵌入主流的IDE中，实现一键式启动；并且分析工具支持从代码管理系统中自动获取代码进行检测，检测结果可与Bugzilla等Bug管理系统进行整合。
6、结果可视展现
可视化的结果呈现、方便的验证操作和统计数据对比等都是提高源码安全保障效率的有效手段。具体而言，可视化的分析结果应当包括：缺陷密度、缺陷分布、不同版本的检测结果对比、缺陷触发路径的图形化展示等内容。这些结果对于快速地定位和修复源码安全问题提供方便。
上述6项内容符合内建安全的理念，也能够满足SDL、DevSecOps等方法对上线前软件安全保障的要求，同时也符合安全融入DevSecOps时所应遵循的“自动”和“透明”原则，是非常优秀的源码安全保障实践，可以作为企业构建自身内建安全开发体系时的参考。
（本文作者：360企业安全集团代码安全事业部副总经理 韩建）