我的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%的和谐相处，但是当一个组织把安全作为一个关键的优先事项，并赋予团队正确的知识和工具以成功时，他们的关系可以得到极大的改善，特别是开发者。归根结底，一个全公司范围的、积极的安全文化是否是一个优先事项，如果我们要与（目前的）常见漏洞作斗争，就绝对应该如此。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
开发人员在他们的自然环境中经常被发现处于高度集中的状态，在紧迫的期限内编码令人敬畏的功能。功能建设往往是我们工作中最喜欢的部分，实际上，它是软件开发生命周期（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%的和谐相处，但是当一个组织把安全作为一个关键的优先事项，并赋予团队正确的知识和工具以成功时，他们的关系可以得到极大的改善，特别是开发者。归根结底，一个全公司范围的、积极的安全文化是否是一个优先事项，如果我们要与（目前的）常见漏洞作斗争，就绝对应该如此。
开发人员在他们的自然环境中经常被发现处于高度集中的状态，在紧迫的期限内编码令人敬畏的功能。功能建设往往是我们工作中最喜欢的部分，实际上，它是软件开发生命周期（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%的和谐相处，但是当一个组织把安全作为一个关键的优先事项，并赋予团队正确的知识和工具以成功时，他们的关系可以得到极大的改善，特别是开发者。归根结底，一个全公司范围的、积极的安全文化是否是一个优先事项，如果我们要与（目前的）常见漏洞作斗争，就绝对应该如此。
点击下面的链接，下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
开发人员在他们的自然环境中经常被发现处于高度集中的状态，在紧迫的期限内编码令人敬畏的功能。功能建设往往是我们工作中最喜欢的部分，实际上，它是软件开发生命周期（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%的和谐相处，但是当一个组织把安全作为一个关键的优先事项，并赋予团队正确的知识和工具以成功时，他们的关系可以得到极大的改善，特别是开发者。归根结底，一个全公司范围的、积极的安全文化是否是一个优先事项，如果我们要与（目前的）常见漏洞作斗争，就绝对应该如此。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载资源
OpenText 应用程序安全性的强大功能 + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
