AI模型安全评估：范围界定、测试方法与服务商选择

以一家虚构的保险公司为例：它从承包商处购买了一个经过微调的模型，用于读取理赔申请的扫描件并为每份申请标注风险等级。模型运行在内部集群中，理赔系统通过REST API调用它，承包商每季度把新版本权重上传到共享的模型仓库。在接入新产品线之前，安全团队被要求"检查一下模型是否安全"，随后收到两份方案。第一份是针对API的Web渗透测试，附带一份"按OWASP Top 10"编写的报告。第二份则反问：谁有权向仓库上传权重？权重以什么格式存储？测试人员能否查看请求日志？能否拿到制品副本？

例子是虚构的，但其中的分岔真实存在。第一份方案检查的是请求进入模型的那扇门，对模型本身几乎什么也说明不了。第二份方案更接近本质，但采购方不清楚测试人员为什么需要权重，也不清楚没有权重时对方能主张什么。那些写着"模型安全"、实际上只检查过API的报告，就是这样产生的。

下文讨论：哪些层面应纳入范围，为什么访问级别决定结论的边界，通用标准在哪里有帮助、在哪里留下空白，以及如何验收结果。本文只讨论经授权的工作，不包含漏洞利用指引；只有持有书面许可，才可以测试相应系统。

模型安全评估究竟包含什么

AI模型安全评估，是对以训练好的模型为核心的系统所进行的、经授权的结构化检查。它有三个目标：发现薄弱环节，确认防护机制按声明发挥作用，形成管理层可据以决策的整改计划。不过，“模型”一词容易误导。在实际部署中，受检对象往往是一组制品：架构和配置说明、一个或多个权重文件或分片、分词器和预处理器，以及加载与运行代码。并非每个组件都属于狭义的数学模型，但每个组件都可能改变已部署系统的行为。风险产生于多个层面的交汇处，现实的评估范围通常包括四层。

第一层是模型制品及其供应链：权重从哪里来，谁能替换它，以什么格式存储，加载时会发生什么。第二层是模型行为：模型对刻意构造的输入有多强的稳健性，是否会泄露其训练数据的信息。第三层是围绕模型的应用和API：身份认证、授权、租户隔离、限额以及输出处理。第四层是治理：谁对风险负责，如何报告，多久复审一次。

每一层都需要各自的方法和访问权限：经验丰富的Web测试人员能找出API中的授权缺陷，而从模型回答中还原训练数据则是另一类问题。如果这类发现被放进同一张表，却不说明每项发现是如何、在何种访问条件下得到的，报告就很难使用。

对于生成式模型，OWASP Top 10 for LLM Applications 2026年版是一个有用的参照：其中把供应链（LLM04 Supply Chain）、数据与模型投毒（LLM05 Data and Model Poisoning）以及敏感信息泄露（LLM02 Sensitive Information Disclosure）列为独立类别。但它是提升风险意识的清单，不是验证标准，也不是认证：它提示该问什么，而不是如何测试某个具体模型。关于生成式系统的整体测试，可参阅我们关于生成式AI安全评估的文章。

访问级别决定结论的边界

测试人员只能主张其访问权限允许检查的内容，而过高的期望恰恰容易在这里产生。

在黑盒测试中，测试人员只能看到API：授权、限额、输入处理，以及模型对构造请求的反应。但仅凭API的响应，无法证明训练数据没有被投毒、权重与声明一致，或模型中不存在由测试人员未知的触发条件激活的后门。在这一层面"没有发现"，只意味着测试人员所知的检查在特定条件下没有发现问题。

当方法和证据足够时，更广的访问权限可以支撑更多结论。配置和日志可以显示记录了什么，以及对这些记录的访问如何受到控制。制品副本可以用于计算哈希；若另有通过独立渠道取得的可信参考值，还可以进行比对，同时也能分析格式和加载代码。访问训练流水线可以评估围绕数据的流程，但即便如此，检查的也是控制措施，而不是证明数据集"干净"。

