如果应用安全工具是银弹，为什么这么多公司不解雇它？
这篇文章的一个版本出现在 SC杂志.它已被更新并在此转发。
今天的安全专家所面临的许多难题之一是弄清楚他们将使用何种解决方案来处理他们所面临的网络风险的平衡。预算应该如何在工具和人员之间分配？哪套工具对现有的技术栈最有效？有这么多的选择，没有简单的答案，选择错误的选项将在以后花费时间和金钱。
最近的一份报告显示，从现在到2025年，应用安全工具市场正在跟踪"爆炸性 "增长，这有力地表明了它们在成功的DevSecOps实践中无可争议的作用，以及在面对日益增长的具有潜在安全漏洞的代码量时日益增长的行业相关性。
然而，有一个有点奇怪的问题。将近一半的组织明知故犯地发送有漏洞的代码，尽管使用了一系列旨在阻止这种情况的AppSec工具。对于具有不可否认的市场需求的产品获得快速的牵引力，这没有什么意义。为什么这么多人购买了复杂的安全工具，却忽视了它们的发现或根本不使用它们？这有点像买了一个海滨别墅，却睡在树林里的帐篷里。
有几个原因导致AppSec工具没有像我们所期望的那样被利用，这与工具及其功能无关，而更多的是它们如何与整个安全计划整合。
更多的工具并不等同于更少的问题。
随着公司不断发展他们的软件开发流程，从敏捷到DevOps，再到神圣的涅槃，即DevSecOps（嘿，现在，这是我们得到的最好的），在这一过程中，不可避免地要购买多种扫描仪、监控器、防火墙和各种AppSec工具。虽然看起来是 "多多益善"，但这往往会导致技术栈类似于弗兰肯斯泰因的怪物，这意味着所有的不可预测性。
由于预算和专家资源对于所需的工作范围来说越来越有限，试图消除混乱并找到最佳的工具化路径是一项艰巨的任务，而需要扫描和补救的代码不断出现。难怪许多组织不得不继续运送代码，尽管这相当令人震惊，而且仍然对我们的数据和隐私构成巨大的风险。
扫描工具很慢，这影响了发布的敏捷性。
在软件开发中，快速实现安全是一种白鲸，而事实是，即使在我们引导组织采用面向DevSecOps的方法时，我们仍在努力使其正确。在90年代，一丝不苟的手工代码审查可能是安全的保障，但在我们的代码行数以千亿计的时代，这是一个有效的计划，就像用指甲刀准备一个足球场一样。
扫描工具使寻找潜在问题的过程自动化，为我们做了细致的代码审查部分。问题是，在CI/CD管道全面启动的情况下，它们仍然很慢，而且没有一个工具能找到所有的漏洞。在扫描后向安全团队吐出的结果也有几个明显的问题。
- 有很多假阳性（和阴性）现象
- 一些可怜的安全专家仍然不得不坐在那里做人工审查，以从幽灵般的错误中选出真正的错误。
- 很多时候，太多常见的漏洞被暴露出来，而这些漏洞本应该在代码部署之前就被发现。你真的想让你昂贵的安全专家从大的、多毛的安全问题上分心吗？
- 扫描仪可以找到，但不能修复。
即使是在一个竭尽全力致力于网络安全最佳实践，并与时俱进地将安全纳入流程的每个阶段的组织中，如果扫描器是主要的保护措施，并且有太多的常见错误阻碍了团队部署安全代码，那么上述流程仍然是一个障碍。有理由认为，在这里可能会走弯路，而这通常是以依赖最低限度的工具的形式出现的，这些工具不可能涵盖所有的潜在风险，即使是购买了一套解决方案。
一些技术领先的自动化会导致代码质量下降
扫描和测试承担着AppSec工具中自动化流程的重任，还有防火墙和监控等基本要素，但其他常见的工具会在不经意间随着时间的推移侵蚀实践安全的基础。
例如，RASP（运行时应用自我保护）技术经常被应用于强化安全态势而不牺牲编码速度。它在应用程序的运行环境中运行，防止恶意代码输入、实时攻击，并标记任何奇怪的执行行为。
这当然是一层额外的保护，但如果被认为是针对代码库中任何潜在弱点的故障保护，开发人员可能会变得自满，特别是在面对越来越不可能的上市期限时，推出新功能。安全编码实践可能不会被遵循，因为他们认为运行时的自我保护会发现任何错误。开发人员不会去创造不安全的编码模式，但安全往往会被放在优先位置，以支持功能的交付，特别是假设有一个自动化的保障。
工具可能会失败（在RASP的情况下，经常在监控模式下运行，以避免误报，这反过来只能提供可视性--而不是保护--防止攻击），而当这种情况发生时，每次都可以依靠高质量的安全代码。每个接触代码的角色的安全意识是DevSecOps的基础，开发人员不进行安全代码的培训或生产安全代码是一个错误。编写安全和不安全的代码需要同样的努力；获得安全代码的知识才是真正的精力所在。实施和优化RASP所花费的时间可以更好地用于提高开发人员的技能，使其在一开始就不犯错误。
平衡工具和人：这不是银弹，但这是最接近我们的方法（目前）。
DevSecOps的主要精神是使安全成为一种共同的责任，对于那些正在创建为我们的生活提供动力的软件的组织来说--从电网到我们的门铃--他们需要把每个人都带到这个旅程中来，以确保更高水平的安全。
工具并不能做到这一切，甚至也不是最便宜的方法。到目前为止，最好的结果是通过优先考虑对每个接触代码的人进行相关的安全培训，积极努力让开发团队把安全放在首位，并建立一个积极的安全文化，由人主导，而工具套件则起辅助作用。
即使面对时间限制、偷工减料以及其他让安全专家夜不能寐的事情，如果开发人员首先不引入常见的安全缺陷，那么这些工具（以及是否使用这些工具）所代表的风险因素要小得多。
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。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
这篇文章的一个版本出现在 SC杂志.它已被更新并在此转发。
今天的安全专家所面临的许多难题之一是弄清楚他们将使用何种解决方案来处理他们所面临的网络风险的平衡。预算应该如何在工具和人员之间分配？哪套工具对现有的技术栈最有效？有这么多的选择，没有简单的答案，选择错误的选项将在以后花费时间和金钱。
最近的一份报告显示，从现在到2025年，应用安全工具市场正在跟踪"爆炸性 "增长，这有力地表明了它们在成功的DevSecOps实践中无可争议的作用，以及在面对日益增长的具有潜在安全漏洞的代码量时日益增长的行业相关性。
然而，有一个有点奇怪的问题。将近一半的组织明知故犯地发送有漏洞的代码，尽管使用了一系列旨在阻止这种情况的AppSec工具。对于具有不可否认的市场需求的产品获得快速的牵引力，这没有什么意义。为什么这么多人购买了复杂的安全工具，却忽视了它们的发现或根本不使用它们？这有点像买了一个海滨别墅，却睡在树林里的帐篷里。
有几个原因导致AppSec工具没有像我们所期望的那样被利用，这与工具及其功能无关，而更多的是它们如何与整个安全计划整合。
更多的工具并不等同于更少的问题。
随着公司不断发展他们的软件开发流程，从敏捷到DevOps，再到神圣的涅槃，即DevSecOps（嘿，现在，这是我们得到的最好的），在这一过程中，不可避免地要购买多种扫描仪、监控器、防火墙和各种AppSec工具。虽然看起来是 "多多益善"，但这往往会导致技术栈类似于弗兰肯斯泰因的怪物，这意味着所有的不可预测性。
由于预算和专家资源对于所需的工作范围来说越来越有限，试图消除混乱并找到最佳的工具化路径是一项艰巨的任务，而需要扫描和补救的代码不断出现。难怪许多组织不得不继续运送代码，尽管这相当令人震惊，而且仍然对我们的数据和隐私构成巨大的风险。
扫描工具很慢，这影响了发布的敏捷性。
在软件开发中，快速实现安全是一种白鲸，而事实是，即使在我们引导组织采用面向DevSecOps的方法时，我们仍在努力使其正确。在90年代，一丝不苟的手工代码审查可能是安全的保障，但在我们的代码行数以千亿计的时代，这是一个有效的计划，就像用指甲刀准备一个足球场一样。
扫描工具使寻找潜在问题的过程自动化，为我们做了细致的代码审查部分。问题是，在CI/CD管道全面启动的情况下，它们仍然很慢，而且没有一个工具能找到所有的漏洞。在扫描后向安全团队吐出的结果也有几个明显的问题。
- 有很多假阳性（和阴性）现象
- 一些可怜的安全专家仍然不得不坐在那里做人工审查，以从幽灵般的错误中选出真正的错误。
- 很多时候，太多常见的漏洞被暴露出来，而这些漏洞本应该在代码部署之前就被发现。你真的想让你昂贵的安全专家从大的、多毛的安全问题上分心吗？
- 扫描仪可以找到，但不能修复。
即使是在一个竭尽全力致力于网络安全最佳实践，并与时俱进地将安全纳入流程的每个阶段的组织中，如果扫描器是主要的保护措施，并且有太多的常见错误阻碍了团队部署安全代码，那么上述流程仍然是一个障碍。有理由认为，在这里可能会走弯路，而这通常是以依赖最低限度的工具的形式出现的，这些工具不可能涵盖所有的潜在风险，即使是购买了一套解决方案。
一些技术领先的自动化会导致代码质量下降
扫描和测试承担着AppSec工具中自动化流程的重任，还有防火墙和监控等基本要素，但其他常见的工具会在不经意间随着时间的推移侵蚀实践安全的基础。
例如，RASP（运行时应用自我保护）技术经常被应用于强化安全态势而不牺牲编码速度。它在应用程序的运行环境中运行，防止恶意代码输入、实时攻击，并标记任何奇怪的执行行为。
这当然是一层额外的保护，但如果被认为是针对代码库中任何潜在弱点的故障保护，开发人员可能会变得自满，特别是在面对越来越不可能的上市期限时，推出新功能。安全编码实践可能不会被遵循，因为他们认为运行时的自我保护会发现任何错误。开发人员不会去创造不安全的编码模式，但安全往往会被放在优先位置，以支持功能的交付，特别是假设有一个自动化的保障。
工具可能会失败（在RASP的情况下，经常在监控模式下运行，以避免误报，这反过来只能提供可视性--而不是保护--防止攻击），而当这种情况发生时，每次都可以依靠高质量的安全代码。每个接触代码的角色的安全意识是DevSecOps的基础，开发人员不进行安全代码的培训或生产安全代码是一个错误。编写安全和不安全的代码需要同样的努力；获得安全代码的知识才是真正的精力所在。实施和优化RASP所花费的时间可以更好地用于提高开发人员的技能，使其在一开始就不犯错误。
平衡工具和人：这不是银弹，但这是最接近我们的方法（目前）。
DevSecOps的主要精神是使安全成为一种共同的责任，对于那些正在创建为我们的生活提供动力的软件的组织来说--从电网到我们的门铃--他们需要把每个人都带到这个旅程中来，以确保更高水平的安全。
工具并不能做到这一切，甚至也不是最便宜的方法。到目前为止，最好的结果是通过优先考虑对每个接触代码的人进行相关的安全培训，积极努力让开发团队把安全放在首位，并建立一个积极的安全文化，由人主导，而工具套件则起辅助作用。
即使面对时间限制、偷工减料以及其他让安全专家夜不能寐的事情，如果开发人员首先不引入常见的安全缺陷，那么这些工具（以及是否使用这些工具）所代表的风险因素要小得多。
这篇文章的一个版本出现在 SC杂志.它已被更新并在此转发。
今天的安全专家所面临的许多难题之一是弄清楚他们将使用何种解决方案来处理他们所面临的网络风险的平衡。预算应该如何在工具和人员之间分配？哪套工具对现有的技术栈最有效？有这么多的选择，没有简单的答案，选择错误的选项将在以后花费时间和金钱。
最近的一份报告显示，从现在到2025年，应用安全工具市场正在跟踪"爆炸性 "增长，这有力地表明了它们在成功的DevSecOps实践中无可争议的作用，以及在面对日益增长的具有潜在安全漏洞的代码量时日益增长的行业相关性。
然而，有一个有点奇怪的问题。将近一半的组织明知故犯地发送有漏洞的代码，尽管使用了一系列旨在阻止这种情况的AppSec工具。对于具有不可否认的市场需求的产品获得快速的牵引力，这没有什么意义。为什么这么多人购买了复杂的安全工具，却忽视了它们的发现或根本不使用它们？这有点像买了一个海滨别墅，却睡在树林里的帐篷里。
有几个原因导致AppSec工具没有像我们所期望的那样被利用，这与工具及其功能无关，而更多的是它们如何与整个安全计划整合。
更多的工具并不等同于更少的问题。
随着公司不断发展他们的软件开发流程，从敏捷到DevOps，再到神圣的涅槃，即DevSecOps（嘿，现在，这是我们得到的最好的），在这一过程中，不可避免地要购买多种扫描仪、监控器、防火墙和各种AppSec工具。虽然看起来是 "多多益善"，但这往往会导致技术栈类似于弗兰肯斯泰因的怪物，这意味着所有的不可预测性。
由于预算和专家资源对于所需的工作范围来说越来越有限，试图消除混乱并找到最佳的工具化路径是一项艰巨的任务，而需要扫描和补救的代码不断出现。难怪许多组织不得不继续运送代码，尽管这相当令人震惊，而且仍然对我们的数据和隐私构成巨大的风险。
扫描工具很慢，这影响了发布的敏捷性。
在软件开发中，快速实现安全是一种白鲸，而事实是，即使在我们引导组织采用面向DevSecOps的方法时，我们仍在努力使其正确。在90年代，一丝不苟的手工代码审查可能是安全的保障，但在我们的代码行数以千亿计的时代，这是一个有效的计划，就像用指甲刀准备一个足球场一样。
扫描工具使寻找潜在问题的过程自动化，为我们做了细致的代码审查部分。问题是，在CI/CD管道全面启动的情况下，它们仍然很慢，而且没有一个工具能找到所有的漏洞。在扫描后向安全团队吐出的结果也有几个明显的问题。
- 有很多假阳性（和阴性）现象
- 一些可怜的安全专家仍然不得不坐在那里做人工审查，以从幽灵般的错误中选出真正的错误。
- 很多时候，太多常见的漏洞被暴露出来，而这些漏洞本应该在代码部署之前就被发现。你真的想让你昂贵的安全专家从大的、多毛的安全问题上分心吗？
- 扫描仪可以找到，但不能修复。
即使是在一个竭尽全力致力于网络安全最佳实践，并与时俱进地将安全纳入流程的每个阶段的组织中，如果扫描器是主要的保护措施，并且有太多的常见错误阻碍了团队部署安全代码，那么上述流程仍然是一个障碍。有理由认为，在这里可能会走弯路，而这通常是以依赖最低限度的工具的形式出现的，这些工具不可能涵盖所有的潜在风险，即使是购买了一套解决方案。
一些技术领先的自动化会导致代码质量下降
扫描和测试承担着AppSec工具中自动化流程的重任，还有防火墙和监控等基本要素，但其他常见的工具会在不经意间随着时间的推移侵蚀实践安全的基础。
例如，RASP（运行时应用自我保护）技术经常被应用于强化安全态势而不牺牲编码速度。它在应用程序的运行环境中运行，防止恶意代码输入、实时攻击，并标记任何奇怪的执行行为。
这当然是一层额外的保护，但如果被认为是针对代码库中任何潜在弱点的故障保护，开发人员可能会变得自满，特别是在面对越来越不可能的上市期限时，推出新功能。安全编码实践可能不会被遵循，因为他们认为运行时的自我保护会发现任何错误。开发人员不会去创造不安全的编码模式，但安全往往会被放在优先位置，以支持功能的交付，特别是假设有一个自动化的保障。
工具可能会失败（在RASP的情况下，经常在监控模式下运行，以避免误报，这反过来只能提供可视性--而不是保护--防止攻击），而当这种情况发生时，每次都可以依靠高质量的安全代码。每个接触代码的角色的安全意识是DevSecOps的基础，开发人员不进行安全代码的培训或生产安全代码是一个错误。编写安全和不安全的代码需要同样的努力；获得安全代码的知识才是真正的精力所在。实施和优化RASP所花费的时间可以更好地用于提高开发人员的技能，使其在一开始就不犯错误。
平衡工具和人：这不是银弹，但这是最接近我们的方法（目前）。
DevSecOps的主要精神是使安全成为一种共同的责任，对于那些正在创建为我们的生活提供动力的软件的组织来说--从电网到我们的门铃--他们需要把每个人都带到这个旅程中来，以确保更高水平的安全。
工具并不能做到这一切，甚至也不是最便宜的方法。到目前为止，最好的结果是通过优先考虑对每个接触代码的人进行相关的安全培训，积极努力让开发团队把安全放在首位，并建立一个积极的安全文化，由人主导，而工具套件则起辅助作用。
即使面对时间限制、偷工减料以及其他让安全专家夜不能寐的事情，如果开发人员首先不引入常见的安全缺陷，那么这些工具（以及是否使用这些工具）所代表的风险因素要小得多。
点击下面的链接，下载本资料的 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。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
这篇文章的一个版本出现在 SC杂志.它已被更新并在此转发。
今天的安全专家所面临的许多难题之一是弄清楚他们将使用何种解决方案来处理他们所面临的网络风险的平衡。预算应该如何在工具和人员之间分配？哪套工具对现有的技术栈最有效？有这么多的选择，没有简单的答案，选择错误的选项将在以后花费时间和金钱。
最近的一份报告显示，从现在到2025年，应用安全工具市场正在跟踪"爆炸性 "增长，这有力地表明了它们在成功的DevSecOps实践中无可争议的作用，以及在面对日益增长的具有潜在安全漏洞的代码量时日益增长的行业相关性。
然而，有一个有点奇怪的问题。将近一半的组织明知故犯地发送有漏洞的代码，尽管使用了一系列旨在阻止这种情况的AppSec工具。对于具有不可否认的市场需求的产品获得快速的牵引力，这没有什么意义。为什么这么多人购买了复杂的安全工具，却忽视了它们的发现或根本不使用它们？这有点像买了一个海滨别墅，却睡在树林里的帐篷里。
有几个原因导致AppSec工具没有像我们所期望的那样被利用，这与工具及其功能无关，而更多的是它们如何与整个安全计划整合。
更多的工具并不等同于更少的问题。
随着公司不断发展他们的软件开发流程，从敏捷到DevOps，再到神圣的涅槃，即DevSecOps（嘿，现在，这是我们得到的最好的），在这一过程中，不可避免地要购买多种扫描仪、监控器、防火墙和各种AppSec工具。虽然看起来是 "多多益善"，但这往往会导致技术栈类似于弗兰肯斯泰因的怪物，这意味着所有的不可预测性。
由于预算和专家资源对于所需的工作范围来说越来越有限，试图消除混乱并找到最佳的工具化路径是一项艰巨的任务，而需要扫描和补救的代码不断出现。难怪许多组织不得不继续运送代码，尽管这相当令人震惊，而且仍然对我们的数据和隐私构成巨大的风险。
扫描工具很慢，这影响了发布的敏捷性。
在软件开发中，快速实现安全是一种白鲸，而事实是，即使在我们引导组织采用面向DevSecOps的方法时，我们仍在努力使其正确。在90年代，一丝不苟的手工代码审查可能是安全的保障，但在我们的代码行数以千亿计的时代，这是一个有效的计划，就像用指甲刀准备一个足球场一样。
扫描工具使寻找潜在问题的过程自动化，为我们做了细致的代码审查部分。问题是，在CI/CD管道全面启动的情况下，它们仍然很慢，而且没有一个工具能找到所有的漏洞。在扫描后向安全团队吐出的结果也有几个明显的问题。
- 有很多假阳性（和阴性）现象
- 一些可怜的安全专家仍然不得不坐在那里做人工审查，以从幽灵般的错误中选出真正的错误。
- 很多时候，太多常见的漏洞被暴露出来，而这些漏洞本应该在代码部署之前就被发现。你真的想让你昂贵的安全专家从大的、多毛的安全问题上分心吗？
- 扫描仪可以找到，但不能修复。
即使是在一个竭尽全力致力于网络安全最佳实践，并与时俱进地将安全纳入流程的每个阶段的组织中，如果扫描器是主要的保护措施，并且有太多的常见错误阻碍了团队部署安全代码，那么上述流程仍然是一个障碍。有理由认为，在这里可能会走弯路，而这通常是以依赖最低限度的工具的形式出现的，这些工具不可能涵盖所有的潜在风险，即使是购买了一套解决方案。
一些技术领先的自动化会导致代码质量下降
扫描和测试承担着AppSec工具中自动化流程的重任，还有防火墙和监控等基本要素，但其他常见的工具会在不经意间随着时间的推移侵蚀实践安全的基础。
例如，RASP（运行时应用自我保护）技术经常被应用于强化安全态势而不牺牲编码速度。它在应用程序的运行环境中运行，防止恶意代码输入、实时攻击，并标记任何奇怪的执行行为。
这当然是一层额外的保护，但如果被认为是针对代码库中任何潜在弱点的故障保护，开发人员可能会变得自满，特别是在面对越来越不可能的上市期限时，推出新功能。安全编码实践可能不会被遵循，因为他们认为运行时的自我保护会发现任何错误。开发人员不会去创造不安全的编码模式，但安全往往会被放在优先位置，以支持功能的交付，特别是假设有一个自动化的保障。
工具可能会失败（在RASP的情况下，经常在监控模式下运行，以避免误报，这反过来只能提供可视性--而不是保护--防止攻击），而当这种情况发生时，每次都可以依靠高质量的安全代码。每个接触代码的角色的安全意识是DevSecOps的基础，开发人员不进行安全代码的培训或生产安全代码是一个错误。编写安全和不安全的代码需要同样的努力；获得安全代码的知识才是真正的精力所在。实施和优化RASP所花费的时间可以更好地用于提高开发人员的技能，使其在一开始就不犯错误。
平衡工具和人：这不是银弹，但这是最接近我们的方法（目前）。
DevSecOps的主要精神是使安全成为一种共同的责任，对于那些正在创建为我们的生活提供动力的软件的组织来说--从电网到我们的门铃--他们需要把每个人都带到这个旅程中来，以确保更高水平的安全。
工具并不能做到这一切，甚至也不是最便宜的方法。到目前为止，最好的结果是通过优先考虑对每个接触代码的人进行相关的安全培训，积极努力让开发团队把安全放在首位，并建立一个积极的安全文化，由人主导，而工具套件则起辅助作用。
即使面对时间限制、偷工减料以及其他让安全专家夜不能寐的事情，如果开发人员首先不引入常见的安全缺陷，那么这些工具（以及是否使用这些工具）所代表的风险因素要小得多。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载
.png)
