永无止境的攻击面时代的预防工作
这篇文章的一个版本出现在 SD时报.它已被更新并在此转发。
当我们谈论进步时，通常情况下，数字进步是最重要的话题。我们希望一切都更好、更快、更方便、更强大，而且我们希望用更少的钱、时间和风险来做这些。在大多数情况下，这些 "不可能 "的目标最终都会实现；这可能需要几年时间和多个版本（以及一个开发人员团队，如果他们被要求在功能设计上再转换一次该死的齿轮，他们可能会发动政变），但每天，代码都在那里改变世界。
然而，伴随着伟大的软件扩张而来的是巨大的责任，而现实是，我们根本没有准备好从安全角度来处理它。软件开发不再是一个孤岛，当我们考虑到由软件驱动的风险的所有方面--从云、电器和车辆中的嵌入式系统、我们的关键基础设施等一切，更不用说连接这一切的API--攻击面是无边界的，而且是无法控制的。
我们不能期待一个神奇的时代，每一行代码都由经验丰富的安全专家精心检查--这种技能差距不会很快消失--但作为一个行业，我们可以采用更全面的方法来处理代码级安全。
让我们来探讨一下，我们如何用手头的工具来笼络这个无限的攻击面。
对商业风险的程度要现实（以及你愿意接受的程度）。
完美的安全是不可持续的，但戴上眼罩，假装一切是蓝天白云也是不可持续的。我们已经知道，一些组织在知情的情况下会运送有漏洞的代码，显然，这是一种基于新功能和产品上市时间的计算风险。
安全的速度是一个挑战，尤其是在DevSecOps不是标准开发方法的地方。然而，我们只需要看看最近的Log4Shell漏洞，就会发现代码中相对较小的安全问题是如何为成功的攻击提供机会的，并看到那些计算过的风险对运送较低质量的代码所造成的后果可能远比预计的大。
适应成为一个（访问）控制怪人
由于云存储环境配置不当，造成了数量惊人的昂贵的数据泄露，而访问控制错误导致的敏感数据暴露的可能性继续困扰着大多数企业的安全团队。
2019年，财富500强公司第一美国金融公司(First American Financial Corp.)艰难地发现了这一点。一个认证错误--一个相对简单的补救措施--导致超过8亿条记录被曝光，包括银行对账单、抵押贷款合同和身份证照片。他们的文件链接不需要用户识别或登录，使得任何有网络浏览器的人都可以访问它们。更糟糕的是，它们是用顺序号记录的，这意味着链接中的数字的简单变化就会暴露出新的数据记录。
这个安全问题在被媒体曝光之前就已经在内部被发现了，然而，由于没有将其正确归类为高风险安全问题，也没有将其报告给高级管理层进行紧急补救，因此造成的影响至今仍在进行中。
破损的访问控制现在位于OWASP前10名的最顶端是有原因的：它就像泥土一样普遍，开发人员需要经过验证的安全意识和实用技能来驾驭自己构建的认证和权限的最佳实践，确保检查和措施到位以保护敏感数据的暴露。
API的性质使它们特别相关和棘手；从设计上看，它们与其他应用程序非常健谈，而开发团队应该对所有潜在的接入点有可见性。毕竟，他们在寻求提供更安全的软件时不能考虑到未知的变量和用例。
分析你的安全计划：对预防的重视程度如何？
安全计划的一个重要组成部分致力于事件响应和反应是有道理的，但许多组织由于没有利用所有可用的资源在一开始就防止安全事件的发生而失去了宝贵的风险最小化。
当然，有全面的安全工具堆，可以帮助发现有问题的漏洞，但几乎50%的公司承认，他们知道有漏洞的代码。时间的限制，工具集的复杂性，以及缺乏训练有素的专家来应对报告，这些都是造成本质上的风险的原因，但事实上，代码需要在云、应用程序、API功能、嵌入式系统、库和不断扩大的技术领域中得到保护，这确保了我们在目前的方法下总是落后一步。
安全漏洞是人类造成的问题，我们不能指望机器人为我们做所有的修复工作。如果你的开发团队没有得到有效的技能提升--不仅仅是每年一次的研讨会，而是适当的教育积木--那么你总是有可能接受低质量的代码作为标准，以及随之而来的安全风险。
你是否高估了你的开发人员的准备程度？
开发人员很少被评估他们的安全编码能力，这不是他们的优先事项（在很多情况下也不是一个KPI）。如果不给他们指出一条更好的道路，或者告诉他们这是衡量他们成功的一个标准，他们就不能成为不良安全实践的替罪羊。
但是，在组织内部经常有这样一种假设，即所提供的指导在培养工程团队减轻常见的安全风险方面是有效的。根据培训和他们应用安全最佳实践的意识，他们可能没有准备好成为理想的第一道防线（并阻止无休止的注入缺陷堵塞pentest报告）。
理想的状态是完成越来越复杂的学习途径，并对所产生的技能进行验证，以确保它在现实世界中对开发者实际有效。然而，这需要一个文化标准，即从一开始就考虑到开发人员，并正确地启用。如果我们作为一个行业要到野外去捍卫我们自己创造的这个巨大的代码景观，我们将需要所有我们能得到的帮助......而在我们面前有比我们意识到的更多。
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
永无止境的攻击面时代的预防工作
这篇文章的一个版本出现在 SD时报.它已被更新并在此转发。
当我们谈论进步时，通常情况下，数字进步是最重要的话题。我们希望一切都更好、更快、更方便、更强大，而且我们希望用更少的钱、时间和风险来做这些。在大多数情况下，这些 "不可能 "的目标最终都会实现；这可能需要几年时间和多个版本（以及一个开发人员团队，如果他们被要求在功能设计上再转换一次该死的齿轮，他们可能会发动政变），但每天，代码都在那里改变世界。
然而，伴随着伟大的软件扩张而来的是巨大的责任，而现实是，我们根本没有准备好从安全角度来处理它。软件开发不再是一个孤岛，当我们考虑到由软件驱动的风险的所有方面--从云、电器和车辆中的嵌入式系统、我们的关键基础设施等一切，更不用说连接这一切的API--攻击面是无边界的，而且是无法控制的。
我们不能期待一个神奇的时代，每一行代码都由经验丰富的安全专家精心检查--这种技能差距不会很快消失--但作为一个行业，我们可以采用更全面的方法来处理代码级安全。
让我们来探讨一下，我们如何用手头的工具来笼络这个无限的攻击面。
对商业风险的程度要现实（以及你愿意接受的程度）。
完美的安全是不可持续的，但戴上眼罩，假装一切是蓝天白云也是不可持续的。我们已经知道，一些组织在知情的情况下会运送有漏洞的代码，显然，这是一种基于新功能和产品上市时间的计算风险。
安全的速度是一个挑战，尤其是在DevSecOps不是标准开发方法的地方。然而，我们只需要看看最近的Log4Shell漏洞，就会发现代码中相对较小的安全问题是如何为成功的攻击提供机会的，并看到那些计算过的风险对运送较低质量的代码所造成的后果可能远比预计的大。
适应成为一个（访问）控制怪人
由于云存储环境配置不当，造成了数量惊人的昂贵的数据泄露，而访问控制错误导致的敏感数据暴露的可能性继续困扰着大多数企业的安全团队。
2019年，财富500强公司第一美国金融公司(First American Financial Corp.)艰难地发现了这一点。一个认证错误--一个相对简单的补救措施--导致超过8亿条记录被曝光，包括银行对账单、抵押贷款合同和身份证照片。他们的文件链接不需要用户识别或登录，使得任何有网络浏览器的人都可以访问它们。更糟糕的是，它们是用顺序号记录的，这意味着链接中的数字的简单变化就会暴露出新的数据记录。
这个安全问题在被媒体曝光之前就已经在内部被发现了，然而，由于没有将其正确归类为高风险安全问题，也没有将其报告给高级管理层进行紧急补救，因此造成的影响至今仍在进行中。
破损的访问控制现在位于OWASP前10名的最顶端是有原因的：它就像泥土一样普遍，开发人员需要经过验证的安全意识和实用技能来驾驭自己构建的认证和权限的最佳实践，确保检查和措施到位以保护敏感数据的暴露。
API的性质使它们特别相关和棘手；从设计上看，它们与其他应用程序非常健谈，而开发团队应该对所有潜在的接入点有可见性。毕竟，他们在寻求提供更安全的软件时不能考虑到未知的变量和用例。
分析你的安全计划：对预防的重视程度如何？
安全计划的一个重要组成部分致力于事件响应和反应是有道理的，但许多组织由于没有利用所有可用的资源在一开始就防止安全事件的发生而失去了宝贵的风险最小化。
当然，有全面的安全工具堆，可以帮助发现有问题的漏洞，但几乎50%的公司承认，他们知道有漏洞的代码。时间的限制，工具集的复杂性，以及缺乏训练有素的专家来应对报告，这些都是造成本质上的风险的原因，但事实上，代码需要在云、应用程序、API功能、嵌入式系统、库和不断扩大的技术领域中得到保护，这确保了我们在目前的方法下总是落后一步。
安全漏洞是人类造成的问题，我们不能指望机器人为我们做所有的修复工作。如果你的开发团队没有得到有效的技能提升--不仅仅是每年一次的研讨会，而是适当的教育积木--那么你总是有可能接受低质量的代码作为标准，以及随之而来的安全风险。
你是否高估了你的开发人员的准备程度？
开发人员很少被评估他们的安全编码能力，这不是他们的优先事项（在很多情况下也不是一个KPI）。如果不给他们指出一条更好的道路，或者告诉他们这是衡量他们成功的一个标准，他们就不能成为不良安全实践的替罪羊。
但是，在组织内部经常有这样一种假设，即所提供的指导在培养工程团队减轻常见的安全风险方面是有效的。根据培训和他们应用安全最佳实践的意识，他们可能没有准备好成为理想的第一道防线（并阻止无休止的注入缺陷堵塞pentest报告）。
理想的状态是完成越来越复杂的学习途径，并对所产生的技能进行验证，以确保它在现实世界中对开发者实际有效。然而，这需要一个文化标准，即从一开始就考虑到开发人员，并正确地启用。如果我们作为一个行业要到野外去捍卫我们自己创造的这个巨大的代码景观，我们将需要所有我们能得到的帮助......而在我们面前有比我们意识到的更多。
