为何DevSecOps落地如此艰难？

什么是DevSecOps

DevSecOps是为了让安全能够融入现代应用开发和部署的快节奏周期，而进行的一种文化的改变。DevSecOps意味着开发中的安全左移，从而需要缩减开发团队和安全团队之间的距离，使得开发团队自身可以通过自动化的方式处理大量的安全工作。

传统的软件开发流程中，大部分开发者都需要数月，甚至数年才会发布新版本的应用。这就有了大量的时间，让不同的内部和外部团队，对代码进行质量检测和安全测试，但是，随着过去十年中，公有云、容器和微服务模型的发展，单一的应用被分解成不同的小组件，独立运作。这对软件开发的方式带来了直接的冲击，形成了滚动发布和敏捷化的开发模式。在这一模式下，新的功能和代码会持续地快速被投入使用。许多此类流程通过新的技术和工具自动化实现，让企业能更高速地进行创新，从而在竞争中获得领先。

云、容器和微服务同样产生了DevOps文化。开发者可以自己解决对于架构的需求，而不需要另一个分离的架构团队来帮他们实现。现在所有的主流云供应商都提供相关的API和配置工具，帮助客户能够通过预设的模板，用代码对架构进行配置。

尽管说DevOps文化给软件开发带来了很多创新因素，但是安全却无法跟上代码的迭代速度。DevSecOps则应运而生，试图解决这个问题，并将安全测试完全结合进持续集成（continuous integration, CI）与持续交付（continuous delivery, CD）流水线中，同时将相关的知识和技能嵌入开发团队，从而开发团队可以内部解决安全隐患。

DevSecOps的三个关键要点在于：

• 开发团队自己完成安全测试
• 测试中发现的问题由开发团队进行管理
• 开发团队完成修复工作

应用安全测试公司Veracode的联合创始人兼CTO，Chris Wysopal表示：“第三个要点会需要一些时间才能实现，但是我认为那才是应用安全真正成为DevSecOps的时候。那样就不需要另一个不同的团队去处理安全相关的问题。”

实现真正的安全+开发

在Wysopal看来，第三点的实现难点在于开发者必须在不需要外部帮助的情况下，有修复安全漏洞的能力，而做到这一点需要不少时间。许多团队通过在开发组中加入一名安全领袖来实现这一点。这个人员往往在应用安全方面有相当多的经验，并且相比团队其他成员受到更多的相关训练。这个人能够检查相关的安全修复，并确保他们被正确应用。

不过，这不意味着这位安全领袖不能从团队外部获取专家意见。他们依然可以从公司的应用安全测试服务的供应商处获得咨询服务。但这应该是特殊情况，而不能成为常态。安全领袖模式不同于安全团队成员分散在不同开发小组的模式。

DevOps自动化与开源管理公司Sonatype的CTO，Brian Fox则认为，开发和安全的集成也需要从管理层面着手。在他看来，如果安全无法自上而下地完全集成进开发流程中，就无法达到预期的效；即使同一团队的人也会产生管理层面的目标分歧——有时候尽管两个人并未有冲突产生，但是他们也相互无视对方，并没有进行合作。

同样的问题也曾发生质量检测（Quality Assurance, QA）中。之前会有一名QA经理和一名工程师经理，理论上他们应该一同合作，但事实上两者之间总会会有派系斗争。Fox提到，一当QA成为开发团队工作的一环的时候，就会发现精神上的敌对关系消失了；而同样的问题依然出现在安全上，而这需要很多的努力才能去改变。

DevSecOps测试与相关工具

硅谷的科技公司属于早期就开始采用DevSecOps方法的，但是当时的安全测试工具并不适合开发者使用。开发者希望用一些能够自动化使用的命令行工具，这样他们能够轻松地修改不同的设置，并且能将获得的结果输入到漏洞追踪器中。而在传统的安全团队和CISO的理念中，安全的目标是治理、合规和风险管理。

之后逐渐有新的工具开始出现。这些工具都是由开发者自己编写给其他开发者的，并且集成到了开发环境以及CI/CD工作流中。一些工具是开源的，其他则是由一些初创公司基于这些开源工具进一步改造的。尽管这些工具确实解决了开发者的需求，但是它们却不再真正意义上解决CISO的需求了。