如果合同或知识产权条款如此约定，供应商可以拒绝提供权重。此时报告应明确写出未对制品进行检查。评估限制及相关剩余风险仍由采购方分析和接受；把条款写进合同本身并不会转移风险。供应商保证、独立报告、可信参考哈希或签名，以及基础模型和微调来源证据，都是额外且有边界的输入，但不能替代对制品的直接检查，也不能证明制品安全。

授权需要来自所有相关方。如果模型托管在云服务商处，权重属于承包商，数据属于客户，那么每一个有权在其范围内允许相关操作的一方都需要给出书面同意；仅有客户的同意，并不能覆盖他人的基础设施。

如果还不清楚哪种访问级别切实可行、能支撑哪些结论，最好在签订合同前理清。与Pentest.red的这类沟通可以从范围确认开始：组件、访问权限、负责人，以及需要回答的问题。

模型制品与供应链

模型权重可能存放在一个文件或多个分片中，并与配置及其他相关制品组成一组；这组制品会经过对象存储、模型仓库和部署流水线。和任何软件制品一样，它也有供应链，模型层面相当一部分切实可行的检查就在这里。

第一个问题是谁可以写入模型仓库。如果流水线令牌或承包商账号无需单独审批就能发布版本，其余一切都取决于令牌持有者的安全习惯。第二个是格式。一些基于通用对象序列化的格式（例如Python的pickle）能够编码对象，而对这类对象进行不安全反序列化时可能执行代码。因此，用此类反序列化器加载不可信制品可能导致代码执行，这是CWE-502的一种表现。只存储张量的格式能降低这一风险，但不能回答"这是谁的权重"。第三个是加载器：有些库会随模型一起从代码仓库拉取可执行代码，此类选项应是深思熟虑的决定，而不是照抄示例得来的默认值。

部署流水线需要令牌来读取、有时还要写入权重。多因素认证保护的是人，而不是工作负载凭据：对后者而言，重要的是最小权限、读写分离的令牌、轮换和日志记录。"只读"访问也不应被自动视为安全：能下载权重的人，就获得了知识产权，并能离线针对模型的精确副本构造输入。

1. 仓库写权限过宽流水线令牌或承包商账号无需单独审批、也不经来源核验，就能上传新版本的权重。
2. 制品被替换仓库中出现权重被改动的文件，或在反序列化时允许执行代码的格式中夹带了可执行载荷。
3. 加载时不做比对部署直接拉取"最新版本"，不把哈希或签名与存放在仓库之外的参考值进行比对。
4. 悄然生效代码在推理节点上执行，或模型对某一小类输入的分类发生变化；功能测试可能察觉不到。

沿着这条链路的检查归结为：写权限与凭据、将哈希或签名与仓库之外的参考值比对、格式、加载器选项，以及版本变更能否在监控中看到。计算出的哈希用于标识字节内容；与可信参考值比对，才能检查它是否与预期制品一致；来源证据则帮助追溯源头。任何一项都不能单独证明模型安全。来源、完整性校验、发布权限控制这些原则同样适用于程序库和容器，详见我们关于软件供应链安全评估的文章。

数据投毒：能查什么，不能查什么

投毒是指向训练或微调数据中加入准备好的样本，使模型在特定输入下表现异常。触发条件可能很窄，常规功能测试未必能察觉这种变化。

通过API无法证明不存在投毒，诚实的测试人员也不会作此承诺。检查的是流程：谁写入数据集，标注外包方如何获得数据访问，数据集版本是否用哈希固定，评估集是否分开存放并受不同控制，新版本发布前是否进行回归评估。

反馈回路值得特别关注。如果在我们的例子中，理赔专员的修正会自动进入下一轮微调数据，那么任何能影响这些修正的人都在影响未来的模型。这是一条信任边界，应像检查数据库写权限那样加以检查。

