渗透测试人员是我的敌人吗？开发人员揭示他们对渗透测试和静态分析结果的真实看法

开发人员在专注工作时，往往处于一种心流状态，忙于在紧迫的期限内编写出色的功能。构建功能通常是我们工作中最为享受的部分，实际上，这也是软件开发生命周期（SDLC）的核心成果。

然而，正如我们之前讨论过的，许多人仍然将功能优先级置于安全最佳实践之上。毕竟，在大多数组织中，安全工作被视为“别人的事”，而我们所能获得的充分安全培训也十分有限。渗透测试和静态分析扫描工具（即 SAST）只是降低安全风险整体流程的一部分，它们与我们的日常工作相对独立……当然，除非代码被打回要求进行热修复时除外。

就在那一刻，许多开发人员会想：“渗透测试人员是不是讨厌我？”

这些互动往往定义了一个团队和一种文化。令人担忧的是，缺乏沟通、理解和整体协作已经造成了紧张关系，至少在开发人员这一方是如此。试想一下：你花了数百个小时雕刻出一座精美的雕像，然后有人拿着锤子走过来，在告诉你地基不牢固后，就开始砸掉它的一部分。这就是测试人员与开发人员之间感知的动态关系——后者心血结晶的软件被一个没有参与整个劳动过程的局外人“屠杀”了；不仅如此，他们还增加了工作量，推迟了交付代码的成就感。

我很久以前就进入了安全领域，因此我能理解双方的立场。不，渗透测试人员并不会讨厌开发人员。渗透测试人员很可能也是超负荷工作，承受着巨大的压力。因此，源源不断出现的常见安全漏洞（本可以在代码层面轻松修复）占用了他们大量的时间、资源和精力，使他们无法专注于真正严重的问题。

我一直觉得渗透测试人员就像父母。他们希望你做得好，而当你没做到时……他们不是生气，只是感到失望。

既然我已经让你脑海中有了这个（或许有些不公平的）形象，让我们深入探讨一下。是什么导致了开发人员产生这种世界观？

“我当然会进行防御，因为他们在教我怎么做事！”

没人喜欢感觉自己工作做得不好，或者别人不喜欢自己的作品。对开发人员来说，不幸的是，当静态分析和渗透测试结果反馈给他们时，这感觉就像是一张成绩单。他们拿到了低分，但归根结底，他们的老板考核的是他们构建的功能以及交付的时间，而不是软件中是否存在漏洞。

对于可怜的渗透测试人员来说，这属于“别迁怒于信使”。这并非针对个人——他们的任务就是发现漏洞，而他们确实发现了。诚然，在人际层面，也许有些渗透测试人员脾气比较暴躁，但他们并不是（也不应该）为了刁难开发团队。如果双方在什么是安全最佳实践上达成共识，对彼此都会轻松得多。而且，没人要求开发人员做到完美；实际上，测试团队的存在是为了保护他们，避免发布存在漏洞的代码。

“他们让我修复所有这些小问题，难道不知道还有更重要的优先级吗？如果他们真的那么关心，为什么不帮我一起修复？”

确实如此——开发人员的首要任务永远是构建功能，在这个数字化飞速发展的疯狂世界里，必须保持高速交付。虽然一些程序员对安全和安全编码有个人兴趣，但普遍的看法是安全是“别人的问题”，这不可避免地包括了渗透测试人员。

大多数常见的漏洞确实是容易修复的小问题——一旦发现，像跨站脚本（XSS）和 SQL 注入这类问题的修复方法都很简单……问题在于，许多开发人员根本没有意识到他们从一开始就引入了这些漏洞，而这些看似微小的问题，正是攻击者造成公司毁灭性打击所需的突破口。根据 Akamai 的数据，在 2017 年 11 月至 2019 年 3 月期间，SQL 注入漏洞占所有基于 Web 攻击向量的 65%。对于一个已经有二十多年已知修复方案的漏洞来说，这是一个令人警醒的统计数据。

一些渗透测试团队确实会协助修复安全漏洞，但另一些团队只会提供一份坏消息报告，并期望开发人员处理热修复，即使此时他们可能已经转到了另一个项目。在某些情况下，开发团队可能会面对一份包含他们无法（或不应被要求）修复的漏洞报告——但这仍然必须作为发现结果的一部分，同样，不要将其视为针对个人。

实现这一目标的“折中方案”是让渗透测试人员、安全人员和开发经理更多地扮演导师角色，确保团队拥有有效的培训和工具，让每位程序员从 SDLC 的最开始就有最好的机会成功编写安全代码。双方确实应该各退一步，确保从一开始就考虑到安全性，将其作为健康 DevSecOps 实践的一部分。

“我的安全知识比他们认为的要好得多；这些报告大多是误报，或者根本不重要。”

静态分析是 SDLC 安全流程的一个要素，静态分析扫描工具（SAST）发挥着基础性作用。是的，误报确实是这些扫描工具以及其他类型（DAST/IAST/RAST）扫描器的一个问题。这在原本就缓慢的流程中令人烦恼，需要人工代码审查，给开发人员和渗透测试人员都带来了压力。渗透测试人员已经花费时间精心设置了自定义规则以避免不准确的读数，并提供了针对公司的指导，但仍有一些错误读数漏网，出现在困惑的开发人员面前。

这个流程并不完美，但另一个问题是，许多开发人员缺乏足够的知识来持续缓解常见的漏洞。由于高等教育中很少提供安全培训，且在职培训的效果参差不齐，因此可以推断，这其中可能也存在过度自信的因素（这并非他们的错——我们整个行业需要更好地为他们提供所需的装备）。

“我不知道这个应用程序会被测试，但现在我却被这些修复任务缠住了。”

有时，过度劳累的工程师会认为渗透测试人员只是在幕后伺机而动，等待时机去测试应用程序，给开发团队泼冷水。他们认为测试人员是在过度测试、吹毛求疵，是在制造额外的工作量。

唯一的问题是，他们自己也同样不堪重负（事实上情况更糟——网络安全人才短缺已达到严峻程度且日益恶化），根本没有时间进行无谓的测试。他们并非决定测试优先级的唯一决策者；测试请求可能来自高层领导、客户、安全审计要求，甚至是漏洞赏金计划的结果。

对于开发人员来说，被从当前的功能开发冲刺中抽调出来去处理安全修复是很烦人的——尤其是如果这些问题并非他们自己造成的话。也许是之前的团队或供应商进行了上一次更新。然而，安全是每个人的问题。这并不意味着每个开发人员都必须像对待自己造成的错误一样去承担所有安全漏洞，但他们确实需要参与进来，将安全视为共同的责任。

接下来该怎么做？

有时，思维方式的转变足以在解决问题上取得重大进展。我们讨论过开发人员对不理想的渗透测试结果所表现出的冷淡反应，但如果他们能将其视为一种挑战呢？也许他们可以将渗透测试人员视为友好的竞争对手；一个他们可以在其擅长的领域中击败的人。毕竟，一个具备安全意识、能在编写代码时消除常见漏洞的开发人员，会让渗透测试人员的工作变得更加困难。相比之下，一个不关注安全的开发人员，在软件被轻易攻破时，会被渗透测试人员全面碾压。

渗透测试人员和开发人员可能无法始终保持和谐，但当组织将安全视为关键优先事项，并为团队（尤其是开发人员）提供成功所需的知识和工具时，他们的关系可以得到极大改善。归根结底，这取决于公司是否将积极的安全文化作为优先事项；如果我们想要扭转目前在对抗常见漏洞方面的劣势，这绝对应该成为重中之重。