如果 AppSec 工具是灵丹妙药，为什么这么多公司没有解雇它？

这篇文章的一个版本出现在 SC 杂志。它已在此处更新和发布。

‍

当今安全专家面临的众多难题之一是弄清楚他们将用来处理所面临的网络风险的解决方案的平衡。应该如何在工具和人员之间分配预算？哪套工具最适合现有技术堆栈？有这么多的选择，没有简单的答案，选择错误的选项将在以后花费时间和金钱。

最近的一份报告显示，应用程序安全工具市场正在跟踪 从现在起到2025年的 “爆炸性” 增长，这有力地表明他们在成功的 DevSecOps 实践中发挥了无可争议的作用，面对越来越多的具有潜在安全漏洞的代码，行业相关性也越来越高。

但是，有一个有点奇怪的问题。 将近一半的组织故意发布易受攻击的代码， 尽管 使用一系列旨在阻止这种情况的 AppSec 工具。对于具有不可否认的市场需求迅速受到关注的产品来说，这毫无意义。为什么这么多人会购买复杂的安全工具，却忽略了他们的发现或根本不使用它们？这有点像买海滨住宅，却睡在树林里的帐篷里。

AppSec工具没有像我们预期的那样被利用，有几个原因，与其说是工具及其功能，不如说是它们如何与整个安全程序集成。

更多的工具并不等于更少的问题。

随着公司不断发展其软件开发流程，从敏捷到DevOps，再到神圣的天堂DevSecOps（嘿，就目前而言，这是我们目前拥有的最好的工具），在此过程中不可避免地会购买多个扫描器、显示器、防火墙和各种AppSec工具。尽管看起来像是 “越多越好”，但这往往会导致一个类似于弗兰肯斯坦怪兽的技术堆栈，这意味着所有的不可预测性。

由于所需工作范围的预算和专家资源越来越有限，试图消除混乱局面并找到最佳的前进工具路径是一项艰巨的任务，而且需要扫描和修复的代码不断出现。难怪许多组织不得不保留运输代码，尽管这相当令人担忧，而且仍然对我们的数据和隐私构成巨大风险。

扫描工具运行缓慢，这会影响发布灵活性。

在软件开发中，快速实现安全性有点像白鲸，事实是，尽管我们引导组织采用了面向DevSeCops的方法，但我们仍在努力解决这个问题。在90年代，细致的手动代码审查本来可以起到安全保护的作用，但是在我们生成数千亿行代码的时代，该计划与用指甲剪准备足球场一样有效。

扫描工具可以自动发现潜在问题，为我们完成细致的代码审查部分。问题在于，在 CI/CD 管道全力以赴的情况下，它们仍然运行缓慢，而且没有一个工具能发现所有漏洞。扫描后向安全团队透露的结果还有几个明显的问题：

1. 有一个 很多 误报（和阴性）
2. 一些糟糕的安全专家仍然必须坐在那里进行手动审查，从幻影错误中筛选出真正的错误
3. 通常，会暴露出太多的常见漏洞，这些漏洞本应在部署代码之前被发现。你真的想让你的非常昂贵的安全专家从这些小东西的重大而棘手的安全问题上分散注意力吗？
4. 扫描仪发现，它们无法修复。

即使在一个尽最大努力实现网络安全最佳实践，并与时俱进将安全纳入流程的每个阶段的组织中，如果扫描仪是主要的保护措施，并且太多的常见错误使团队在部署安全代码时陷入困境，则上述过程仍然是一个引人注目的焦点。这里可以偷工减料是有道理的，这通常是依赖最低限度的工具，即使购买了一套解决方案，这些工具也不可能涵盖所有潜在风险。

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

扫描和测试承受了 AppSec 工具中的自动化流程以及防火墙和监控等基本要素的负担，但随着时间的推移，其他常用工具可能会无意中侵蚀实际的安全基础。

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

这无疑是一层额外的保护，但如果将其视为防范代码库中任何潜在缺陷的万无一失，开发人员可能会沾沾自喜，尤其是在推出新功能时面临越来越不可能的上市截止日期时。可能不遵循安全编码惯例，前提是运行时自我保护会发现任何错误。开发人员不会竭尽全力创建不安全的编码模式，但是安全性通常会被取消优先级，转而使用功能交付，尤其是在假设自动保护的情况下。

工具可能会出现故障（对于 RASP 而言，通常在监控模式下运行以避免误报，而误报反过来只能提供可见性，而不能提供保护），当这种情况发生时，每次都可以依赖高质量、安全的代码。每个涉及代码的角色的安全意识是 DevSecOps 的基础，开发人员不接受安全代码培训或不生成安全代码是错误的。安全和不安全的代码需要同样的努力来编写；它需要获得安全编码的知识，这需要真正的精力。可以更好地利用实施和优化 RASP 所花费的时间来提高开发人员的技能，以免一开始就犯错误。

平衡工具和人员：这不是灵丹妙药，但它是我们（目前）最接近的灵丹妙药。

DevSecOps的主要理念是使安全成为一项共同的责任，对于正在开发为我们的生活提供动力的软件的组织，从电网到门铃，他们需要让每个人踏上旅程，以确保更高的安全水平。

工具无法完成所有工作，甚至不是最便宜的方式。到目前为止，最好的结果是通过优先为所有接触代码的人提供相关的安全培训，积极努力将安全放在开发团队的首位，以及建立以人为主导的积极安全文化，并使用起辅助作用的工具套件来实现。

即使面对时间限制、偷工减料和其他让安全专家无法入睡的事情，如果开发人员一开始不引入常见的安全缺陷，那么这些工具（以及是否使用它们）所代表的风险因素要小得多。

‍