模型行为：稳健性与隐私

模型层面的发现需要自己的术语，否则就会与Web漏洞混为一谈。一个方便的基础是NIST AI 100-2 E2025，它给出了对抗性机器学习攻击及缓解措施的分类体系和术语。其中区分了逃逸攻击（构造输入以在运行时改变模型输出）、投毒攻击（在训练阶段施加影响）以及隐私攻击——例如试图确定某条记录是否在训练数据中，或依据模型的回答复制其行为。

行为测试应从业务影响出发，而不是从选择工具出发。对理赔分类模型而言，有意义的问题是：对扫描件做一个人眼难以察觉的小改动，能否把申请移入低风险类别？对用个人数据训练的模型而言：它是否会在有针对性的查询下复现特定记录的片段？

这类测试需要事先约定：商定查询预算，避免在生产环境中造成负载和费用或影响其他客户；准备经客户批准的测试集。在能够访问流水线时，可以预先向微调数据加入合成标记记录，再检查是否会复现。这个实验会改变训练数据并产生新的模型版本；它衡量的是对这些标记的记忆，而不能证明全部原始训练数据的隐私。

一个重要的保留：一个成功的例子证明攻击是可能的，却不说明它多常成功。生成是否具有随机性取决于模型、运行环境和采样设置；在固定条件下，系统也可能表现为确定性。因此，行为类发现应按约定的一组试验复现，并记录输入、生成参数、所用 seed（如有）、运行环境和制品的确切版本。

生成式模型：泄露与隐藏上下文

生成式模型还会带来隐藏上下文暴露的问题，即应用放入请求中的系统指令和内部数据。测试时应把进入模型上下文的内容视为可能被泄露。把API密钥或其他秘密放进系统指令是一项设计风险，即使测试未能提取它，因为提示词措辞并不是保密边界；已经确认的泄露应与不安全的放置方式分别记录。内部地址则应根据其敏感性和它所能提供的访问来评估。

围绕模型的应用与API

如果模型通过Web界面或API对外提供，这一攻击面应采用成熟的Web测试方法。OWASP 发布了用于 Web 应用安全测试的 Web Security Testing Guide；本文把 4.2 版固定为示例，每个项目都应记录实际使用的版本，而不判断另一版本当前是否仍在开发。OWASP ASVS规定了对技术安全控制的要求，目标之一是统一市场上验证工作在覆盖范围和严格程度上的差异。本文采用ASVS 5.0.0；建议以带版本号的标识符（如v5.0.0-1.2.5）引用要求，因为编号会随版本变化，要求清单也提供CSV、JSON等格式。OWASP Top 10 2025是提升意识的文件，因此报告中的"覆盖Top 10"所提供的信息，少于对具体ASVS要求的引用。

围绕模型会出现一些特有的检查对象。不同客户微调模型之间的隔离：客户A能否通过修改请求中的模型标识符访问客户B的模型？这是普通的对象级授权缺陷，却有模型特有的后果——能接触到用他人数据训练出的行为。上传、回滚和切换版本的管理接口：谁能调用，服务器端是否校验。客户端传入的推理参数：若回答长度和候选数量不受限制，一个请求就可能消耗过多资源，并在按用量计费的服务中产生本可避免的费用。日志：请求和回答可能包含个人数据，因此要最小化、脱敏，限制访问并设定保留期限。

关于接口测试方法的更多内容，请参阅我们关于REST API安全评估的文章。

当模型输出变成命令

不能仅仅因为输出出自"自己的"系统，就把模型输出视为可信。如果模型输出中的风险类别、文件名或查询片段被继续传入SQL、模板或命令行，就应适用与用户输入相同的要求，包括ASVS中关于防御操作系统命令注入的要求。一个重要细节：不经过shell、把参数作为数组的独立元素传递，可以防止特殊字符被解释，但不能防止参数注入，因为以连字符开头的值可能被程序当作选项。需要允许值白名单、格式校验，并在工具支持时显式使用选项结束分隔符。

