OWASP LLM Top 10 评估：基于证据的方法、范围与服务商选择指南

OWASP LLM Top 10 评估涵盖哪些内容

OWASP LLM Top 10 评估是对嵌入大语言模型的应用开展的授权安全审查，围绕 OWASP 面向大语言模型应用的风险清单组织。搜索这一主题的人通常关心三个实际问题：具体测试什么？结果如何被证明而不只是被宣称？如何比较提供大模型安全评估或大模型渗透测试服务的供应商？本指南基于公开、可核实的参考资料回答这些问题，包括 OWASP Top 10、OWASP Web 安全测试指南（WSTG）、OWASP 应用安全验证标准（ASVS）、NIST SP 800-115、NIST 网络安全框架 2.0、CISA 安全设计（Secure by Design）、MITRE CWE Top 25 以及 MDN 的 HTTP 文档。

有一项限制需要先说明。本文的证据库并未收录 OWASP 大模型专用清单的正文，因此本文不复述其类别与编号，而是建议每次评估都写明所用清单的确切版本，并将每项发现映射到该版本。ASVS 项目提醒，要求标识符可能随版本变化，建议使用带版本前缀的引用。大模型评估同样需要这一规范，才能在清单修订后避免歧义。

实际上，大语言模型应用很少只是一个模型。它是一个 Web 或 API 产品，包含 HTTP 接口、身份认证、会话管理、渲染模型输出的前端，以及连接数据存储和工具的连接器。只测试对话行为而忽略外围应用的评估，会让相当一部分真实攻击面得不到检查。

• 面向模型的接口：提示词、系统指令以及任何检索或上下文构建流程
• 应用层：HTTP API、身份认证、会话，以及用户之间和租户之间的授权
• 输出路径：浏览器渲染、下游服务、数据库，以及接收模型输出的操作系统调用
• 集成：模型可调用的工具、插件或连接器，以及它们可访问的数据
• 运营：日志、监控，以及提示词、模型和连接器的变更管理

延伸阅读SCADA系统安全防护：威胁、安全评估与服务商选择

研究方法与证据基础

本分析基于八个公开来源，每个来源只在其实际表述的范围内使用。贡献者数量、发布版本和数据集规模等数值均取自各项目页面的公开内容。这些数字反映参考资料的成熟度和规模，并不是对大模型风险的测量，不应作此解读。

本文刻意不包含厂商基准测试、价格、客户案例或特定工具效果的说法，因为证据库无法支撑这些内容。本文推荐的做法均源自所引用的框架，属于指导建议，而非实测结果。

之所以引入 Web 应用安全标准，是因为大模型应用通过 Web 协议交付。MDN 将 HTTP 描述为客户端-服务器模式的无状态协议，Cookie 为部分交互增加了状态。MDN 还将身份认证描述为服务器验证客户端身份的方式，以确保只有授权的用户或系统才能访问特定资源。保护大模型产品的许多控制措施正落在这些基础机制上，因此可信的评估会把它们与模型行为一并测试。

为什么 Top 10 清单是起点而不是测试标准

OWASP 将其 Top 10 定位为面向开发人员和 Web 应用安全的标准意识文档，代表业界对 Web 应用最关键风险的广泛共识。项目页面指出，采用它或许是推动开发文化转向安全编码最有效的第一步。最新版本为 OWASP Top 10 2025，2021 版和 2017 版仍可获取，项目列出 199 名贡献者。

提升意识与验证是两项不同的工作。ASVS 项目表示，其首要目标是借助一个商业上可行的开放标准，统一市场上 Web 应用安全验证在覆盖范围和严格程度上的差异，并为测试技术安全控制提供基础。因此，可信的 OWASP LLM Top 10 评估用大模型清单来组织风险沟通，用具体的要求和测试用例来产生证据。

对采购方而言，结论很简单：如果一份报告只声称十个类别都已“覆盖”，却没有测试用例、证据和明确的通过或失败标准，那它只是一份检查表，而不是评估。应把任何 Top 10 式清单（包括大模型清单）当作“该看哪里”的地图，并追问每个领域究竟是如何验证的。

将评估映射到 OWASP、NIST 与 CISA 参考资料

NIST SP 800-115《信息安全测试与评估技术指南》发布于 2008 年 9 月，取代了 SP 800-42。它帮助组织规划和实施技术安全测试与检查、分析发现并制定缓解策略，并着重说明每种技术的优点与局限。虽然它早于大模型产品出现，但提供了完整的工作结构：规划、执行、分析和缓解。

OWASP WSTG 自称是面向 Web 应用开发人员和安全专业人员的首要安全测试资源。4.2 版是当前的网页版和 PDF 发布版本，5.0 版正在开发中。项目列出 184 名贡献者和 246821 次下载。在大模型评估中，它为模型外围的 HTTP 层和 Web 层提供测试用例。

