文章总结： 应用程序安全风险需结合业务背景评估，OWASPTop10基于发生率、可利用性及影响数据排名，风险公式整合发生率、覆盖率、漏洞利用与影响评分。建议建立基于风险的投资组合方法，将安全融入SDLC，使用OWASPSAMM/DSOMM评估成熟度，实施持续测试与监控，并通过安全教育和管理层可视性推动改进。 综合评分： 87 文章分类： 应用安全,漏洞分析,安全建设,安全运营,数据安全

【接上文】应用程序安全风险及管理计划

原创

破天KK

KK安全说

2025年11月22日 11:22 北京

什么是应用程序安全风险？

攻击者可能利用应用程序中的多种不同路径对您的企业或组织造成损害。每一种路径都存在潜在风险，需要进行调查。

| | | | | | | | — | — | — | — | — | — | | 威胁代理人 | 攻击向量 | 可利用性 | 安全漏洞的可能性 控制 | 技术的 影响 | 商业 影响 | | 通过环境，动态地，通过情境图景 | 按应用暴露程度（按环境） | 平均加权漏洞利用 | 缺失对照 \ 按平均发生率 \ 按覆盖率加权 | 平均加权影响 | 按业务 |

在我们的风险评级中，我们考虑了漏洞利用的普遍参数、漏洞安全控制措施缺失的平均可能性及其技术影响。

每个组织都是独一无二的，其面临的威胁行为者、目标以及任何安全漏洞的影响也各不相同。例如，如果一个公共利益组织使用内容管理系统 (CMS) 管理公共信息，而一个医疗系统使用完全相同的 CMS 管理敏感的健康记录，那么即使使用相同的软件，威胁行为者和业务影响也可能截然不同。因此，至关重要的是，要根据应用程序的暴露情况、适用的威胁主体（按业务和地点划分的定向攻击和非定向攻击）以及具体的业务影响，来了解组织面临的风险。

数据如何用于选择类别和进行排名

2017年，我们根据漏洞发生率选择类别以确定其可能性，然后根据团队数十年的经验，通过讨论对漏洞的可利用性、可检测性（也包括可能性）和技术影响进行排名。2021年，我们使用了国家漏洞数据库（NVD）中CVSSv2和CVSSv3评分的数据来评估漏洞的可利用性和（技术）影响。2025年，我们沿用了2021年制定的方法。

我们下载了 OWASP Dependency Check，并提取了按相关 CVE 分组的 CVSS 漏洞利用和影响评分。由于所有 CVE 都只有 CVSSv2 评分，而 CVSSv2 存在一些缺陷，需要 CVSSv3 来解决，因此这项工作耗费了不少时间和精力。在某个时间点之后，所有 CVE 都会被分配一个 CVSSv3 评分。此外，CVSSv2 和 CVSSv3 之间的评分范围和公式也进行了更新。

在 CVSSv2 中，漏洞利用和（技术）影响的最高分均为 10.0，但根据公式计算，漏洞利用的权重会分别降至 60% 和 40%。在 CVSSv3 中，漏洞利用的理论最高分被限制为 6.0 和 4.0。考虑到权重调整，在 CVSSv3 中，影响评分平均提高了近 1.5 分，而漏洞利用评分平均降低了近 0.5 分（以 2021 年十大漏洞分析为例）。

从OWASP依赖性检查工具中提取的CVE到国家漏洞数据库（NVD）中CWE的记录约为17.5万条（2021年为12.5万条）。此外，还有643个不同的CWE映射到CVE（2021年为241个）。在提取的近22万个CVE中，16万个具有CVSS v2评分，15.6万个具有CVSS v3评分，6千个具有CVSS v4评分。许多CVE具有多个评分，因此总数超过22万。