但是Wysopal又提到，虽然对于开发团队而言，使用大量不同的开源工具会让他们觉得他们覆盖了所有自己的需要面；但从企业治理的角度来看，过多零碎的工具反而会让安全团队难以根据公司的策略进行管理。

在过去的数年中，传统的应用安全厂商开始改造他们的产品以解决以下两个场景需求：提供CISO需要的分析和报告，同时也提供开发者所需要的灵活些和易用性。一些如GitHub的针对开发者的云服务供应商已经开始将安全测试直接加入他们的服务之中；如果这些安全测试服务不时原生的功能，它们也会以第三方集成的形式在可购买的服务项目中出现。

Fox表示，在他的整个职业生涯中，总是能看到一些反复的规律：用户总有两个倾向——一种是需要一个供应商提供完整的工具组，另一种则更愿意自己将不同的工具集成到一起。而在过去两年中，他认为用户更倾向于用统一完整的工具组。

Fox同时也提醒，这种需求可能会在某个时间点逆转——比如在下一个开创性的技术出现的时候，而企业也需要为此做好准备。一个完整的工具组的问题在于，工具组可能有一些组织需求之外的功能；这些功能往往不是因为对企业更有效而存在的，仅仅是因为它们是免费的。在一定时间后，随着开发者对工具的使用，他们自己会采用更适合自己工作需求的工具，而非企业认可的工具组。

从治理的角度来看，不受管理的团队必然有负面影响；但是企业必须意识到在未来的一两年中，这些事情将会无法避免地发生，即使试图限制工具的使用，还是会有一些开发者会我行我素。

Fox补充认为，早期的云使用者很多是很不情愿使用云服务的大组织中，存在的一些小团队。因此，如果组织能够意识到这是不可避免会发生的事情，并不对相关团队限制过多，可能反而有机会发现一些开创性的前沿技术，甚至能真的替换现有的技术。

DevSecOps实践

根据Wysopal的说法，越来越多的企业将自动安全扫描集成为CI/CD流水线的一部分，但是效果并不能立竿见影。Wysopal认为这是所谓的“安全债务”，因为之前开发者选择不修复的漏洞数目角度造成的。“安全债务”产生的原因很多，包括没有立即修复发现的漏洞；也可能决定不修复，而使用其他方式缓解；还可能因为威胁级别较低而不选择修复。在Veracode自己的2019年软件安全报告趋势当中提到，在基于过去一年对85,000个应用进行扫描获得的数据中发现，平均修复应用中发现的漏洞时间为171天，而在十年前第一份报告出现的时候才59天。但是，产生这个区别的原因是因为之前囤积了大量没有修复的漏洞，而修复时间的中位数依然很相近。

当将某个应用的扫描结果和扫描频率相关联以后可以发现，增加在CI/CD流水线上集成的自动化扫描频率，能够更快修复漏洞：每天被扫描的应用修复漏洞的时间中位数为19天，而每月扫描则为68天。

而从经济的角度来说，如果需要从安全债务中减少损失，就需要改变一些开发习惯；而DevOps和DevSecOps的实践过程，也确实地使原有的文化发生了变化。

DevSecOps文化的另一个利好，是在代码中存在的严重漏洞数量也会大幅度减少。Veracode的数据显示，没有漏洞的应用比例相比十年前降低了，这似乎看上去比之前更糟糕了；但从另一组数据中则能发现，没有高危漏洞的应用比例则从66%上升到了80%。

不过，即使DevSecOps的模式存在，依然有很多工作需要安全人员来处理，而且仍然很依赖人工测试——尤其是对于逻辑漏洞以及设计缺陷等无法通过纯自动扫描解决的问题。Wysopal表示，人工测试已经逐渐不再是一年，甚至两年一次的行为。人工测试需要反复进行，最好能作为DevOps流程的一部分，在为期两周的项目阶段中，针对新出的功能进行人工测试。如果开发团队对人工测试有了足够的了解，那就可以由安全领袖进行，并且真正满足开发团队自己的需求。

来源：数世咨询