OWASP ASVS 5.0.0 提供可验证的要求。其文档推荐使用带版本前缀的标识符，例如 v5.0.0-1.2.5，并以 CSV、JSON 等便于程序化使用的格式发布要求清单，使可追溯的发现在实践中变得可行。该项目列出 141 名贡献者。

在治理层面，NIST CSF 2.0 帮助组织理解并改进网络安全风险管理。NIST 正就 SP 1353 征求意见，截止日期为 2026 年 10 月 15 日。这是一份关于利用人工智能开展 CSF 分析与报告的快速入门指南初始公开草案，说明与人工智能相关的指导仍在形成之中。CISA 安全设计补充了生产者责任的视角：已有超过 200 家软件厂商签署其承诺，承诺朝七项关键目标作出善意努力；CISA 还列出了与人工智能相关的材料，例如安全人工智能系统开发指南。

• NIST SP 800-115：从规划到缓解的工作生命周期
• OWASP 大模型清单（注明版本）：模型特有问题的风险分类
• OWASP WSTG：外围 Web 应用与 API 的测试用例
• OWASP ASVS：可验证、带版本引用的控制要求
• MITRE CWE：发现的根本原因分类
• NIST CSF 2.0 与 CISA 安全设计：治理、责任与采购语言

证据得出的关键发现

传统软件弱点依然处于核心位置。2025 年 CWE Top 25 列出了当年数据集中 39080 条 CVE 记录背后最严重、最普遍的弱点。MITRE 指出，命令注入等弱点会吸引攻击者的关注。MITRE 还发布了 Top 10 KEV 弱点清单，以及另外 15 个处于入选 Top 25 边缘的弱点。只要大模型功能把模型输出传递给操作系统、数据库或浏览器，这些已知的弱点类别就同样适用。ASVS 包含防范操作系统命令注入的要求，CISA 安全设计警报也专门讨论了如何消除跨站脚本、操作系统命令注入和目录遍历。

输出渲染属于 Web 安全问题。MDN 说明，内容安全策略（CSP）允许管理员控制客户端可为页面加载哪些资源，有助于检测和缓解跨站脚本、数据注入等攻击；CORS 则让开发人员控制网站如何响应跨站请求。如果聊天界面在浏览器中渲染模型输出，这些控制就应纳入范围。

可追溯性是区分质量高低的主要因素。不断演进的标准中，标识符可能发生变化。引用特定版本大模型清单、带版本的 ASVS 要求和 CWE 标识符的发现，在参考资料修订后依然可以解读；只引用无版本类别名称的报告很快就会过时。

安全默认配置与加固配置同样重要。CISA 指出，产品应开箱即安全，多因素认证、日志记录和单点登录等功能应免费提供，并且安全应作为核心业务要求，而不仅是一项技术功能。因此，对大模型产品的评估应检查默认设置，而不只是为测试准备的最佳配置。

参考体系仍在变化。WSTG 5.0 正在开发，CWE 清单每年更新，NIST 与人工智能相关的 CSF 指南正在征求意见。组织应规划定期复评，并记录每次评估所使用的参考资料版本。

设计经授权的 OWASP LLM Top 10 测试计划

授权优先。开展任何测试前，都应取得系统所有者的书面授权，写明系统、环境、账户、时间窗口、数据处理规则和停止条件。NIST SP 800-115 将测试视为有既定流程和程序的计划性活动。本文中的任何内容都不授予、也不暗示对任何系统进行测试的许可。测试第三方模型提供商或托管服务时，须遵守其条款，必要时取得明确同意。

按层设计计划，每一层对应自己的参考依据：模型特有的风险主题取自注明版本的 OWASP 大模型清单，应用与 API 测试用例取自 WSTG，控制验证依据 ASVS，根本原因按 CWE 分类。这种结构可以避免一个常见缺口：对话测试做得很充分，身份认证、授权和输出处理却无人测试。

优先在预发布环境中采用非破坏性方法，使用具有代表性但不敏感的数据。对于有副作用的集成，例如发送消息或写入记录，应事先约定处理方式，常见做法是使用沙箱或模拟接口，确保测试不会造成现实损害。

在工作开始前，为每项发现定义证据标准，内容包括受影响组件、问题出现的条件、映射的标识符、影响、修复建议和复测结果。复现细节应通过受控渠道提供给系统所有者。

• 已签署的授权书和工作规则
• 所用每项参考资料的明确版本
• 资产与集成清单，包括模型可访问的数据
• 环境与测试数据计划
• 有副作用工具的处理方式
• 证据模板与严重性评定方法
• 复测窗口与验收标准

延伸阅读Web应用漏洞检测：范围、方法与经得起检验的证据

权衡：深度、可重复性与成本

人工与自动化技术相辅相成。NIST SP 800-115 强调每种技术手段都有优点和局限，并给出使用建议。自动化检查易于扩展，并可在各版本间重复执行；专家人工测试更擅长把模型、应用和集成之间的问题串联起来。站得住脚的计划会写明哪种技术覆盖哪类风险。