对于 2025 年十大漏洞，我们按以下方式计算了平均漏洞利用和影响评分。我们将所有具有 CVSS 评分的 CVE 按 CWE 分组，并根据 CVSSv3 评分的漏洞数量百分比以及 CVSSv2 评分的漏洞数量百分比，对漏洞利用和影响评分进行加权，从而得到总体平均值。我们将这些平均值映射到数据集中的 CWE，用作风险方程另一半的漏洞利用和（技术）影响评分。

你可能会问，为什么不使用 CVSS v4.0？这是因为评分算法发生了根本性的变化，它不再像 CVSSv2 和 CVSSv3 那样能够轻松地提供漏洞利用或影响评分。我们会尝试在未来版本的 Top Ten 中采用 CVSS v4.0 评分，但目前还无法在 2025 年版中及时找到解决方案。

对于发生率，我们计算了在一段时间内，组织测试的应用程序群体中，存在每种 CWE 漏洞的应用程序所占的百分比。需要注意的是，我们不使用频率（即问题在应用程序中出现的次数），而是关注在应用程序群体中发现每种 CWE 漏洞的应用程序所占的百分比。

为了衡量覆盖率，我们考察所有组织针对特定 CWE 测试过的应用程序的百分比。计算出的覆盖率越高，就越能保证发生率的准确性，因为样本量更能代表总体。

本次迭代使用的公式与 2021 年类似，但权重有所调整：（最大发生率 % * 1000）+（最大覆盖率 % * 100）+（平均漏洞利用次数 * 10）+（平均影响程度 * 20）+（总发生次数 / 10000）= 风险评分

计算出的分数范围从“访问控制故障”类别的 621.60 到“内存管理错误”类别的 271.08。

这套系统并不完美，但对于风险等级的划分很有价值。

另一个日益严峻的挑战是“应用程序”的定义。随着行业向微服务架构和其他规模小于传统应用程序的实现方式转变，计算变得更加复杂。例如，如果一个组织正在测试代码库，它如何定义一个应用程序？与 CVSSv4 的发展类似，下一版十大漏洞评估报告可能需要调整分析和评分方法，以适应不断变化的行业环境。

数据因素

前十大类别均列出了相应的数据因素，以下是这些因素的含义：

CWE 映射： Top Ten 团队将 CWE 映射到某个类别的数量。

发生率：发生率是指该组织当年测试的群体中，易受该 CWE 漏洞影响的应用程序所占的百分比。

加权漏洞利用：将 CVSSv2 和 CVSSv3 分数中的漏洞利用子分数分配给 CVE，映射到 CWE，进行归一化，并放在 10 分制量表上。

加权影响：将 CVSSv2 和 CVSSv3 评分中分配给 CVE 的影响子评分映射到 CWE，进行标准化，并采用 10 分制。

（测试）覆盖率：所有组织针对给定 CWE 测试的应用程序百分比。

总发生次数：已找到的将 CWE 映射到某个类别的应用程序总数。

CVE 总数： NVD 数据库中映射到某个类别的 CWE 的 CVE 总数。

公式：（最大发生率 % * 1000）+（最大覆盖率 % * 100）+（平均漏洞利用次数 * 10）+（平均影响次数 * 20）+（总发生次数 / 10000）= 风险评分

建立现代应用程序安全计划

OWASP Top Ten 列表是旨在提高人们对特定主题下最关键风险认识的意识文档。它并非完整列表，而只是一个起点。在之前的版本中，我们已将启动应用程序安全计划作为避免这些风险及其他风险的最佳方法。本节将介绍如何启动和构建现代化的应用程序安全计划。

如果您已经拥有应用程序安全计划，不妨考虑使用OWASP SAMM（软件保障成熟度模型）或 DSOMM（DevSecOps 成熟度模型）对其进行成熟度评估。这些成熟度模型全面而详尽，可以帮助您确定在扩展和完善计划方面应该重点关注哪些方面。请注意：您无需完全按照 OWASP SAMM 或 DSOMM 中的所有内容进行操作才能做好，它们旨在为您提供指导和多种选择。它们并非旨在提供无法达到的标准或描述成本过高的计划。它们之所以内容丰富，是为了给您提供多种思路和选择。

