本文对比了Contrast Security的两份报告，探讨了应用安全在DevSecOps中的演进。报告指出，传统的应用安全方法在应对现代软件的复杂性和分布式特性时面临挑战，如开发人员修复漏洞时间有限、工具割裂等。文章强调了从“左移”到“右移”的转变，即在运维和测试阶段解决代码安全问题，并强调了安全在DevOps中的重要性，以及需要全面的安全措施，包括漏洞识别、软件成分分析、运行时保护等，以提升应用安全性。

🛡️ 传统应用安全方法难以应对现代软件的复杂性和分布式特性，导致开发人员修复漏洞的时间有限，漏洞积压增加。

🛠️ 组织需使用多种工具来实现全面的DevSecOps模型，但工具的割裂增加了开发团队的学习曲线和操作难度，安全反馈也难以与开发人员的工作流程集成。

📉 现有的应用程序安全指标，如扫描次数和发现的漏洞数量，并不能有效降低风险。更快的修复时间和更低的安全债务是衡量应用安全成熟度的关键指标。

🔄 鉴于“左移”在实践中遇到的问题，安全策略应在DevOps的各个阶段实施，强调安全是DevOps的内生部分，而非简单的“左移”或“右移”。

✅ 现代应用安全方案应涵盖漏洞识别与分析、软件成分分析(SCA)、运行时保护、风险态势、报告和合规、企业准备、开发人员经验和平台要求等多个方面，以实现全面的安全覆盖。

‍‍写在前面：ContrastSecurity是一家著名的开发安全厂商，技术强项是运行时安全，也就是IAST和RASP。这是它的一个报告，算是对开发平台产品功能的一个总结吧。本文包括2021和2022年两个版本，主要是想看看他们之间的变化。

开发安全领域，前端时间一直提“左移”，以降低修复代码漏洞的成本，但效果怎么样呢？估计不是太好，因为开发人员过于疲劳，所以现在又开始提“右移”，在运维和测试阶段解决代码安全问题。

其实问题就在那里，怎么合适就怎么解决。

DevSecOps购买指南：应用安全

ContrastSecurity  2021年1月

总纲

        随着应用程序变得更加复杂和分布式，传统应用程序安全的有效性在几个关键领域已经落后了，包括在软件开发期间减少漏洞、跟踪开源软件(OSS)风险和保护开发后发布的应用程序。这使得企业软件工厂比以往任何时候都更加容易受到攻击。难怪web应用程序攻击同比增长56%。此外，我们看到软件供应商和供应链的攻击激增，针对云原生应用程序基础设施的威胁也在增加。

       选择一个有效的应用程序安全测试方案应该基于现代软件的特定需求，集成于软件开发生命周期(SDLC)中的任何阶段，除了修复漏洞外，还要关注漏洞的发现和测试。核心能力包括漏洞识别标准、软件成分分析、运行时保护和合规等。本文档可作为提案请求(RFP)或应用程序安全供应商选择的模板。

目录

01 多样的工具，误导的控制，错误的指标

02 度量现代应用程序安全

03 附录：评估和购买现代开发平台

•漏洞识别和分析

•软件成分分析(SCA)

•运行时保护

•风险态势

•报告和合规

•企业准备

•开发人员经验

•平台要求

01 多样的工具、误导的控制、错误的指标

       软件工厂比以往任何时候都更加脆弱。传统的应用程序安全测试方法已经跟不上现代应用程序的规模和复杂性。这导致了当今DevOps环境中的一些严重问题：

开发人员修复漏洞的时间有限

       随着交付周期的压力越来越大，开发人员发现和修复应用程序漏洞的能力有限。代码量增加，发现的漏洞积压也会增加。在生产环境中运行的应用程序也会接连暴露漏洞，几乎所有(99%以上)的组织都报告说，他们生产环境中的应用程序有四个或更多的漏洞。

       齐心协力修复使企业面临风险的漏洞，并“偿还”其安全债务，是企业可以采取的最有力的单一行动，以减少事件的可能性。