规划工作：NIST SP 800-115的方法纪律

NIST SP 800-115《信息安全测试与评估技术指南》（Technical Guide to Information Security Testing and Assessment）于2008年9月发布，取代了SP 800-42。它帮助规划和开展技术测试与检查、分析发现并制定缓解策略。在形式上，它把评估分为规划、执行和执行后（post-execution）三个阶段，并说明每种技术方法的优势与局限。该文件声明自己并非完整的测试计划，且早于现代模型的普及，因此它提供的是流程纪律而非AI测试用例：它是项目的框架，而不是项目的内容。

在规划阶段，值得要求四项产出：来自每一个有权授权的相关方的书面授权，并划清边界（模型端点、应用、API、模型仓库、流水线、基础设施）；方法与组件的对应表，注明每种方法无法发现什么；对提示词、回答、日志和训练样本的处理规则，包括最小化、脱敏、访问限制、保留期限和项目结束后的删除；以及把每项发现与根本原因、优先级和负责人关联起来的报告格式。

测试环境也要单独约定。预发布环境中的模型可能在权重版本、量化方式、生成参数和安全过滤器上与生产环境不同，因此其结果不能不加保留地套用到生产环境：报告要记录被测制品的哈希和配置，生产环境中的测试只能在约定范围内进行。

在实践中，我们会在SP 800-115的三个阶段之外增加整改与复测的循环。这不是该文件的内容，而是一种工作习惯；没有它，报告就止于一份发现清单，而不是经过确认的风险降低。

优先级排序：CWE弱点类别与模型上下文

把发现映射到适用的CWE弱点类别，会把讨论从单个实例转向更广泛的缺陷模式，并有助于规划系统性修复。2025年CWE Top 25 Most Dangerous Software Weaknesses和2025 CWE Top 10 KEV Weaknesses分析都可以作为开发优先级的输入，但任何排名都不能单独决定优先级；仍需结合可达攻击路径、可能影响和现有控制。基于KEV的分析按照弱点类别与CISA已知被利用漏洞目录中漏洞的关联进行排名。

重要的是不要误读这些清单。CWE描述的是一类弱点，而不是它在你的系统中被利用的概率。某类弱点出现在基于KEV的清单中，是提高优先级的合理理由，但不能证明你的这个实例正在被利用；决策仍取决于攻击者现实可得的访问以及后果。

对于包含模型的系统，图景是清晰的。加载器中的不安全反序列化、模型选择API中缺失的授权检查、输出处理中的命令注入，都能很好地映射到CWE。逃逸、数据记忆之类的行为类发现则不然：它们更适合按NIST AI 100-2分类体系归类，并依据其对决策和数据的影响进行评估。如何建立这种优先级排序，详见我们关于基于风险的漏洞优先级排序的文章。

验收什么样的结果，如何验证修复

没有复现条件的发现用处不大。每项发现都应注明权重版本或哈希、环境、访问级别、生成参数；对于非确定性行为，还应注明尝试次数和成功比例。复测只能在其实施的条件下确认修复；模型重新训练后，稳健性复测实际上是对新模型的新测试。

如何建立值得信赖的修复验证，详见我们关于渗透测试整改验证的文章。

权衡与通用标准的局限

广度和深度争夺同一份预算：深入的行为测试可能漏掉API中的授权缺陷，基于标准的广泛审查可能漏掉加载器中的缺陷。好的方案会公开展示这种权衡，并解释所选的平衡。

通用框架会留下空白。SP 800-115、WSTG、ASVS、CWE和CSF是关于测试、验证和风险管理的文件，而不是保护模型的标准，因此模型层面的测试用例必须纳入测试方有文档记录的方法论。引用某个框架，并不能证明覆盖了AI。