如果您正在从头开始制定计划，或者您发现 OWASP SAMM 或 DSOMM 目前对您的团队来说“太难了”，请查看以下建议。

1. 建立基于风险的投资组合方法：

• 从业务角度确定应用程序组合的保护需求。这部分应由隐私法和与受保护数据资产相关的其他法规驱动。
• 建立一套通用的风险评级模型，该模型包含一组一致的可能性和影响因素，能够反映贵组织对风险的承受能力。
• 据此对所有应用程序和 API 进行评估和优先级排序，并将结果添加到配置管理数据库 (CMDB)中。
• 制定保证准则，以正确定义所需的保障范围和严格程度。

2. 打好坚实的基础：

• 制定一套重点明确的政策和标准，为所有开发团队提供应用程序安全基线。
• 定义一套通用的可重用安全控制措施，作为这些策略和标准的补充，并为它们的使用提供设计和开发指导。
• 建立一套针对不同开发角色和主题的、必要的应用程序安全培训课程。

3. 将安全措施融入现有流程：

• 将安全实施和验证活动纳入现有开发和运营流程中。
• 活动包括威胁建模、安全设计和设计审查、安全编码和代码审查、渗透测试和补救措施。
• 为开发和项目团队提供领域专家和支持服务，以帮助他们取得成功。
• 审查您当前的系统开发生命周期和所有软件安全活动、工具、策略和流程，然后将其记录下来。
• 对于新软件，请在系统开发生命周期 (SDLC) 的每个阶段添加一项或多项安全活动。以下我们提供了一些建议，供您参考。务必在每个新项目或软件计划中执行这些新活动，这样才能确保交付的每个新软件都具备组织可接受的安全级别。
• 选择合适的活动，确保最终产品符合贵组织可接受的风险水平。
• 对于现有软件（有时称为遗留软件），您需要制定正式的维护计划，请参阅下文“运营和变更管理”部分，了解如何维护安全应用程序。

4. 应用安全教育：

• 不妨考虑启动一个安全倡导者计划，或者面向开发人员的通用安全教育计划（有时也称为安全倡导或安全意识计划），让他们掌握您希望他们了解的一切。这将帮助他们及时了解最新知识，掌握安全的工作方法，并营造更积极的工作安全文化。此外，它通常还能增进团队间的信任，建立更和谐的工作关系。OWASP 通过不断完善的《OWASP 安全倡导者指南》为您提供支持。
• OWASP 教育项目提供培训资料，帮助开发人员了解 Web 应用程序安全。如需进行漏洞方面的实践学习，请尝试OWASP Juice Shop 项目或OWASP WebGoat。为了保持知识更新，您可以参加OWASP AppSec 大会、OWASP 大会培训或当地OWASP 分会会议。

5. 提供管理层可视性：

• 运用指标进行管理。根据收集到的指标和分析数据来推动改进和资金决策。指标包括安全实践和活动的遵守情况、引入的漏洞、已缓解的漏洞、应用程序覆盖率、按类型和实例数量划分的缺陷密度等。
• 分析实施和验证活动的数据，找出根本原因和漏洞模式，从而推动企业范围内的战略性和系统性改进。从错误中吸取教训，并提供积极的激励措施来促进改进。

建立并使用可重复的安全流程和标准安全控制措施

需求和资源管理阶段：

