我的entester，我的敌人？开发人员透露他们对entesting和静态分析结果的真实想法

开发人员在他们的自然环境中经常被发现处于高度集中的状态，在紧迫的期限内编码令人敬畏的功能。功能建设往往是我们工作中最喜欢的部分，实际上，它是软件开发生命周期（SDLC）的基本成果。

然而，正如我们之前所讨论的，我们中的许多人仍然把功能放在优先于安全最佳实践的位置。毕竟，在大多数组织中，它被设定为别人的工作，而对我们的充分安全培训是有限的。渗透测试和静态分析扫描工具（更好地称为SAST）只是减轻安全风险的整个过程的一部分，与我们的工作相当独立地运作......当然，直到代码反弹到我们这里来进行热修复。

而就在那一刻，许多开发者认为："五角大楼的人恨我吗？"。

这些互动往往定义了一个团队，一种文化。令人担忧的是，缺乏沟通、理解和整体协作造成了紧张，至少在开发者一方。想一想吧。想象一下，你花了几百个小时雕刻了一个了不起的雕像，然后有人拿着锤子走过来，在告诉你它的基础没有达到要求后开始砸碎它。这就是测试人员和开发人员之间的感知动态--后者的软件宝贝被一个没有和他们一起努力完成这个过程的局外人屠杀了；相反，他们延长了工作量，推迟了代码交付的满意度。

我很久以前就进入了安全领域，我可以看到故事的两面性。不，entesters并不讨厌开发者。五级测试员很可能是工作过度，压力很大。因此，源源不断的普通安全漏洞可以很容易地在代码层面上修复，这占用了时间、资源和头脑，而不是真正严重的问题。

我一直认为五位导师有点像父母。他们希望你做得好，而当你做得不好时......他们并不生气，只是感到失望。

既然我已经在你的脑海中留下了这个（也许有点不公平）的印象，让我们再深入地探讨一下。是什么造成了开发者之间的这种世界观？

"我当然会有抵触情绪；他们在告诉我如何做我的工作！"

没有人喜欢感觉他们做得不好，或者有人不喜欢他们的工作。可悲的是，对于开发者来说，当静态分析和五次测试的结果反馈给他们时，他们会感觉像一张成绩单。他们被打了低分，但在一天结束时，他们的老板是根据他们建立的功能和他们交付的时间来评估他们的，而不是软件中是否有脆弱的元素。

对于可怜的五级测试员来说，这是一个 "不要向信使开枪 "的案例。这不是针对个人的--他们的任务是发现bug，而且他们发现了这些bug。当然，在人与人之间的层面上，也许有些测试人员比其他人更暴躁，但他们不是（或不应该是）来钉死开发团队的。如果这两个团队在安全最佳实践方面有相同的看法，那就会容易得多。而且，人们并不期望开发人员是完美的；现实中，测试团队的存在是为了保护他们不发送有漏洞的代码。

"他们让我解决所有这些小问题，难道他们不知道有更高的优先级吗？如果他们这么关心，为什么不帮我解决这些问题？"

这是真的--开发人员最优先考虑的永远是功能的构建，在这个疯狂的快速数字化的世界里，它必须以速度完成。虽然有些编码员对安全和安全编码有个人兴趣，但普遍的看法是，安全是 "别人的问题"，这不可避免地包括五角大楼。

大多数常见的漏洞确实是需要补救的小问题--一旦知道，对于跨站脚本（XSS）和SQL注入等问题，修复措施很容易执行......问题是，许多开发人员没有意识到他们首先引入了这些问题，而这些看似微小的问题是攻击者为公司造成破坏性问题所需的小机会窗口。根据Akamai的数据，在2017年11月至2019年3月期间，SQL注入漏洞占所有基于网络的攻击载体的65%。对于一个已经有二十多年已知修复方法的漏洞来说，这是一个令人清醒的统计数字。

一些entest团队确实协助修复安全漏洞，但其他团队会提供一份坏消息的报告，并期望开发人员通过热修复工作，即使他们在发生这种情况时已经转移到另一个项目。在某些情况下，开发团队可能会面临一份包括他们不能（或不应该被期望）修复的错误的报告--它仍然必须是调查结果的一部分，而且同样地，不要把它当作个人问题。

这方面的 "幸福媒介 "是五角大楼、安全人员和开发经理更多地扮演导师的角色，以确保团队在有效的培训和工具方面有他们需要的东西，给个人编码者最好的机会，以便从SDLC的一开始就成功和安全地编码。这两个团队确实应该在半路相遇，以确保从一开始就考虑安全问题，作为健康的DevSecOps实践的一部分。

"我的安全知识比我得到的荣誉要好得多；这些报告大多是假阳性，或者不重要"。

静态分析是SDLC中安全流程的一个要素，静态分析扫描工具（SAST）发挥着基本作用。是的，假阳性是这些和其他类型（DAST/IAST/RAST）的扫描器的问题。这是一个已经很慢的过程中的一个烦恼，需要手动审查代码，给开发人员和五角大楼的人都带来了压力。测试人员已经花时间精心设置了自定义规则，以避免不准确的读数，并提供了公司特定的指导，但一些错误的读数还是溜走了，并最终出现在让人挠头的开发人员面前。

这个过程并不完美，但另一个问题是，许多开发人员缺乏足够的知识来持续地缓解许多常见的漏洞。由于安全培训在高等教育中很少见，而在职培训的效果也各不相同，因此有理由认为可能也存在一些过度自信的情况（这不是他们的错--我们作为一个行业需要更好地装备他们所需要的）。

"我不知道这个应用程序将被测试，但现在我被补救任务缠住了"。

有时，工作过度的工程师们会认为五级测试员只是挂在一旁，等待时机，通过测试一个应用程序来打击开发团队的工作。他们过度测试，他们吹毛求疵，他们在创造额外的工作。

唯一的问题是，他们也是工作过度（事实上更甚--网络安全技能的短缺已经到了可怕的程度，而且越来越严重），根本没有时间无缘无故地进行测试。他们并不是确定测试优先级的唯一决策者；它可能是由高级领导层、客户要求的，作为安全审计的一部分，甚至是作为漏洞赏金计划的结果而确定的。

对于开发者来说，被从当前的功能建设冲刺中拉出来从事安全修复工作是很烦人的--尤其是当这不是他们的工作时。也许上一个团队做了最后的更新，或者是另一个供应商。然而，安全是每个人的问题。这并不意味着每个开发人员都要承担安全漏洞的所有权，好像这些漏洞都是他们自己造成的，但他们确实需要加入到安全是一种共同责任的行列中来。

从这里到哪里去？

有时，一个心态的转变就能在解决问题上取得重大进展。我们已经谈到了开发人员对不太理想的测试结果的冷淡反应，但如果他们能把它变成一种挑战呢？也许他们可以把测试员看作是一个友好的竞争者；一个他们可以在自己的游戏中打败的人。毕竟，一个有安全意识的开发者如果能在写代码时消除常见的bug，会使他们的工作更加困难。相比之下，一个不注重安全的开发者会被他们的五角大楼的同行们全面击败，因为他们可以轻易地破坏他们的软件。

Pentesters和开发者可能不是100%的和谐相处，但是当一个组织把安全作为一个关键的优先事项，并赋予团队正确的知识和工具以成功时，他们的关系可以得到极大的改善，特别是开发者。归根结底，一个全公司范围的、积极的安全文化是否是一个优先事项，如果我们要与（目前的）常见漏洞作斗争，就绝对应该如此。