标准会变化：例如，可以把 WSTG 4.2 固定为本次使用的版本；OWASP Top 10 有 2017、2021 和 2025 年版；ASVS 提醒标识符会随版本变化；OWASP Top 10 for LLM Applications 2026 年版的编号也与此前版本不同。每次评估都应记录适用于当次工作的版本，而不使用浮动的“最新版”或开发中版本声明。因此合同和报告中要记录确切版本，否则不同年份的发现无法比较。

方法有其局限。自动扫描和人工测试不能相互替代，报告应说明每种方法无法发现什么。如果测试方用AI工具做分析或写报告，请询问这些工具如何接受检验：NIST围绕CSF 2.0发布的材料，把使用AI处理参考映射（informative references）与对工具的持续评估和改进联系在一起。这些材料本身把AI视为安全工作的工具，而不是被保护的对象。

面向管理层的报告与复评频率

NIST把Cybersecurity Framework 2.0描述为帮助组织理解并改进网络安全风险管理的工具。对于模型评估，它是方便的报告框架：AI系统当前与目标状态的概况（profile）确立目标，发现表述为相对于目标成果的差距，管理层能把模型风险与其他网络风险放在一起看，历次评估也变得可以比较。

为了不让报告被束之高阁，要把它转化为工作产物：把适用于 Web 控制的 ASVS 要求以 CSV 或 JSON 导入任务跟踪系统，使每项此类控制都有负责人和状态；其他组件采用相应标准，并用适用的 CWE 弱点类别改进安全开发实践；记录所用标准的版本和被测制品的哈希，使下一次评估能够衡量真实的变化。

复评最好不仅与日历挂钩，也与事件挂钩：新的权重版本、更换基础模型、新的微调数据来源、模型输出会触发操作的集成，以及托管平台的变更。每一个事件都会改变此前结论赖以成立的条件。

如何选择服务商

比较供应商之前，应先回答上面的技术问题，否则比较的只是措辞，而不是方案。请每一家服务商用相同的术语描述范围。哪些组件纳入工作（API、模型、制品、模型仓库、流水线），在何种访问级别下进行？每个组件适用哪份文件、哪个确切版本？在Web测试之外增加了哪些模型层面的检查，方法论记录在哪里？软件发现如何映射到适用的CWE弱点类别，模型层面的发现又如何映射到CSF 2.0成果和NIST AI 100-2分类体系的类别？每种方法有哪些局限？如果服务商使用AI工具，这些工具如何接受检验？哪些授权和数据处理规则将约束这项工作？

对于以下方案应保持警惕：只引用Top 10；承诺根据API测试得出关于训练数据完整性的结论；或者提供"模型安全证书"。渗透测试不是认证、不是鉴证，也不是审计意见：它展示的是在约定条件下能够发现的问题，无法独立核实的证书或结果不应被接受。

如果需要结合您的系统梳理这些问题，可以在渗透测试的框架内，与Pentest.red讨论围绕模型的API、应用、基础设施和供应链的范围、访问权限和预期证据。具体包含哪些工作，在范围确认时确定。渗透测试报告可以作为更广泛符合性评估的一项证据，但渗透测试本身不是认证或符合性意见；正式认证和监管符合性工作仍需另行开展具备相应资质的评估。

结语：可信的模型评估是什么样的

可信的AI模型安全评估，应取得每个有权批准其责任范围内测试的一方的书面授权，并明确界定适用层面的范围：制品及其供应链、模型行为、应用和API，以及治理。SP 800-115、WSTG、ASVS、CWE和CSF 2.0为它提供流程纪律和共同的报告语言，NIST AI 100-2分类体系为模型层面的发现提供词汇，但这些文件都不能取代针对模型本身的测试方法。

最重要的是对边界保持诚实：每一项结论都附带访问级别、模型版本以及得出该结论的条件。提出这一要求的采购方，得到的是可以比较、可以执行、可以复现的结果，而不是一份标题令人安心的文件。