可重复性需要专门处理。如果应用对相同输入返回不同响应，单次观察就是薄弱的证据。报告应记录条件、尝试次数和观察到的结果，使结论能够被复现或质疑。

广度与严格程度相互牵制。覆盖 Top 10 清单的每个类别带来广度，而 ASVS 式验证提高严格程度。预算有限的团队可以把严格验证集中在模型输出会到达敏感系统的路径上，其余部分接受较轻的覆盖，但报告必须明确说明这一点。

时点性结果会逐渐失效。CISA 关于安全软件部署的指南强调在发布流程中加入可靠的测试和度量环节。对大模型产品而言，模型、提示词、检索来源或连接器发生变更，都是开展针对性复测的合理触发条件。

评估之后的运营影响

发现应反馈到开发生命周期，而不只是进入工单队列。MITRE 指出，洞察常见根本原因可以为厂商的软件开发生命周期和架构规划提供反馈，帮助消除整类缺陷；开发阶段的漏洞越少，部署后需要处理的问题也越少。按 CWE 根本原因对大模型发现进行归类，能让这种反馈切实落地。

日志需要专门验证。CISA 将日志列为应免费提供的安全功能之一。评估应确认模型交互、工具调用和授权决策的记录足以支持调查，同时遵守针对敏感内容约定的数据处理规则。

剩余风险必须有责任人。CISA 呼吁由高管层承担产品安全责任，NIST CSF 2.0 则为网络安全风险成果提供了通用词汇。把已接受的风险映射到 CSF 成果上，管理层就能将其与安全计划的其他部分一同跟踪。

采购指南：如何选择大模型安全评估服务商

应先明确评估需要证明什么，再选择服务商。CISA 的“按需安全”（Secure by Demand）指南供软件客户在与第三方经销商或服务提供商进行采购洽谈时使用。采购 OWASP LLM Top 10 评估或大模型渗透测试时，同样适用这一思路。

提出具体问题，并以书面形式比较答复。以下问题用于检验一份方案能否产出可追溯、可验证的证据，而不是一份通用检查表。

谨慎对待认证类说法。证据中的 OWASP 项目页面描述的是免费、开放的文档项目，并未描述针对评估服务商的认证。对于任何声称的认证或资质，都应向颁发机构独立核实。

本文不提供价格数据。比较方案时应看范围、证据质量、可追溯性和复测条款，而不是报价高低。若某方案只覆盖模型的对话行为，却排除了应用、API 和集成，应保持警惕。

• 发现将映射到 OWASP 大模型清单的哪个确切版本？
• 发现是否同时附带带版本的 ASVS 标识符和 CWE 标识符？
• 哪些 WSTG 测试领域覆盖外围应用和 API？
• 授权、工作规则和停止条件如何形成文档？
• 测试期间如何处理有副作用的集成和敏感数据？
• 模型行为类发现的可重复性如何记录？
• 是否包含复测？其验收标准是什么？
• 能否提供展示证据格式的脱敏样例报告？

OWASP LLM Top 10 评估决策框架

按以下顺序确定你需要哪种 OWASP LLM Top 10 评估以及如何委托实施。每一步都会产出下一步所依赖的成果物。

以广度为主的轻量审查适合早期原型和数据访问范围有限的内部工具。当模型输出可能到达操作系统调用、数据库、其他用户的浏览器或外部工具时，就有理由开展更深入、以要求为依据的评估，因为正是在这些路径上，CWE Top 25 中的已知弱点类别变得可被利用。

• 1. 目的：建立意识基线、发布前保证，或对照策略或要求集进行验证（NIST SP 800-115 将后者列为合理的测试目的）
• 2. 盘点：模型接口、应用层、输出路径、集成和数据访问范围
• 3. 深度：以广度覆盖大模型清单，或在高风险路径上开展基于 ASVS 的严格验证
• 4. 授权：签署的范围、工作规则和数据处理规则
• 5. 服务商：采购问题的答复、样例报告和复测条款
• 6. 执行：带版本引用、每项发现均附证据的分层测试计划
• 7. 修复：按 CWE 根本原因归类并反馈到软件开发生命周期
• 8. 治理：将剩余风险映射到 NIST CSF 2.0 成果并指定高管责任人，同时设定复评触发条件

结论：让 OWASP LLM Top 10 评估真正发挥作用

当 OWASP LLM Top 10 评估把大模型清单当作风险地图，并以可验证的证据支撑每一个结论时，才能真正创造价值。所引用的参考资料指向同一方向：NIST SP 800-115 提供结构，WSTG 提供测试用例，ASVS 提供带版本的要求，CWE 提供根本原因分类，MDN 说明模型输出周围的 Web 控制，NIST CSF 2.0 与 CISA 安全设计则覆盖治理与采购。

在选择服务商之前，应先明确目的、范围和证据标准，取得书面授权，并坚持带版本的可追溯性。这些步骤能把大模型安全审查从一次性的检查表，转变为可重复的保证流程，跟上模型、提示词和参考标准的变化。

延伸阅读渗透测试的组成部分：完整技术指南