多样的、割裂的工具

       组织必须使用各种不同的工具来实现全面的DevSecOps模型：扫描开源组件(SCA)、测试开发中的应用程序(静态应用程序安全测试，动态应用程序安全测试，交互式应用程序安全测试)、以及防止生产中的攻击(web应用程序防火墙)。这为开发团队创造了一个更陡峭的学习曲线和低操作性。更糟糕的是，应用程序安全通常没有与开发人员使用的各种部署、构建和测试工具集成。此外，开发人员通常会在他们自己的工作流程之外获得安全反馈，并且完全脱离工作环境。他们必须停止当前项目的工作，返回前面的代码进行故障排除，这个问题被称为“工作来回切换”。

       超过一半的组织表示，他们的安全团队已经达到了一个临界点，安全工具的数量对他们的安全现状产生了不利影响，并增加了风险。

毫无意义的指标

       目前用于评估应用程序安全成功与否的典型指标导致误导，因为它们实际上并没有降低风险。这些衡量指标可能包括执行的扫描次数、测试的应用程序数量和/或发现的漏洞数量。但是，通过最重要的修复角度来看，这些现有工具中的大多数都失效了。

       修复漏洞数量和平均修复时间(MTTR)都是有效的应用程序安全的真实度量。这些指标为应用安全程序的成熟度提供了强有力的指标；更快的修复时间转化为组织更低的风险和更低的安全债务。拥有更多安全债务(即，更多未修复的漏洞)的企业会进一步落后，并且会经历更多的漏洞，比安全债务低于平均水平的企业高1.7倍，其结果是应用程序安全风险的持续升级，更不用说成本了。

       随着开发过程离错误产生的地方越来越远，修复漏洞的成本也越来越高，对于一个主要的应用程序安全厂商来说，目前的平均修复时间是171天。

02度量现代应用程序安全

       一个适用于现代开发环境(例如，DevOps, Agile)有效的应用程序安全测试方案需要包括对组织的几个重要收益：

针对修复进行优化(包括修复的漏洞数量和平均修复时间)
在应用程序、应用程序组合、业务单元或公司层面度量风险和降低风险
在整个SDLC中有完整的覆盖
适应现代技术和传统技术
在开发周期的所有阶段，任何技术资源都可以使用

       随着企业寻求替换过时的应用程序安全测试工具，并开始通过降低风险而不是覆盖范围来度量他们的程序，他们可以基于以下类别的标准来评估现代应用程序安全方案(参见附录)：

漏洞识别和分析
软件组合分析(SCA)
运行时保护
风险姿势
报告和合规
企业准备
开发人员经验
平台要求

从设计到生产实现安全覆盖

       选择一个现代的、有效的DevSecOps平台可以帮助组织通过实时发现更多的实际缺陷来理顺他们的持续集成/持续部署(CI/CD)管道。它还可以通过用户友好的“如何修复”指导和预建命令行工具，将开发人员转变为安全专家。最后，它可以提供保护，以确保应用程序安全交付，即使在生产中存在开放或未知的漏洞。

       全面的DevSecOps方法需要应用程序安全和DevOps工具集之间的紧密集成。但45%的组织表示，他们很难确保整个DevOps工具链的安全。

03附录：评估和购买现代DevSecOps平台

       为了使DevSecOps在当今的现代开发环境中有效，它的覆盖范围必须扩展到应用程序的所有部分。这包括自定义代码、开源库、第三方组件以及应用程序编程接口(API)。

       以下清单可以帮助指导组织评估和购买DevSecOps解决方案时，准备提案请求(RFP)材料。

漏洞识别与分析

在开发和测试时为开发人员提供漏洞的可见性
提供在开发人员桌面、安全门和构建阶段进行测试的选项
提供测试客户端和服务器端代码的选项
提供具体的指导，以修复SDLC中的漏洞
衡量程序路径数量，以确定覆盖差距

软件成分分析(SCA)

提供对第三方库(即开源组件)中存在的漏洞的可见性和修复建议
查明潜在的第三方库许可风险和跨应用程序的相关漏洞

运行时保护

在生产环境中保护第三方和自定义开发的应用程序在运行时的漏洞
有效地预防/阻止威胁利用任何现有的代码漏洞
保护应用程序免受OWASP Top10漏洞攻击，如跨站脚本(XSS)， SQL注入(SQLi)，命令注入、XML注入以及其他已知的CVE，而不用打补丁
保护应用程序免受零日攻击，无需修复
包括与常用监控系统的预建集成功能— splunk、Securonix、 AppDynamics等。
提供全面的数据输出(即，时间戳、有效载荷、URL、端口、源/目的IP、违规/事件类型、会话ID、cookie、堆栈跟踪)