• 与业务部门收集并协商应用程序的业务需求，包括所有数据资产的保密性、真实性、完整性和可用性方面的保护要求，以及预期的业务逻辑。
• 编制技术需求，包括功能性和非功能性安全需求。OWASP 建议您使用 [OWASP 应用程序安全验证标准 (ASVS) (https://owasp.org/www-project-application-security-verification-standard/)] 作为指导，来设定应用程序的安全需求。
• 制定并协商涵盖设计、建造、测试和运营（包括安全活动）各个方面的预算。
• 在项目进度计划中加入安全保障活动。
• 在项目启动会上自我介绍，表明你是安保代表，以便他们知道该和谁交谈。

征求建议书（RFP）和合同签订：

• 与内部或外部开发人员协商需求，包括有关安全计划的指导方针和安全要求，例如软件开发生命周期 (SDLC) 和最佳实践。
• 评估所有技术要求的完成情况，包括规划和设计阶段。
• 协商所有技术要求，包括设计、安全和服务级别协议（SLA）。
• 采用模板和清单，例如OWASP 安全软件合同附件(1)。1 ：请注意 ，该附件适用于美国合同法，因此在使用示例附件之前，请咨询合格的法律顾问。

规划设计阶段：

• 与开发商和内部股东（例如安全专家）协商规划和设计。
• 根据防护需求和预期威胁级别，制定相应的安全架构、控制措施、应对措施和设计评审方案。这项工作应由安全专家提供支持。
• 与其事后在应用程序和 API 中添加安全措施，不如从一开始就将安全性融入设计，这样更具成本效益。OWASP 推荐使用OWASP 速查表和OWASP 主动控制措施作为指导，了解如何从一开始就将安全性融入设计。
• 执行威胁建模，请参阅OWASP 速查表：威胁建模。
• 教导你的软件架构师安全的设计理念和模式，并要求他们尽可能地将这些理念和模式应用到他们的设计中。
• 与开发人员一起检查数据流。
• 将安全用户故事添加到所有其他用户故事中。

安全开发生命周期：

• 为了改进贵组织在构建应用程序和 API 时所遵循的流程，OWASP 推荐使用OWASP 软件保障成熟度模型 (SAMM)。该模型可帮助组织制定并实施针对其面临的特定风险的软件安全策略。
• 为您的软件开发人员提供安全编码培训，以及您认为有助于他们创建更强大、更安全的应用程序的任何其他培训。
• 代码审查，请参阅OWASP 速查表：安全代码审查。
• 给你的开发人员安全工具，然后教他们如何使用这些工具，特别是静态分析、软件成分分析、密钥和基础设施即代码 (IaC)扫描器。
• 如果可能，为开发人员创建护栏（技术保障措施，引导他们做出更安全的选择）。
• 构建强大且易用的安全控制并非易事。应尽可能提供安全的默认设置，并尽可能创建“铺好的路”（即让最简单的方法也成为最安全的方法，成为显而易见的首选方法）。OWASP安全指南是开发人员的良好起点，许多现代框架现在都自带标准且有效的安全控制，用于授权、验证、CSRF 防护等。
• 为您的开发人员提供与安全相关的 IDE 插件，并鼓励他们使用这些插件。
• 向他们提供秘密管理工具、许可证以及使用说明文档。
• 为他们提供一个私有的AI系统，理想情况下，该系统应配备一个RAG服务器，其中包含丰富的实用安全文档、团队编写的用于提升性能的提示信息，以及一个MCP服务器，用于调用贵组织选择的安全工具。教会他们如何安全地使用AI，因为不管你喜不喜欢，他们都会这么做。

建立持续的应用安全测试：

• 测试技术功能及其与 IT 架构的集成，并协调业务测试。
• 从技术和业务角度创建“使用”和“滥用”测试用例。
• 根据内部流程、保护需求以及应用程序假定的威胁级别来管理安全测试。
• 提供安全测试工具（模糊测试器、分布式安全测试工具等）、安全的测试环境以及使用培训，或者代为进行测试，或者聘请测试人员。
• 如果您需要高度的保证，请考虑进行正式的渗透测试，以及压力测试和性能测试。
• 与开发人员合作，帮助他们根据错误报告确定需要修复的内容，并确保他们的经理给他们时间来完成这项工作。

推出：

• 将应用程序投入运行，并根据需要从以前使用的应用程序进行迁移。
• 完成所有文档，包括变更管理数据库（CMDB）和安全架构。

运营与变革管理：

• 操作必须包含应用程序安全管理指南（例如补丁管理）。
• 提高用户的安全意识，并解决可用性与安全性之间的冲突。
• 计划和管理变更，例如迁移到应用程序或其他组件（如操作系统、中间件和库）的新版本。
• 确保所有应用都已列入清单，并记录所有重要细节。更新所有文档，包括配置管理数据库 (CMDB) 和安全架构、控制措施和应对措施，以及任何运行手册或项目文档。
• 对所有应用程序执行日志记录、监控和警报功能。如果缺少此功能，请添加。
• 建立高效的更新和补丁流程。
• 制定定期扫描计划（最好包括动态扫描、静态扫描、密钥扫描、IaC 扫描和软件成分分析）。
• 修复安全漏洞的服务级别协议 (SLA)。
• 为员工（最好也包括客户）提供报告漏洞的途径。
• 建立一支训练有素的事件响应团队，了解软件攻击的特征和可观测性工具。
• 运行拦截或防护工具来阻止自动化攻击。
• 每年（或更频繁地）对设施进行加固。
• 至少每年进行一次渗透测试（具体取决于您的应用程序所需的安全级别）。
• 建立流程和工具，以加强和保护您的软件供应链。
• 建立并更新业务连续性和灾难恢复计划，其中包括您最重要的应用程序以及您用于维护这些应用程序的工具。

退役系统：

• 任何必要的数据都应存档。所有其他数据都应安全擦除。
• 安全地停用该应用程序，包括删除未使用的帐户、角色和权限。
• 在 CMDB 中将应用程序状态设置为“已停用”。

以OWASP Top 10为标准

OWASP Top 10 主要是一个安全意识文档。然而，自 2003 年发布以来，这并没有阻止许多组织将其作为事实上的行业应用安全标准。如果您想将 OWASP Top 10 用作编码或测试标准，请注意它只是最低要求，仅供参考。

使用 OWASP Top 10 作为标准的一大难点在于，我们记录的是应用安全风险，而非易于测试的问题。例如，A06:2025——不安全设计——就超出了大多数测试方法的范围。另一个例子是，测试是否已实施有效的日志记录和监控机制，而这只能通过访谈和抽取有效事件响应的样本来进行。静态代码分析工具可以查找日志记录的缺失，但可能无法确定业务逻辑或访问控制是否记录了关键的安全漏洞。渗透测试人员可能只能在测试环境中确认是否已启动事件响应，而测试环境的监控方式通常与生产环境不同。

以下是我们建议何时适合使用 OWASP Top 10：

| | | | | — | — | — | | 用例 | OWASP 2025 年十大漏洞 | OWASP应用安全验证标准 | | 意识 | 是的 | | | 训练 | 入门级 | 综合的 | | 设计与建筑 | 偶尔 | 是的 | | 编码标准 | 最低限度 | 是的 | | 安全代码审查 | 最低限度 | 是的 | | 同行评审清单 | 最低限度 | 是的 | | 单元测试 | 偶尔 | 是的 | | 集成测试 | 偶尔 | 是的 | | 渗透测试 | 最低限度 | 是的 | | 工具支持 | 最低限度 | 是的 | | 安全供应链 | 偶尔 | 是的 |

我们鼓励任何想要采用应用程序安全标准的人使用OWASP 应用程序安全验证标准(ASVS)，因为它旨在可验证和可测试，并且可以在安全开发生命周期的所有部分中使用。

对于工具供应商而言，ASVS 是唯一可接受的选择。由于 OWASP Top 10 风险中某些风险的性质（参见A06:2025-不安全设计），工具无法全面检测、测试或防御 OWASP Top 10 风险。OWASP 不鼓励任何声称能够完全覆盖 OWASP Top 10 风险的说法，因为这根本不可能。