如果应用安全工具是万能良药，为什么这么多公司却迟迟不愿使用？

本文的一个版本曾发表于《SC Magazine》。本文经更新后在此转载。

‍

当今安全专家面临的众多难题之一，是如何平衡各种解决方案以应对网络风险。预算应如何在工具和人员之间分配？什么样的工具套件最适合现有的技术栈？面对如此多的选择，并没有简单的答案，而一旦选错，后续将付出高昂的时间和金钱代价。

一份最新报告显示，应用安全工具市场预计在未来几年至2025年间将实现“爆发式”增长，这有力地证明了它们在成功的DevSecOps实践中不可替代的作用，也反映出在代码量激增且潜藏安全漏洞的情况下，这些工具在行业内的重要性日益凸显。

然而，存在一个颇为令人费解的问题。近半数的组织明知代码存在漏洞仍将其发布，尽管他们使用了旨在阻止此类情况的一系列应用安全工具。对于市场需求明确且发展迅速的产品来说，这实在令人费解。为什么这么多企业购买了先进的安全工具，却对其检测结果视而不见，甚至根本不用？这就像买了海景房，却非要睡在树林里的帐篷里一样。

应用安全工具未能达到预期效果的原因有几个，这与其说是因为工具本身的功能问题，不如说是因为它们未能与整个安全计划实现有效整合。

工具越多，并不代表问题越少。

随着企业不断演进其软件开发流程，从敏捷开发到DevOps，再到DevSecOps这一“圣杯”（至少目前看来是最好的方案），在此过程中不可避免地会采购各种扫描器、监控器、防火墙以及各类应用安全工具。虽然看起来似乎是“多多益善”，但这往往会导致技术栈变得像“科学怪人”一样拼凑，并带来随之而来的各种不可预测性。

在预算和专家资源日益受限的情况下，想要理清乱局并找到最佳的工具化路径是一项艰巨的任务，而需要扫描和修复的代码却源源不断。难怪许多组织不得不继续发布代码，尽管这令人担忧，且依然对我们的数据和隐私构成了巨大风险。

扫描工具速度缓慢，这影响了发布的敏捷性。

在软件开发中，实现“安全与速度并重”就像是追逐“白鲸”一样困难。事实上，即使我们正在引导组织采用DevSecOps导向的方法，我们仍在努力实现这一目标。在90年代，细致的手动代码审查或许能作为安全防线，但在如今我们以千亿行计产出代码的时代，这种做法无异于用指甲剪去修剪足球场。

扫描工具通过自动化流程来发现潜在问题，替我们完成了那部分繁琐的代码审查工作。但问题在于，在全速运转的CI/CD流水线中，它们的速度依然太慢，而且没有任何单一工具能发现所有漏洞。此外，扫描后反馈给安全团队的结果还存在几个明显的痛点：

1. 存在大量误报（和漏报）
2. 可怜的安全专家不得不坐在那里进行手动审查，以从虚假漏洞中筛选出真正的Bug
3. 通常，扫描结果会揭示出太多本应在代码部署前就该解决的常见漏洞。你真的希望昂贵的安全专家被这些琐事分散精力，而无法专注于重大的安全问题吗？
4. 扫描器只能发现问题，不能修复问题。

即使是在竭尽全力遵循网络安全最佳实践、并与时俱进地将安全融入流程每个阶段的组织中，如果扫描器是主要的防护手段，且过多的常见Bug阻碍了团队部署安全代码，上述流程依然会成为“拦路虎”。可以推断，在这种情况下，人们可能会选择走捷径，通常表现为仅依赖最基础的工具，而这些工具即便在购买了一整套解决方案的情况下，也无法覆盖所有潜在风险。

某些技术主导的自动化可能会导致代码质量下降

在应用安全工具中，扫描和测试承担了自动化流程的重任，再加上防火墙和监控等基础工具，但其他一些常见工具却可能在不知不觉中逐渐侵蚀掉手动安全的基础。

例如，RASP（运行时应用自我保护）技术通常被用于在不牺牲编码速度的前提下加强安全态势。它在应用程序的运行时环境中运行，防御恶意代码输入和实时攻击，并标记任何异常的执行行为。

这无疑增加了一层额外的保护，但如果将其视为代码库中任何潜在弱点的“万能保险”，开发人员可能会产生懈怠心理，尤其是在面临日益紧迫的上线截止日期以推送新功能时。开发人员可能会不再遵循安全编码实践，认为运行时自我保护机制会检测出任何错误。开发人员并非故意编写不安全的代码，但在假设有自动化保障的情况下，安全往往会被置于功能交付之后。

工具可能会失效（以 RASP 为例，它通常运行在监控模式下以避免误报，但这只能提供可见性，而无法提供针对攻击的保护），一旦失效，唯有高质量的安全代码才是最可靠的保障。DevSecOps 的核心在于让每一个涉及代码的角色都具备安全意识，如果开发人员不接受安全培训或无法编写安全代码，那将是一个严重的失误。编写安全代码与不安全代码所需的工作量并无二致，真正的难点在于掌握安全编码的知识。与其耗费时间去部署和优化 RASP，不如将这些精力投入到提升开发人员的技能上，从源头上杜绝安全隐患。

平衡工具与人员：这虽非万能良药，但却是目前我们所能采取的最佳方案。

DevSecOps 的核心理念是将安全视为共同责任。对于那些开发驱动我们生活软件的组织而言——从电网到智能门铃，无所不包——他们必须让每个人都参与到这一进程中，以确保更高水平的安全性。

工具无法解决所有问题，而且这甚至不是成本最低的方式。事实证明，最好的结果来自于：为所有接触代码的人员提供相关的安全培训，积极让开发团队时刻关注安全，并建立一种以人为本的积极安全文化，让工具套件仅发挥辅助作用。

即便面临时间紧迫、赶工期以及其他让安全专家彻夜难眠的问题，只要开发人员从一开始就不引入常见的安全缺陷，那么这些工具（无论是否使用）所带来的风险因素都会大大降低。

‍