风险态势

为应用程序提供风险评分，并跟踪该评分随时间的变化情况
根据组织的其他应用程序组合对风险评分进行基准测试
将第三方/开源库的风险评分从自定义代码的风险评分中分离出来
如果启用运行时保护，调整风险评分

报告和合规

测量漏洞存在和关闭率
测量平均修复时间
衡量针对特定漏洞的攻击
通过策略识别不兼容的应用，如支付卡行业(PCI)， OWASP等。
直接关联美国国家标准与技术研究所(NIST)特别出版物800-37和800-53风险管理指南，和PCI DSS要求第6章，设计和维护安全系统

整合跨多个评估类型和策略的结果
支持在平台内定制报告

‍

企业准备

执行应用程序安全，无需发送应用程序源代码或二进制或字节码到云服务器来完成该过程
为每个应用定义自定义策略
定义策略内的宽限期(即团队在策略失败之前修复的时间)
在企业的任何级别应用策略(即，针对单个团队或业务单元，或跨整个组织)
定义缺陷严重性、类别、常见弱点条目(CWEs)，以及包含策略的标准
在应用程序启动、上传和结果发布阶段提供厂商协助

开发人员的经验

集成bug跟踪系统，聊天工具，票务系统，以及容器化工具(如Docker, Kubernetes)
通过CLI启动评估
扫描公共或私有存储库
检测开发人员桌面的漏洞(例如，集成开发人员环境[IDE])
‍

平台需求

提供单一的平台来管理所有的解决方案，包括应用程序安全测试(自定义代码和开源库)和运行时保护
使用主动攻击信息来规划漏洞修复优先级
使用运行时保护规则防御未打补丁的CVE
使用运行时保护规则来防御开发人员未修复的漏洞
使用运行时保护规则来防御零日漏洞

（完）

DevSecOps购买指南：应用安全

Contrast Security 2023年2月

总纲

       软件工厂比以往任何时候都更加容易受到攻击。传统的应用程序安全测试方法已经无法满足现代应用程序的规模和复杂性。

       随着应用程序变得更加复杂和分布式，传统的应用程序安全有效性在几个关键领域已经落后，包括减少软件开发过程中的漏洞、跟踪开源软件(OSS)风险和保护开发后发布的应用程序。Akamai Industries最近的一份报告显示，应用程序编程接口(API)和web应用程序攻击增加了257%。此外，我们看到在软件供应商和供应链方面的攻击激增，针对云原生应用程序基础设施的威胁也在增加。

       选择有效的应用程序安全测试方案应根据现代软件的具体要求；应该包含在软件开发生命周期(SDLC)的任何阶段；除了修复漏洞外，还必须专注于发现和测试漏洞。核心功能包括漏洞识别标准、软件成分分析(SCA)、运行时保护和合规性等。

       组织必须认识到安全是DevOps不可分割的一部分。虽然将安全转移到开发过程中可能很诱人，但重要的是要理解安全是接下来工作的基本内容，即DevOps的运维部分，要确保性能，弹性和可靠性。阻止和检测必须被视为相互交织和相辅相成的。不幸的是，安全左移方法可能会因为各种原因而失败，包括缺乏安全知识、开发团队工作量过重、糟糕的集成、不一致的优先级或缺乏自动化。

       为了满足法规和客户的需求，组织必须借助安全性透明原则，来确保其软件是安全的。这涉及到采用一种全面的方法，包括进行安全评估、实现安全编码实践，以及部署能够准确识别和减轻安全风险的工具。通过采取这些步骤，组织不仅可以满足法规和客户的需求，还可以在他们开发的软件中建立信任和信心。

       使用此文档作为提案请求(RFP，request for proposal)或应用程序安全供应商选择的模板。

目录

01 开发人员修复漏洞的时间有限

02 聪明的转变：拒绝转移责任

03 开发人员疲劳

04 工具：交付安全的代码，而不是误报

05 增加软件供应商的合规性、信任和透明度

06 度量现代应用程序安全

07 评估现代DevSecOps平台的最佳实践

01 开发人员修复漏洞的时间有限

       第一步：认识到AppSec团队目前面临的最大挑战。它们是:

