2021-2022现代应用程序开发安全分析报告.pdf

2021-2022现代应用程序 开 发安全分析报告 返回目录 目录 研究目标 3 研究重点 4 尽管许多组织仍会提交易受攻击的代码，但大多数组织认为他们的应用安全计划都是可靠的。 5 为了确保如今种类繁多的应用程序开发与部署模型的安全，需要使用各种各样的安全测试工具。 11 开发人员安全培训质量参差不齐，缺乏提高开发人员安全技能的计划。 17 AppSec 测试工具激增为许多人带来了问题，超过三分之一的人将投资重点放在了整合上。 20 各个组织都在投资，超过半数的组织都计划较前一年相比，大幅增加在应用安全方面的支出。 22 研究方法 26 3 研究目标 DevSecOps 已在现代开发应用程序时优先考虑安全性并围绕确保安 全展开开发活动，然而，驱动并衡量安全团队或开发团队的指标是不 一致的，因此实现此目标仍然备受挑战。再加上大多数安全团队缺乏 对现代应用程序开发实践的了解，这使得挑战进一步加剧。向微服务 架构的转型以及对容器，无服务器模式的使用，转变了开发人员构 建、测试以及部署的方式。 因而，应用安全工具的整合可以说是早已启动。众多测试工具催生了 大量问题，许多问题又彼此重叠，使得各个组织不堪重负，确定优先 次序和缓解问题变得复杂化，因此，集成式的应用安全平台可以说是 众望所归。 为了深入了解这些趋势，ESG 对北美（美国和加拿大）地区各个组织 参与确保应用程序开发工具和流程安全的 378 名负责 IT、网络安全 和应用程序开发的专业人员进行了调研。 考察购买意向。即考察应用安全团队在开发过程中对应用程序的安全 程度的把控，并预测买家对于不同类型供应商的应用安全解决方案的 偏好。 了解触发点。即决策者会根据什么来进行应用安全投资，以及如何把握投 资的优先级和时机。 确定了解程度。确定安全团队对于现代开发和部署实践的了解程度，以 及在何处实施安全控制以便降低风险。 深入了解。即了解开发团队和网络安全团队对于应用安全解决方案的部署 与管理方面的协同工作方式。 本项研究旨在： 拥有良好的应用安全计划并不意味着组织将不再提交易受攻击的代码。区别在于提交此类代码的人完全知情并清楚地 了解他们所承担的风险。要想实现应用程序安全就需要持续对潜在风险进行分类处理，这其中就涉及到如何制定优先级 决策，使得开发团队既能在规定日期前交付应用程序，同时还能降低风险。 随着应用安全日趋成熟，任何单一的测试技术都无法帮助开发团队降低全部安全风险。这就需要安全团队运用通常由多个供应商 提供的多种工具来确保 SDLC 的安全。尽管使用情况各不相同，组织认为最重要的工具也有所不同，但大多数组织最终都会混合使 用众多工具来满足他们的安全需求。 尽管大多数组织为开发人员提供某一级别的安全培训，但超过 50% 的组织仅仅每年培训一次或者更少。虽然开发经理通常负责此 类培训，但是在大多数组织中，应用程序安全分析师都肩负重任，需要对跟踪记录显示引入了过多安全问题的开发团队或单个开 发人员，执行补救式的培训。 与其他类别的安全控制相似，许多组织使用了太多工具，以致于他们难以集成和管理它们。这就降低了计划的有效程度，并需要安 排过多资源来管理工具。近三分之一的组织都遇到了这一问题，并因此计划将未来的投资用于整合与简化大量的工具。 44% 的组织计划将应用安全投资瞄准云端，三分之一的组织将整点放在工具整合上，以便简化流程。其他组织则计划投资扩大测 试工具的使用范围，使更大比例的开发团队和应用程序能使用这些工具。 研究重点 尽管许多组织仍会提交易受攻击的代码，但 大多数组织认为他们的应用安全计划都是 可靠的。 为了确保如今种类繁多的应用程序开发与部署模 型的安全，需要使用各种各样的安全测试工具。 开发人员安全培训质量参差不齐，缺乏提高开发 人员安全技能的计划。 AppSec 测试工具激增为许多人带来了问题，超过 三分之一的人将投资重点放在了整合上。 各个组织都在投资，超过半数的组织都计划较前 一年相比，大幅增加在应用安全方面的支出。 返回目录 5 研究重点： 现代应用程序开发安全 尽管许多组织仍会提交易 受攻击的代码，但大多数 组织认为他们的应用安全 计划都是可靠的。 大多数组织认为他们的应用安全计划相 当不错 大多数组织认为他们的应用安全计划相当不错，超过三分之一的组织给 其计划打 9 或 10 分，整体平均分为 7.92 分。这一好评反映了各组织在过 去几年对于应用安全计划的不断投资效果和覆盖水平。尽管如此，离完 全覆盖代码库还相去甚远，仅 34% 的组织在其超过四分之三的代码库中 使用 AppSec 工具。 受 AppSec 工具保护的代码库 2% 7% 20% 37% 21% 13% Less than 10% 10% to 25% 26% to 50% 51% to 75% 76% to 90% 91% to 100% 36% 的组织给其应用安全 计划打 9 或 10 分 36+64+R 不到 10% 10% 至 25% 26% 至 50% 51% 至 75% 76% 至 90% 91% 至 100% 组织会提交易受攻击的代码吗？ 为什么组织会提交易受攻击的代码 48% 31% 6% 14% Yes, we do this regularly Yes, we do this occasionally Yes, we have done this once No, we have never knowingly pushed code to production with vulnerabilities 45% 49% 54% The vulnerabilities were discovered too late in our cycle to resolve them in time We felt the vulnerabilities had very low risk To meet a critical deadline, with a plan to remediate in a later release 无论程序有多么完善，大 部分组织仍会定期提交易 受攻击的代码 拥有良好的应用安全计划并不意味着组织将不 再提交易受攻击的代码。区别在于提交此类代码 的人完全知情并清楚地了解他们所承担的风险。 要想实现应用程序安全就需要持续对潜在风险 进行分类处理，这其中就涉及到如何制定优先级 决策，使得开发团队既能在规定日期前交付应用 程序，同时还能降低风险。请注意，如果在开发周 期中过晚发现漏洞，那么这些漏洞通常将无法得 到解决。这也进一步强调了尽早注重应用程序安 全的重要性。因为只有尽早发现漏洞才能留出足 够的时间及时解决关键问题，不影响按时交付。 是的，我们经常提交 是的，我们偶尔提交 是的，我们提交过一次 不是，我们从未故意向产品提交 易受攻击的代码 为了赶上最终交付日期，并计划在以后的版本中进行修复 我们认为漏洞的风险非常低 在开发周期中过晚发现漏洞，以至于这些漏洞无法及时解决 大多数组织仍在遭受漏洞利用导 致的攻击 尽管增加对 AppSec 计划的投资能够降低风险，但 60% 的组织仍然表示他们遭受了 OWASP top-10漏洞入侵。 尽管某些已知漏洞的攻击利用原因不一定直接对应到 到代码缺陷，但这也强调了尽职调查（包括代码覆盖范 围、整个 SDLC 中的测试频率以及确定已识别漏洞的优 先级）的必要性。 那么谁会决定发布具有已知漏洞的代码？尽管众多 组织是由开发经理和安全分析师共同作出此决定 的，但也有不少团队是由一个负责人作出最终决定 的。这反映了不同的开发组织管理整个应用安全流 程方面的差异，一些组织将所有权交给安全团队，而 其他组织则让开发经理负责。 60% 的组织在过去 12 个月遭受到 OWASP top-10漏洞入侵其生产应用程序 60+40+R 谁决定提交代码？ 28% 24% 21% 15% 11% 1% Team decision that includes both development manager and security analyst Development manager Security analyst Individual developers assess the priority of each issue QA and/or security teams Dont know 由包括开发经理和安全分析师在内的团队决定 由开发经理决定 由安全分析师决定 由单个开发者通过评估每个问题的优先级决定 由 QA 和 /或安全团队决定 不知道 安全分析师越来越多的参与到 AppSec 测试过程中 大部分组织由开发经理或应用安全分析师单独负责管理测试计划，同时也有 29% 的组织报告称由上述双方共同负责管理此计划。安全分析师在帮助开发人员安全构建 应用程序方面起着主要的作用。78% 的组织报告称，他们的安全分析师直接与开发人员接洽：31% 的安全分析师直接与开发人员合作审查具体功能和相关代码，28% 的 安全分析师与开发人员合作进行威胁建模，还有 19% 的安全分析师会参与每日站会。这种高度参与能够推动双方相互学习与监督，从而确保应用程序得以安全构建。 应用安全测试所有权 安全分析师如何帮助改进项目 Dedicated security analysts assigned to managing application security, 31% Jointly owned by development manager and our application security team, 29% Development managers, 26% Individual developers, 13% We have no formal ownership for application security testing, 1% Our security analysts work directly with developers to review individual features and code, 31% Our security analysts work together with developers to do threat modeling, 28% Our security analysts only monitor the process, without any direct engagement with developers, 22% Our security analyst(s) participate in daily development scrum meetings, 19% We do not have security analysts assigned to work with our development teams, 1% 我们对应用安全测试没有明确的 所有权， 1% 指定负责管理应用安全的安全分 析师， 31% 开发经理和我们的应用程序安全 团队共同所有， 29% 开发经理， 26% 某个开发人员， 13% 我们的安全分析师直接与开发人员合作 审查具体功能和代码， 31% 我们的安全分析师与开发人员合作 进行威胁建模， 28% 我们的安全分析师仅监控流程， 不会直接与开发人员接洽， 22% 我们的安全分析师参与每日站 会， 19% 我们没有指定安全分析师 与开发 团队合作， 1% 1.应用程序安全控制高度集成到 CI/CD 工具链中。 6.追踪各个开发团队引入的安全问题。 2.正式记录应用安全最佳实践。 7.持续改进影响应用安全的正式流程和指标追踪。 3.应用安全培训包含在持续进行的开发安全培训计 划中。 8.追踪各个开发团队的持续改进指标。 4.开发经理负责向开发人员传达最佳实践。 9.在代码开发过程中追踪安全问题。 5.大量开发人员参与到正式的应用安全培训计划中。 10.通过工具自动汇总风险，并让高级开发主管随时了 解情况。 最为 有效的 AppDev安全计划的 10 大要素 返回目录 11 研究重点： 现代应用程序开发安全 The Enterprise Strategy Group, Inc. 版权所有 2020。保留所有权利。 为了确保如今种类繁多的应用程序开 发与部署模型的安全，需要使用各种 各样的安全测试工具。 版权所有。保留所有权利。 各种各样的 AppSec 测试工具正在投入使用 随着应用程序安全日趋成熟，任何单一的测试技术都无法帮助开发团队降低全部安全风险。这就需要安全团队运用通常由多个供应商提供的多种工具来确保 SDLC 的 安全。尽管使用情况各不相同，组织认为最重要的工具也有所不同，但大多数组织最终都会混合使用众多工具来满足他们的安全需求。 随着新的开发和部署模型不断出现，为确保它们的安全性，新的测试工具应运而生。一些工具会融入到规模更大的测试平台中，而另一些则长期独立存在。 应用程序安全测试所有权 15% 16% 29% 29% 36% 38% 38% 40% 40% 56% Container runtime configuration security tools to ensure secure configuration is in place Fuzzing to identify security and stability issues Container/repo/microservices scanning tools to identify component usage and identify vulnerabilities in base images and specific artifacts IDE plugins actively and successfully in use to assist with security issue identification and resolution DAST - dynamic application security testing (DAST) tools to identify and remediate risk in applications IAST - interactive application security testing (IAST) tools to identify and remediate runtime risk in your organizations web-based applications SCA - software composition analysis (SCA) testing tools to identify open source component usage and associated vulnerabilities SAST - static application security testing (SAST) tools to identify and remediate vulnerabilities within your organizations source code Infrastructure-as-code security tools to protect against misconfigurations, policy violations, threats, and IAM challenges API security vulnerability (ASV) scanning to identify and mitigate risk associated with API usage, including serverless APIs API 安全漏洞 (ASV) 扫描，可识别并降低与使用包括无服务器 API在内的 API 相关的风险， 基础设施即代码安全工具，可防止配置错误、违反策略、威胁以及 IAM 挑战 SAST - 静态应用安全测试 (SAST) 工具，可识别并修复组织源代码中的漏洞 SCA - 软件分析 (SCA) 测试工具，可识别开源组件的使用情况和相关漏洞 IAST - 交互式应用安全测试 (IAST) 工具，可识别并修复组织基于 Web 的应用程序的运行时风险 DAST - 动态应用安全测试 (DAST) 工具，可识别并修复应用程序的风险 IDE 插件主动部署并成功地使用有助于识别并解决安全问题 容器 /仓库 /微服务扫描工具，可识别组件的使用情况以及基础镜像和特定制品的漏洞 模糊测试，可发现安全和稳定性方面的问题 容器运行时配置安全工具，可确保实施安全配置 现代代码库严重依赖开源代码，但是目前运用开源安全控制的代码库不足一半 尽管各种类型的测试工具已经存在多年，但采用程度还不理想。例如，尽管在现代应用程序开发中使用开源软件至关重要，但是目前报告使用针对开源安全测试工具的开发 团队仍然不足一半。虽然许多团队有这样的计划，但这一不确定的趋势也表明了当下众多公司目前对应用安全测试工具的采用情况。 48% 投资于特定的安全控制 手段针对开源代码漏洞 扫描。 48+52+R 从开源代码中拉取的代码库所占 百分比 4% 16% 37% 35% 8% 0% (i.e., we dont use open source) 1% to 25% 26% to 49% 50% to 75% 76% to 100% 0%（例如：我们不 使用开源代码） 1% 至 25% 26% 至 49% 50% 至 75% 76% 至 100% 微服务容器开发势头强劲 在某些情况下，更现代化的开发和部署模型会更早开始注重安全程度。在这里我们看到微服务容器开发在相对短的时间内已经得到了广泛采用，特定安全控制手段也随之 而来。其他云开发和部署模型也采用了类似模式。 使用容器的开发团队所占百分比 确保容器安全的控制手段 1% 4% 20% 40% 27% 7% 1% None 1% to 9% 10% to 25% 26% to 50% 51% to 75% 76% to 100% Dont know 3% 42% 45% 51% 54% We arent using any specific controls yet to secure container/microservices development We are scanning configuration and deployment scripts to identify misconfiguration issues We are modeling the expected behavior of microservices and utilizing behavioral monitoring tools to identify drift We are monitoring container deployment environments for configuration issues We are using automated controls to identify and quarantine/block vulnerable images in our image repository 返回目录The Enterprise Strategy Group, Inc. 版权所有 2020。保留所有权利。 0% 1% 至 9% 10% 至 25% 20% 至 50% 51% 至 75% 76% 至 100% 不知道 我们正在使用自动控制手段在镜像仓库中识别并隔离 /阻断易 受攻击的镜像 我们正在监控容器部署环境以解决配置问题 我们正在对微服务预期行为进行建模并利用行为监控工具识 别偏差 我们正在扫描配置和部署脚本，以便识别错误配置问题 我们尚未实施任何手段来确保容器 /微服务开发的安全 目前测试工具面临的挑战 已识别的安全问题归根结底需要由开发人员来解决，然而， 大多数组织报告称目前工具使用所面临最普遍的挑战是：开 发人员缺乏使用工具解决安全问题的知识。安全工具供应商 会推出即时的培训或推荐修复方案来为开发人员提供指导， 但是最终还是需要开发人员来完成这项工作。开发人员越能 充分理解某些代码引入问题的方式和原因就越能减少问题 产生，因此为提供开发人员安全培训应当能逐步解决此类问 题。 还有一些组织在集成其它 AppSec 工具方面费尽心思，而大 多数人还是担心 AppSec 添加的阻力会拖慢整个开发进程。 目前测试工具面临的主要挑战 14% 15% 15% 18% 20% 23% 24% 24% 26% 26% 29% Too many false negatives Poor automation support Too many false positives Scans too slow Lack of a centralized reporting and management dashboard/console for vulnerability management Poor integration with development/DevOps tools Lack of ability to aggregate and dedupe findings from the various security tools Developers are not utilizing tools weve invested in effectively Adds friction and slows down our development cycles Difficulty or lack of integration between different application security vendor tools Developers lack the knowledge to mitigate issues identified开发人员缺乏应对已识别问题的知识 不同供应商的应用安全工具集成困难或没有集成 增加了阻力并拖慢了开发进度 开发人员没有有效利用我们投资的工具 缺乏从各种安全工具汇总结果并去重的能力 开发 / DevOps 工具集成效果不佳 缺乏用于管理漏洞的集中报告和管理仪表板 /控制台 自动化支持不佳 误报过多 扫描速度过慢 漏报过多 16 DevOps 集成对于改善应用安全计划至关重要 大部分参与调查人员认为，如果项目能够获得成功最重要是得益于在整个 SDLC 中自动执行应用安全测试。DevOps 集成减少了阻力并尽早注重安全问题，可帮助组织尽早 识别安全问题。尽管开发人员的培训与工具和流程的改进无疑也会改进项目，但自动化仍是现代应用程序开发实践的重中之重。 DevOps 和 AppSec 集成水平 56% 38% 5% 1% We utilize a highly integrated set of security controls throughout our DevOps process We use selective controls, but continue to invest in integrating additional controls Our application security tools are not well integrated into our processes We are pushing security as far left as possible in our processes 56% 38% 5% 1% We utilize a highly integrated set of security controls throughout our DevOps process e use selective controls, but continue to vest in integrating additional controls Our application security tools are not well integrated into our processes We are pushing security as far left as possible in our processes 43% 的组织认为 DevOps 集成 对于改进 AppSec 项目至 关重要。 我们在整个 DevOps 流程中使用了一系列 高度集成的安全手段 我们对安全手段选择性使用，但还会继续 集成其它安全手段 我们的应用安全工具没有很好地 集成到流程中 我们尽可能把安全推进到 更早的阶段 返回目录 17 研究重点： 现代应用程序开发安全 The Enterprise Strategy Group, Inc. 版权所有 2020。保留所有权利。 开发人员安全培训质 量参差不齐，缺乏提高 开发人员安全技能的 计划。 大多数组织都要求开发 人员参加 AppSec 培训 大多数组织都要求开发人员参与一定量 的应用安全培训，但是有 35% 的组织表 示，参与正式培训的开发团队不足一半。 仅有 15% 的组织表示，所有开发人员都会 参与培训。至于参与培训的频率，不足一 半的组织要求开发人员每年参与一次以 上的正式培训。 参与正式安全培训的开发人员所占的 百分比 应用程序开发人员的安全培训要求 Developers are only required to participate in training on an annual basis, 17% Developers are required to participate in training at least once per quarter, 29% We only provide security training when developers join the team, 20% Our developers utilize just-in-time training available from within our security tools, 17% Developers are expected to self- educate on application security, 16% We have no security training for developers, 1% 7% 28% 50% 15% Less than 25% 25% to 50% 51% to 75% 76% to 100% 不到 25% 25% 至 50% 51% 至 75% 76% 至 100% 开发人员仅需要每年参加一次培训， 17% 开发人员每季度至少需要参加一次培训， 29% 开发人员没有安全培 训， 1% 开发人员应该自学关于应用安全的 知识， 16% 我们的开发人员利用安全工具中提供的即 时培训， 17% 我们仅在开发人员加入团队时提供安全 培训， 20% 大多数组织缺乏衡量开发人员 安全培训效果的计划 持续改进安全计划要求衡量开发团队和单个开发人 员引入问题的情况。稍多于 40% 的组织报告称，他 们会同时追踪问题引入和持续改进指标，从而有针 对性地改进那些引入问题最多的团队和单个开发人 员。 如何衡量应用程序开发团队的安全培训效果 2% 28% 32% 37% 38% 41% 42% We dont measure training efficacy Issue introduction is tracked at the company level Issue introduction is tracked for each developer Testing from within our training tools Continuous improvement metrics are tracked for each developer Continuous improvement metrics are tracked for each development team Security issue introduction is tracked for each of our development teams 追踪各个开发团队引入的安全问题 追踪各个开发团队的持续改进指标 追踪各个开发人员的持续改进指标 在我们的培训工具中进行测试 追踪每位开发人员引入的问题 追踪整个公司层面引入的问题 我们不衡量培训效果 返回目录 20 研究重点： 现代应用程序开发安全 The Enterprise Strategy Group, Inc. 版权所有 2020。保留所有权利。 AppSec 测试工具激 增为许多人带来了问 题，超过三分之一的人 将投资重点放在了整 合上。 AppSec 工具激增推动组织投资于工具整合 与其他类别的安全控制相似，许多组织使用了太多工具，以致于他们难以集成和管理它们。这往往会导致降低计划的有效程度，并需要安排过多资源来管理工具。72% 的组织 使用的工具超过十种，复杂性成为了一个关键问题。 使用的 AppSec 工具数量 工具数量激增本身带给组织的问题 8% 21% 43% 22% 5% 1% 1 to 5 6 to 10 11 to 20 21 to 50 More than 50 Dont know 30% 54% 16% Significant problem we are overwhelmed with the number of tools in use Minor problem While sometimes challenging, we are happy with the number of tools in use Not a problem we prefer a best-of- breed, and are happy with the number of tools in use 1 至 5 款 6 至 10 款 11 至 20 款 21 至 50 款 超过 50 款 不知道 严重问题 使用大量工具让我们不 堪重负 小问题 尽管使用大量工具有时候富 有挑战，但我们对此感到满意 这不是问题 我们更喜欢同类最佳工 具，并且对于使用大量工具感到满意 返回目录 22 研究重点： 现代应用程序开发安全 The Enterprise Strategy Group, Inc. 版权所有 2020。保留所有权利。 各个组织都在投资，超过半 数的组织都计划较前一年相 比，大幅增加在应用安全方 面的支出。