下载掌阅APP，畅读海量书库
立即打开
威胁建模相当于一剂预防针，其实更像是心理学上判断个体特性的量表，它站在攻击方的角度对开发组织或数字化业务要素进行攻击。通过在需求分析和架构设计阶段的威胁建模分析，我们能够有效地排查数字化业务的潜在威胁，通过识别结构化缺陷，减少漏洞发现成本。此外，威胁建模有助于推动安全工具的集成和落地实践。
但是，威胁建模还存在一些难点。
威胁建模的通用步骤为：标识资源、创建总体体系结构、分解应用程序、识别威胁、记录威胁、评估威胁。其中，一些步骤仍然是需要人工干预的；一些步骤，例如识别威胁，可以通过构建威胁共享平台，实现威胁共享自动化，以便尽快识别威胁并做出相应的反应。此外，某些领域的威胁建模方式仍然陈旧，往往基于简单的问卷、表格形式手工建模，不仅非常耗时且容易出错。尽管市面上提供了一些威胁建模工具，但大多依赖类似数据流图的方式进行分析，而获取数据流图本身就是一件不容易的事。
威胁建模往往是由专业的安全人员来实施的，数字化业务通常是由开发人员设计实现的，所以在沟通中可能会存在一定的偏差。况且，传统思维下安全人员与开发人员从某种程度上来说是对立的。安全人员识别到的威胁可能会引起大量的代码改动，甚至改变原本的代码结构，这给开发人员带来巨大的工作量，导致开发人员产生不满情绪。
安全人员与开发人员很难做到充分沟通是威胁建模工作落地难的一部分原因。此外，为了缓解某个威胁不仅可能会给开发人员带来额外的工作量，而且可能产生额外的成本。若提高软件的安全性并不能给用户带来好的体验感，那么安全也不会成为卖点，最终导致企业不想在安全方面投入与业务增长相匹配的建设成本。
随着业务功能的暴增以及越来越多的业务运营转向数字化，威胁随之增多，仅解决所有高优先级威胁变得非常耗时，更耗费大量的人力和物力。何况一个大型企业可能有数百个应用系统，安全人员对每个应用都实施威胁建模也是不现实的。
威胁建模的应用场景是非常广泛的，例如互联网应用、物联网应用以及车联网应用等。由于不同场景涉及不同的知识库，尽管威胁建模自提出至今已经有30年，但经验分享或模型迁移仍然较为困难。
开源组件因其多样性、可评估性受到广泛关注。使用开源组件能够大大提升企业开发效率，节约成本。一个企业甚至可以完全依靠开源组件搭建整个生产体系。但是正如前面指出的那样，开源从一开始就是一把双刃剑，开源组件为企业提供便利的同时也可能因为潜在的安全漏洞给开发安全带来致命的一击。2021年Sonatype发布的《2021年软件供应链状况报告》显示，越热门的项目越容易受到攻击，而且存在开发者安全能力不足的现象。实际上，这和开源社区的自由化有关：开源项目并没有一个系统的安全审查机制，仅仅是依靠开发者、维护者和用户的主动性进行优化、更新。开源组件已经成为软件产品重要的组成部分，因而开源威胁治理实际是软件安全治理。
在传统的软件安全开发周期中，对于企业和用户而言，开源威胁治理主要存在以下难点。
大部分软件开发者在引入第三方库的时候，会直接从开源库中下载或复用之前使用过的开源组件，并没有关注引入的组件是否存在安全隐患或者缺陷，尤其是一些著名的开源工程，完全不去做安全校验。企业如果使用了未安装最新补丁的开源组件，就可能出现漏洞被攻击者利用的安全事件，产生巨大损失。
新思科技发布的《2021年开源安全和风险分析》（OSSRA）报告显示，当前开源软件的许可证存有以下几个问题：1）2021年经审计的代码库中，90%以上开源软件存在许可证冲突、自定义许可证或根本没有许可证的问题；2）2020年审计的代码库中，65%的开源软件存在许可证冲突问题，26%的开源软件存在没有许可证或自定义许可证的问题。由此得知，目前在使用开源软件时可能会存在合规性和兼容性风险，需要进行评估，以免产生知识产权纠纷。
开源软件出现漏洞时开发者无法快速定位，原因：一方面是软件开发过程中某第三方库组件可能引用了其他第三方库组件及其依赖库，从而形成层层嵌套或关联的链式结构，导致开发者需要层层查找组件的受影响范围；另一方面是漏洞修复响应慢，常见的开源许可证包含贡献者对代码缺陷的免责条款，所以漏洞修复通常需要很长时间。
漏洞是造成软件产品安全隐患的问题之一。传统的软件开发通常只关注用户需求、软件功能如何实现以及软件功能是否实现，而软件安全工作通常是产品上线前进行漏洞扫描或是安全问题出现后被动地进行漏洞修复工作。这些操作存在一定弊端：修复补丁的安全性未知，在修复漏洞的同时补丁程序有可能携带其他恶意程序，引发其他安全问题；企业在软件开发中会使用大量第三方组件，而这些第三方组件安全性未知，就可能存在安全漏洞，对使用了第三方组件的产品进行安全扫描，定位并修复漏洞的工作量巨大；据Forrester的调研统计，越是在软件开发早期发现并修复漏洞，成本越低，如图2-10所示。
图2-10 不同阶段的修复成本
SDL体系是将安全前置，从需求开始将安全内建到软件开发流程中，覆盖软件开发的各个阶段，以降低软件产品安全风险，减少后期维护成本。SDL体系的安全活动主要覆盖软件开发过程的各个阶段，最小化每个阶段引入的错误数，进而最小化最终软件产品漏洞数量，确保软件产品安全。
基本的漏洞闭环管理过程包括漏洞发现、漏洞评估、漏洞修补、修补评估环节。如图2-11所示，首先是通过漏洞威胁情报和扫描结果实现漏洞的披露，结合漏洞热度及业务系统重要性等进行漏洞评估，输出漏洞完整信息，包括优先级、严重程度、漏洞位置等，然后派发漏洞修复任务，及时确认漏洞修复负责人，最终进行漏洞修复，实现漏洞闭环管理。
图2-11 基本的漏洞闭环管理流程
理论上，我们发现了漏洞，分析漏洞产生原因，追溯并锁定代码位置，就可以对该漏洞进行修复。但实际上随着网络环境越来越复杂，披露的漏洞数量逐年递增，漏洞类型越来越多样化，修复的方法和周期也不一样，想要修复所有的漏洞并按计划执行几乎是不可能的。漏洞管控依旧面临着巨大挑战。
目前，许多企业对于漏洞的管理是先部署漏洞扫描设备，根据扫描结果，再采取相应的漏洞缓解措施。这种识别出漏洞就进行修复的方式，缺乏风险优先级排序过程，不能有效地排除风险，而且持续不断地漏洞修复优先级协商工作会导致大量的时间和资源浪费，甚至造成更大风险。需要注意的是，并不是漏洞等级越高其优先级就越高，我们所强调的是风险的优先级，找到需要优先处置的风险，从而显著降低风险。
此外，SDL流程中安全防范措施大多是独立存在的，如漏洞扫描系统、防火墙等防护措施都给软件产品带来一定的安全保障，但这些安全防线仅能抵御来自某个方面的威胁，若部署的安全测试工具很多，则需要处理的警报信息就很多，可能会出现无法协同的问题，造成工具使用和漏洞管理不便。
此外，漏洞管控的终点不仅仅是推进漏洞修复，更重要的是在漏洞修复后对漏洞成因进行分析，以不断优化整个SDL流程。
正如前文所述，早期的SDL是基于传统的瀑布式开发发展出的一种安全模型。由于传统的瀑布式开发的开发和发布周期都比较长，安全团队有足够的时间将安全活动提前引入，进行有效的安全管控。然而，现阶段越来越多的企业为了提高开发效率、提高软件产品的交付速度，逐渐从传统瀑布式开发转型为敏捷开发。
具体来说，敏捷开发具有开发和发布周期短、版本迭代快等特点。如果在敏捷开发中仍选择SDL进行安全管理，显然没有足够的时间让相关安全活动提前介入，同时一些安全活动的介入在时间要求上不免要和敏捷开发流程冲突，例如传统的安全评审、白盒安全测试等。2010年，微软引入了一种全新的、旨在将敏捷开发引入Visual Studio IDE的模板，以拓展SDL的使用范围。
即便如此，SDL中有相当多的安全活动依赖人工操作，例如开发阶段制定安全编码要求、验证阶段基于测试用例进行人工渗透测试、发布和部署阶段通过人工修复漏洞等。而以人工为主、工具为辅的安全不免要游离于开发流程之外。
当SDL以“应急和审查”的形式挂载在软件开发流程之外，但缺乏自动化、无感知的工具支撑时，业务安全和业务价值的快速交付无法兼顾。例如，如何安全且自动化、快速地完成编码、测试和发布继而交付，都是敏捷开发过程中SDL安全实践亟待解决的问题。因此，在解决上述问题前，传统的SDL介入敏捷开发流程只会影响敏捷开发的灵活性，使敏捷开发不再敏捷。