开发人员修复漏洞的时间有限

       随着加速交付的压力不断增加，开发人员发现和修复应用程序漏洞的能力有限。随着代码量增加，已识别的漏洞积压也会增加。在生产环境中运行的应用程序也会逐渐暴露漏洞，几乎所有组织，超过99%，都报告说，他们在生产环境中的应用程序有四个或更多的漏洞。

       齐心协力修复使企业面临风险的漏洞，并“偿还”其安全债务，是企业可以采取的最有力的单一行动，以减少事件的可能性。

02 聪明的转变：拒绝转移责任

       人们强烈反对把责任过渡左移。我们不应该把大部分的负担放在开发人员身上，而应该把重点放在如何最好地将安全实践集成到应用程序开发过程中。这将涉及各方之间的合作，以确保安全在整个过程中得到考虑和实现。通过采用协作的方法，我们可以创建足够安全且满足所有参与者需求的应用程序。

       安全性必须嵌入到DevOps的每个阶段中，而不仅仅是作为一个单独的存在。这不是把安全左移或右移；相反，它是关于确保安全架构正确地集成到DevOps管道中。公司必须记住，安全是DevOps运营部分的基础，确保性能、弹性和可靠性，并不是所有的安全方面都可以向左移。我们还必须明白，阻止和检测并非相互排斥；相反，它们是相互交织、相互加强的。每一次阻止失败都必须通过检测加以识别和处理。最后，安全是DevOps内生部分，确保在整个DevOps工作流程中正确实现安全性至关重要。

03 开发人员疲劳

       安全团队面临压力，需要提供一种更好的方法将安全集成到他们的开发过程中，但这并不容易。开发人员需要提供一种更透明的方式来保护代码，而不是推进部门直线管理，项目管理和安全团队被推到极限。造成这个问题的一些因素：

缺乏安全知识：安全左移的方法依赖于开发人员拥有必要的安全知识来正确识别和处理安全风险。如果开发人员没有所需的知识，他们可能无法充分保护代码。
开发团队负担过重：如果不能有效地实现安全任务，左移方法会增加开发团队的负担。这可能会给开发人员带来额外的压力，并降低他们的工作效率。
糟糕的集成：如果安全没有正确地集成到开发过程中，可能会导致安全被视为一个单独的、独立的过程。这可能导致安全被忽视，或者被推迟到开发周期的后期。
不一致的优先级：安全可能被视为比其他开发任务的优先级低，从而导致安全被忽视或没有得到充分的处理。
缺乏自动化：如果没有适当的自动化工具，开发人员可能无法快速有效地识别和处理安全风险。这可能导致安全问题被忽视或无法解决。

       68%的事件响应者必须同时防御两种或更多的攻击。

04 工具：交付安全的代码，而不是误报

       大多数应用程序安全工具都会产生很多误报。安全团队需要确保他们的应用程序是安全的，但他们也需要确保他们使用的工具提供了准确的信息。

       安全从来不是非黑即白的问题，但太多误报的最终结果是，它可能导致人们对安全工具失去信任，并混淆哪些风险是真实的、哪些是误报。为了确保安全编写代码，安全团队应该使用专门设计用于消除误报的工具。

       这些工具应该易于使用，提供准确的结果，并提供可操作的指导。通过实现准确识别安全风险的工具，安全团队可以有效地交付安全代码，并与开发人员建立信任。

05 增加软件供应商的合规性、信任和透明度

       为了满足合规和客户的要求，组织必须确保他们的软件是安全的。新的法律法规要求组织使安全更加透明。在美国，联邦政府要求是确保软件安全保障和萨班斯-奥克斯利法案(SOX)风格的认证，而类似于通用数据保护条例(GDPR)的法规正在欧洲、中东和非洲(EMEA)出现。

       政府希望能够更清楚地了解为其应用提供动力的软件的透明性。拜登政府将公布一项国家战略，对国家关键基础设施进行全面的网络安全监管。国防部发布持续操作授权(cATO)框架的更新，要求组织采取持续监控方法，而不是传统的静态方法。这包括采取全面的方法，包括进行安全评估、实施安全编码实践、以及部署能够准确识别和减轻安全风险的工具。

06 现代应用程序安全的度量

       针对现代开发环境(如DevOps、Agile)，一个有效的应用程序安全测试方案需要包括对组织的一些关键好处：

