建立信任。应用安全与开发者之间的真正安全协同之路
这篇文章的一个版本出现在 网络防御杂志.它已被更新并在此转发。
一个建立在不信任的基础上的关系，最好是以低期望值来对待。可悲的是，这可能是一个组织内的开发人员和AppSec团队之间的工作关系状况。一般来说，这种情况是不理想的，而且在一个对技术有高风险依赖的世界里会导致糟糕的结果。
开发人员在解决问题、构建功能以及在他们的工作中展示创造力方面很有优势。另一方面，AppSec有一个令人羡慕的任务，那就是在他们的代码中发现安全漏洞，将其退回修复，并提供审计和报告，破坏了工程师的宠物项目的光泽。把责任完全推给开发人员是不公平的--安全不是他们的优先事项，也不是他们KPI的一部分--也不能因为过度劳累的AppSec团队只是做他们的工作而受到惩罚。然而，为了网络安全的最佳实践，以及组织层面更好的安全成果，他们真的需要开始友好相处。
而这一切都从信任开始。
AppSec的 "坏人 "形象阻碍了DevSecOps的和谐。
如果你与某人的唯一互动是在他们指出你的错误之处，那么他们的意见很可能不会被看好。
除非有问题，否则很少看到安全团队的存在，其负面含义往往会引起一些摩擦。这种关系已经破裂了很长时间，开发人员认为AppSec团队是他们的创造力、流程和准时交付功能的障碍，而AppSec则对不断指出已经存在了几十年的普通安全漏洞（就像他们的补救措施一样）感到非常厌倦。
由于越来越不可能的最后期限，资源不足的团队，以及避免返工的强烈愿望，开发人员往往会等到最后一刻才发货，使AppSec审查和干预的机会窗口尽可能小。一个功能失调的过程，它对组织的网络安全风险的增加有着不可接受的影响。
对于安全专家来说，这是一个 "不要射杀信使 "的案例--毕竟，他们的工作是发现错误并报告它们，以便对其进行补救--这不是针对个人。症结在于，他们所提出的建议往往不是最适合公司的技术堆栈，所以在内部软件开发的大环境下，可以被视为基本无助。
AppSec作为小人的概念对于大多数开发方法论来说是违反直觉的，但对于DevSecOps来说，这是一场灾难。黄金标准已经远远超出了瀑布、敏捷，甚至DevOps，进入了一个从SDLC一开始就将安全视为共同责任的过程，这一点至关重要。
为了让DevSecOps发挥作用，需要给软件工程师一个关心安全的理由，而这个理由来自于理解为什么对他们来说保护世界软件的安全是如此重要。那些努力伸出橄榄枝，与开发经理合作以满足团队需求，并在培养安全意识方面承担更多指导作用的安全专家，往往会从他们的努力中看到长期的好处......而且他们花在为另一个XSS错误撕扯头发的时间也略少。
开发人员需要能够提供更好的安全编码结果。
当谈到在高等教育期间学习安全编码时，对许多工程师来说，它是不存在的。这并不是因为他们都在忙着打啤酒杯和WoW--它根本不是大多数计算机科学和IT学位的一部分。
为此，在职培训往往是开发人员第一次接触到软件安全的艺术，而这很少能让他们的世界变得火热。数小时的枯燥视频是一种常见的培训方法，就像 "打勾 "的合规性练习一样，这些练习的频率太低，无法对教开发人员如何安全编码产生任何真正的影响，也无法在减少企业软件中的常见漏洞方面取得任何进展。
AppSec团队和开发团队都忙得不可开交，所以任何培训都应该是有意义的、有吸引力的、有实践性的。从开发背景来看，我们喜欢解决问题并使用工具，所以大多数的静态培训都会在我们专注于更紧迫的事情（或者说，说实话，有趣的事情）时被忽略。
应用程序安全专家处于一个有影响力的位置，他们可以通过倡导开发人员的最佳利益来建立一个长期的、双赢的局面。寻求与工作相关的可行的培训，并以他们喜欢的语言和框架提供，是朝向转移针头和在组织内激发基层、积极的安全文化迈出的一大步。我们几十年来一直在尝试同样的事情，显然，"一刀切 "的培训方法是行不通的。通过帮助提供正确的工具和知识给开发人员，他们可以成功地提高安全编码的技能，以更高的安全意识行事，并产生更高的代码标准。
必须由双方共同作出努力，以取得一致。
有不同目标的人很容易相互误解，或者在最坏的情况下，变得有些不信任。AppSec的目标是跟上不断涌现的代码，并发现任何可能导致数据被泄露、未经授权的访问和恶意攻击的安全问题，这些问题有可能在数年内破坏客户的积极情绪。
开发人员，除其他事项外，在最后期限前建立功能。他们的任务是使软件具有功能性和美观性，并成为保持客户忠诚度的独特数字体验的创造者。他们已经有很多事情要做了，而向他们投出一个安全责任的曲线球是一个令人生畏的前景。虽然这在90年代是可以实现的（你知道，在我们的汽车可以被黑客攻击，而我们的整个生活可以被装在一个叫做智能手机的袖珍超级计算机中），但现在有太多的代码，没有足够的人去通过安全测试。
有了健康的同理心，再加上从软件创建过程的一开始就将安全作为优先事项，AppSec和开发者可以看到使其目标一致的方法。毕竟，积极的安全文化取决于此，而具有安全意识的开发人员是阻止常见漏洞的秘密要素，即使在网络安全技能短缺不断扩大的情况下。
相互尊重时间有巨大的好处。
就像我之前说的，当涉及到创造奇迹（也就是令人惊叹的软件）时，每个人都是超级忙碌的。开发人员将需要分配工作时间来进行可行的实践培训，以培养他们的安全编码技能，任何培训计划都应该是高度相关的设计。
AppSec的时间被浪费在一遍又一遍地修复相同的OWASP十大漏洞上，而开发者的时间则被低参与度的练习所消磨，这些练习强化了他们心中安全是件苦差事的想法。
精心策划的学习体验是至关重要的，它们有助于在需要的时候，通过上下文、一点一滴地提供相关的培训，切中要害。
通过策划一个根据预期结果和内部学习途径定制的安全编码课程，开发人员的时间和工作流程得到了尊重，同时也在努力为企业实现漏洞和网络安全风险的可衡量的减少。这是在寻求结束软性竞争方面的一个快速胜利，并作为一个统一战线向网络安全的狂野西部前进。
Secure Code Warrior的最新情景学习功能。 课程现已推出。
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
建立信任。应用安全与开发者之间的真正安全协同之路
这篇文章的一个版本出现在 网络防御杂志.它已被更新并在此转发。
一个建立在不信任的基础上的关系，最好是以低期望值来对待。可悲的是，这可能是一个组织内的开发人员和AppSec团队之间的工作关系状况。一般来说，这种情况是不理想的，而且在一个对技术有高风险依赖的世界里会导致糟糕的结果。
开发人员在解决问题、构建功能以及在他们的工作中展示创造力方面很有优势。另一方面，AppSec有一个令人羡慕的任务，那就是在他们的代码中发现安全漏洞，将其退回修复，并提供审计和报告，破坏了工程师的宠物项目的光泽。把责任完全推给开发人员是不公平的--安全不是他们的优先事项，也不是他们KPI的一部分--也不能因为过度劳累的AppSec团队只是做他们的工作而受到惩罚。然而，为了网络安全的最佳实践，以及组织层面更好的安全成果，他们真的需要开始友好相处。
而这一切都从信任开始。
AppSec的 "坏人 "形象阻碍了DevSecOps的和谐。
如果你与某人的唯一互动是在他们指出你的错误之处，那么他们的意见很可能不会被看好。
除非有问题，否则很少看到安全团队的存在，其负面含义往往会引起一些摩擦。这种关系已经破裂了很长时间，开发人员认为AppSec团队是他们的创造力、流程和准时交付功能的障碍，而AppSec则对不断指出已经存在了几十年的普通安全漏洞（就像他们的补救措施一样）感到非常厌倦。
由于越来越不可能的最后期限，资源不足的团队，以及避免返工的强烈愿望，开发人员往往会等到最后一刻才发货，使AppSec审查和干预的机会窗口尽可能小。一个功能失调的过程，它对组织的网络安全风险的增加有着不可接受的影响。
对于安全专家来说，这是一个 "不要射杀信使 "的案例--毕竟，他们的工作是发现错误并报告它们，以便对其进行补救--这不是针对个人。症结在于，他们所提出的建议往往不是最适合公司的技术堆栈，所以在内部软件开发的大环境下，可以被视为基本无助。
AppSec作为小人的概念对于大多数开发方法论来说是违反直觉的，但对于DevSecOps来说，这是一场灾难。黄金标准已经远远超出了瀑布、敏捷，甚至DevOps，进入了一个从SDLC一开始就将安全视为共同责任的过程，这一点至关重要。
为了让DevSecOps发挥作用，需要给软件工程师一个关心安全的理由，而这个理由来自于理解为什么对他们来说保护世界软件的安全是如此重要。那些努力伸出橄榄枝，与开发经理合作以满足团队需求，并在培养安全意识方面承担更多指导作用的安全专家，往往会从他们的努力中看到长期的好处......而且他们花在为另一个XSS错误撕扯头发的时间也略少。
开发人员需要能够提供更好的安全编码结果。
当谈到在高等教育期间学习安全编码时，对许多工程师来说，它是不存在的。这并不是因为他们都在忙着打啤酒杯和WoW--它根本不是大多数计算机科学和IT学位的一部分。
为此，在职培训往往是开发人员第一次接触到软件安全的艺术，而这很少能让他们的世界变得火热。数小时的枯燥视频是一种常见的培训方法，就像 "打勾 "的合规性练习一样，这些练习的频率太低，无法对教开发人员如何安全编码产生任何真正的影响，也无法在减少企业软件中的常见漏洞方面取得任何进展。
AppSec团队和开发团队都忙得不可开交，所以任何培训都应该是有意义的、有吸引力的、有实践性的。从开发背景来看，我们喜欢解决问题并使用工具，所以大多数的静态培训都会在我们专注于更紧迫的事情（或者说，说实话，有趣的事情）时被忽略。
应用程序安全专家处于一个有影响力的位置，他们可以通过倡导开发人员的最佳利益来建立一个长期的、双赢的局面。寻求与工作相关的可行的培训，并以他们喜欢的语言和框架提供，是朝向转移针头和在组织内激发基层、积极的安全文化迈出的一大步。我们几十年来一直在尝试同样的事情，显然，"一刀切 "的培训方法是行不通的。通过帮助提供正确的工具和知识给开发人员，他们可以成功地提高安全编码的技能，以更高的安全意识行事，并产生更高的代码标准。
必须由双方共同作出努力，以取得一致。
有不同目标的人很容易相互误解，或者在最坏的情况下，变得有些不信任。AppSec的目标是跟上不断涌现的代码，并发现任何可能导致数据被泄露、未经授权的访问和恶意攻击的安全问题，这些问题有可能在数年内破坏客户的积极情绪。
开发人员，除其他事项外，在最后期限前建立功能。他们的任务是使软件具有功能性和美观性，并成为保持客户忠诚度的独特数字体验的创造者。他们已经有很多事情要做了，而向他们投出一个安全责任的曲线球是一个令人生畏的前景。虽然这在90年代是可以实现的（你知道，在我们的汽车可以被黑客攻击，而我们的整个生活可以被装在一个叫做智能手机的袖珍超级计算机中），但现在有太多的代码，没有足够的人去通过安全测试。
有了健康的同理心，再加上从软件创建过程的一开始就将安全作为优先事项，AppSec和开发者可以看到使其目标一致的方法。毕竟，积极的安全文化取决于此，而具有安全意识的开发人员是阻止常见漏洞的秘密要素，即使在网络安全技能短缺不断扩大的情况下。
相互尊重时间有巨大的好处。
就像我之前说的，当涉及到创造奇迹（也就是令人惊叹的软件）时，每个人都是超级忙碌的。开发人员将需要分配工作时间来进行可行的实践培训，以培养他们的安全编码技能，任何培训计划都应该是高度相关的设计。
AppSec的时间被浪费在一遍又一遍地修复相同的OWASP十大漏洞上，而开发者的时间则被低参与度的练习所消磨，这些练习强化了他们心中安全是件苦差事的想法。
精心策划的学习体验是至关重要的，它们有助于在需要的时候，通过上下文、一点一滴地提供相关的培训，切中要害。
通过策划一个根据预期结果和内部学习途径定制的安全编码课程，开发人员的时间和工作流程得到了尊重，同时也在努力为企业实现漏洞和网络安全风险的可衡量的减少。这是在寻求结束软性竞争方面的一个快速胜利，并作为一个统一战线向网络安全的狂野西部前进。
Secure Code Warrior的最新情景学习功能。 课程现已推出。