针对修复进行优化(包括修复的漏洞数量和平均修复时间)
衡量应用程序、应用程序组合、业务单元或公司级的风险和风险降低;
完整覆盖整个软件开发生命周期
适用于传统技术和现代技术
在开发周期的所有阶段，任何技术资源都可以使用

       企业希望取代过时的应用程序安全测试工具，并开始通过降低风险而不是覆盖范围来衡量他们的项目，他们可以根据以下类别的标准评估现代应用程序安全解决方案：

漏洞识别和分析
软件成分分析(SCA)
运行时保护
风险态势
报告和合规
企业准备
开发人员经验
平台要求

从设计到生产的安全覆盖

       选择一个现代的、有效的DevSecOps平台可以帮助组织实时发现更多真正的缺陷来理顺他们的持续集成/持续部署(CI/CD)管道。它还可以通过用户友好的“如何修复”指南和预建的命令行界面(CLI)工具将开发人员转变为安全专家。最后，它可以提供保护，以确保应用程序安全交付，即使在生产环境中存在开放或未知的漏洞。

       全面的DevSecOps方法需要应用程序安全和DevOps工具集之间的紧密集成。但45%的组织表示，他们很难确保整个DevOps工具链的安全。

07 评估现代DevSecOps平台的最佳实践

       为了使DevSecOps在当今的现代开发环境中有效，它的覆盖范围必须扩展到应用程序的所有部分。这包括自定义代码、开源库、第三方组件和应用程序编程接口(API)。

       下面的清单可以帮助指导组织在评估和购买DevSecOps解决方案时，准备提案请求(RFP)。

漏洞识别与分析

在开发和测试时为开发人员提供漏洞的可见性
提供在开发人员桌面、安全门和构建阶段进行测试的选项
提供测试客户端和服务器端代码的选项
提供具体的指导，以修复SDLC中的漏洞
衡量现有程序路径数量，以确定覆盖差距

软件成分分析(SCA)

提供对第三方库(即开源组件)中存在的漏洞的可见性和修复建议
查明潜在的第三方库许可风险和跨应用程序的相关漏洞

运行时保护

在生产环境中保护第三方和自定义开发的应用程序在运行时的漏洞

有效地预防/阻止威胁利用任何现有的代码漏洞
保护应用程序免受OWASP Top10漏洞攻击，如跨站脚本(XSS)、SQL注入(SQLi)、命令注入、XML注入和其他已知CVE，而不用打补丁
保护应用程序免受零日攻击，无需修复
包括与常用监控系统的预集成功能— Splunk、Securonix、AppDynamics等
提供全面的数据输出(即，时间戳、有效载荷、URL、端口、源/目的IP、违规/事件类型、会话ID、cookie、堆栈跟踪)

风险态势

为应用程序提供风险评分，并跟踪该评分随时间的变化情况
组织的其他应用程序组合对风险评分进行基准测试
将第三方/开源库的风险评分从自定义代码的风险评分中分离出来
如果启用运行时保护，调整风险评分

报告和合规

度量漏洞存在和关闭率
度量平均修复时间
度量针对特定漏洞的攻击
根据策略识别不合规的应用程序，如支付卡行业(PCI)、 OWASP等。
直接关联美国国家标准与技术研究院(NIST)特别出版物800-37和800-53风险管理指南，和PCI DSS要求第6章，设计和维护安全系统
整合跨多个评估类型和策略的结果
支持在平台内定制报告

企业准备

实现应用程序安全，无需发送应用程序源代码或二进制或字节码到云服务器来完成该过程
为每个应用自定义策略
定义策略内的宽限期(即团队在策略失败之前修复的时间)
在企业的任何级别应用策略(即，针对单个团队或业务单元，或跨整个组织)
定义缺陷严重性、类别、CWE和组成策略的标准
在应用程序启动、上传和结果发布阶段提供厂商协助

开发人员的经验

集成bug跟踪系统，聊天工具，票务系统以及容器化工具(如Docker, Kubernetes)
通过CLI启动评估
扫描公共或私有存储库
检测开发人员桌面的漏洞(例如，集成开发人员环境[IDE])

平台需求

提供单一平台来管理所有的解决方案，包括应用程序安全测试(自定义代码和开源库)和运行时保护
使用主动攻击信息来定义漏洞修复优先级
使用运行时保护规则防御未打补丁的CVE
使用运行时保护规则来防御开发人员未修复的开放漏洞
使用运行时保护规则来防御零日漏洞

（完）

📍发表于：中国 北京