在可信研究环境中整合代理风险信号：利用Agent2Agent协议和模型上下文协议（MCP）自动化VEX流程，应用于SACRO和TRevolution开发管线

《Computer Standards & Interfaces》：Integrating Agentic Risk Signalling in Trusted Research Environments: Automating VEX with Agent2Agent Protocols and Model Context Protocol (MCP) in SACRO and TREvolution Pipelines

本研究提出一种可信研究环境（TRE）中的自动化VEX（漏洞可利用性交换）生成与验证框架，整合Model Context Protocol（MCP）和Agent2Agent协议，通过运行时监控、依赖图谱分析及加密签名，实现漏洞上下文感知的动态评估，减少约40%的误报率，并通过容器重放验证可重复性，为安全研究提供可信基础。

　　### 框架概述

本研究提出了一种在安全研究环境中自动化生成和验证可机器读取漏洞声明的框架，即漏洞可利用性交换（VEX）文件。这一框架旨在解决现有漏洞报告中一个关键限制，即静态评分系统往往无法准确判断某一漏洞是否在特定分析环境中可被利用。通过结合结构化元数据捕获、运行时监控以及可验证的来源追踪，该框架能够将漏洞分类为受影响、已修复或不相关，并由可机器读取的证据包支持。研究方法在容器化应用程序中进行了评估，这些应用程序中故意引入了易受攻击的组件。通过软件物料清单（SBOM）和漏洞扫描器生成基础库存，而可重复性框架验证了结果的可独立复现性。研究结果表明，自动化的VEX生成可以减少误报，通过区分理论性风险与实际可利用风险，从而提高联邦基础设施中的安全保证和可重复性。同时，研究也认识到采用这一框架面临诸多挑战，包括多层监控带来的计算开销、对外部工具的依赖以及误报风险。因此，需要在异构领域进行更广泛的试点研究，并在标准化测试平台进行基准测试，以增强其通用性。此外，运行时监控可能引发的隐私问题以及可持续维护模型也需得到重视。通过结合自动化与人工监督，并与新兴标准相协调，本研究为漏洞管理提供了一种可重复、可审计且情境感知的方法。该工作不仅提供了一个概念验证，还为在敏感计算环境中改进安全实践提供了一条可行的路径。

### 研究背景

在研究与开发过程中，网络安全问题常常被推迟处理。尽管安全工程师会建议开发人员及时修补漏洞，但开发人员往往会质疑是否有必要进行这些操作，这导致了关于网络安全的长期争议。一种可能的解决方案是将通用漏洞评分系统（CVSS）及其基础评分、时间评分和环境评分替换为三种基于漏洞评分的策略。这些策略分别是：（1）如果CVSS评分高于8.9，则立即修补；（2）如果CVSS评分高于6.0，则延迟修补；（3）如果CVSS评分低于7.0，则接受风险。然而，这种方案存在两个主要问题。首先，无法明确识别风险的具体位置；其次，随着漏洞公告和CVE数量的增加，未在国家漏洞数据库（NVD）中记录的修补数量难以跟踪，这在网络安全中被称为“可见性”问题，指的是能够全面查看数字足迹及其包含的风险和漏洞的能力。

目前，PDF和文本文件通常用于共享信息，但这些文件通常未被签名。这使得操作员容易受到恶意行为的影响，因为如果漏洞信息以PDF形式共享且未由操作员签名，恶意行为者可能会发送伪造的公告。自动化方法也存在挑战，如如何确保其准确性和安全性。

### 文献综述

在可信研究环境（TRE）中实现机器可读、情境感知的漏洞声明需要综合现有漏洞报告标准、可重复性框架和安全分析协调的最新进展。VEX规范由美国商务部负责制定，旨在将已知的软件漏洞（CVE）与特定的环境和执行状态相结合，从而减少安全操作中的误报和警报疲劳。这些结构化的公告建立在SBOM框架之上，用于声明特定漏洞是否可被利用、是否存在或已被修复。虽然传统的SBOM可以记录软件依赖关系，但它们无法反映动态运行时条件。VEX机制弥补了这一缺陷，特别是在与OSV或本地NVD镜像等漏洞源结合使用时。

近年来，TRE中的安全分析工作，如SACRO，已经将VEX扩展为支持联邦可重复性、安全审计跟踪和实时漏洞抑制。SACRO通过将模型上下文和执行血统直接嵌入输出艺术品中，提升了可重复性，借鉴了In-Toto和Sigstore的原则。将可验证的认证与分析作业元数据结合，与模型上下文协议（MCP）相一致，能够提供可验证的绑定，将输入数据、模型和执行环境联系起来。这种集成在符合GRAIMatter标准的基础设施中尤为重要，因为数字来源和可重复性是敏感健康和公共数据研究的核心关注点。

此外，TRE中的情境感知漏洞评估进一步扩展了传统的扫描工作流程。通过评估组件的存在和可利用性在受限执行环境中（如无出站访问、沙箱执行、强制披露控制），研究人员展示了显著的噪声减少效果。这些条件通过政策引擎如Kyverno强制执行，确保在整个分析生命周期中声明性地执行资源、访问和数据移动政策。

这些系统的结构化输出，使用CSAF或OpenVEX等模式进行格式化，已被整合到审计注册表中，以实现长期验证和血统跟踪。这与美国网络安全与基础设施安全局（CISA）的当前指导相一致，强调VEX艺术品需要经过加密签名并在生命周期事件中可验证。

此外，诸如Dependency-Track等工具生态系统展示了在生产CI/CD管道中生成和使用VEX声明的操作可行性。当这些工具与SACRO和TREvolution开发的联邦编排模型相结合时，VEX被定位为增强敏感计算环境中数字信任的标准。在软件供应链中改进漏洞管理的努力越来越多地集中在提高透明度、互操作性和自动化的标准上。SBOM由美国国家电信和信息管理局（NTIA）正式化，并通过SPDX（ISO/IEC 5962:2021）等倡议进行标准化，为软件组件提供结构化的清单。SBOM在开源和监管领域被广泛采用，因为它使下游消费者能够识别依赖项，并将其与NVD和OSV等公共数据库中的已知漏洞进行关联。虽然SBOM在建立基础透明度方面有效，但它们仍然是静态艺术品，无法捕捉运行时条件或环境特定的缓解措施，这些措施决定了漏洞在实际中的可利用性。

VEX规范通过允许生产者声明特定上下文中漏洞是否影响其产品，解决了一些这些不足。这种区分减少了误报，并提供了比SBOM更清晰的判断。然而，当前的VEX实现，如OpenVEX和CISA VEX，通常依赖于手动声明漏洞的可利用性，并缺乏自动链接到可重复运行时证据。因此，虽然它们提高了沟通效率，但并未提供可独立验证的证据，以证明声明的可利用性状态是正确的。

CSAF通过提供发布公告的标准格式，补充了SBOM和VEX。CSAF使组织能够结构化地沟通漏洞和缓解措施，尤其是在大规模环境中。然而，CSAF公告通常与运行时遥测或可重复性管道脱钩，这意味着它们无法证明漏洞是否在受控执行中被观察、触发或缓解。

同样，NVD和OSV提供了权威的漏洞情报源，但它们主要设计为广泛适用，而不是环境特定的风险。它们记录了已知问题，通过CVSS评分确定严重性，并分发机器可读数据。然而，这些数据库并未整合隔离限制、权限限制或执行痕迹，这些可能使漏洞在特定环境中不可利用。

本研究提出的框架通过将机器可读公告与可重复运行时证据绑定，扩展和补充了这些标准。通过将SBOM库存与实时执行痕迹结合，从NVD和OSV中过滤漏洞数据通过环境特定的限制，并生成经过加密签名和模式验证的VEX艺术品，系统确保了可利用性声明既情境感知又可验证。通过这样做，它弥合了声明性标准（如SBOM、CSAF和VEX）与操作保证机制之间的差距，为在安全和联邦研究环境中漏洞管理提供了一条可重复的信任路径。

### 方法论

本方法论将运行时监控、代理分析和基于协议的情境嵌入整合到SACRO框架中，并基于适应MCP和A2A协议进行安全代理间消息传递和模型状态血统追踪。方法设计（详见图1）基于TRE中运行时监控的需求。第一阶段包括部署代理以观察和记录研究任务执行期间的系统状态。此过程确保VEX艺术品反映静态组件存在和实际软件执行路径及运行时行为。图1详细展示了在TRE中使用MCP和A2A进行运行时监控的步骤。

在SACRO-TRE环境中，任何计算任务的启动都始于对分析上下文的结构化和可验证的捕获。这通过MCP实现，该协议正式化了启动前的阶段，通过生成一个防篡改、机器可读的分析状态记录。MCP框架确保所有后续步骤，从漏洞评估到联邦可重复性，都建立在可重复和加密签名的执行上下文中。

每个提交的分析任务被封装在容器化工作负载中（如Docker或Singularity），具体取决于托管基础设施的安全配置和内核访问限制。每个研究任务作为容器化包提交，确保一致、可重复和可审计的执行，通过捕获完整的软件环境、依赖项和控制参数。

这些容器的编排由自动调度器处理，如在云部署中使用Kubernetes或在高性能计算（HPC）环境中使用SLURM，这些调度器配置有严格的网络安全和资源治理政策。当任务进入队列时，编排层会通过结构化的任务清单评估任务是否符合组织安全政策和数据访问权限，然后再进行调度。

在编排过程中，可选地调用容器运行时安全扫描器（如Anchore Engine或Clair），以在执行前对容器镜像进行静态分析，以识别已知的CVE。这为更广泛的VEX生成框架提供了早期的风险分类。

一旦被接受，编排器将在命名空间隔离的节点池中启动容器实例，实施以下控制：

- **内核能力限制**：通过seccomp、AppArmor或Singularity运行时配置进行限制。
- **本地状态的非持久性**：通过临时卷或空目录挂载来实现。
- **进程间通信（IPC）和用户命名空间隔离**：通过用户命名空间映射（userns-remap）或Singularity的–fakeroot选项实现。

这些编排控制确保了执行来源、运行时行为和后续VEX声明严格限制在声明的软件边界内，使下游自动化流程具有可信任性。

### 情境感知漏洞评估

在SACRO-TRE流程的这一阶段，通过将观察到的软件组件和运行时依赖项与权威的漏洞情报相结合，进行有针对性的漏洞分析，同时考虑TRE特定的缓解措施和操作约束。与传统扫描器不同，这些扫描器报告所有已知漏洞，无论其上下文如何，而本方法通过整合隔离边界、限制网络政策和输出控制的知识，专注于在给定执行环境中可利用的漏洞。

此过程始于在TRE中维护一个安全、隔离的NVD和OSV源的镜像。这些镜像通过经过认证的rsync或受控API轮询机制进行同步，确保在JSON 5.0和OSV格式中更新CVE数据，同时保持TRE的安全状态。所有更新都通过可信签名机制（如Sigstore或GPG）进行加密验证。

对于在之前阶段捕获的每个运行时组件（如通过MCP和代理监控），进行确定性指纹识别。这包括从文件如/etc/os-release中提取操作系统基础镜像标识符，通过工具如pip list、R sessionInfo()或java -jar jdeps等解析语言特定的包元数据，并将其转换为符合SPDX格式的软件包URL（pURL）。这些pURL（如pkg:pypi/numpy@1.22.0）随后与OSV数据库进行匹配，以查找漏洞。

在识别之后，进行过滤阶段，评估每个CVE的实际可利用性，通过整合CVSS指标与TRE特定的约束。例如，在出站访问受限的环境中，需要外部网络通信的漏洞会被降级；在内核能力被seccomp或AppArmor限制的环境中，需要提升权限的威胁会被忽略。这种过滤减少了报告的漏洞数量，只保留在特定上下文中真正可操作的漏洞。

每个漏洞随后被丰富元数据，如从ExploitDB或Metasploit获得的利用成熟度，TRE特定的风险分类，以及通过包管理器工具获得的修补信息。生成的发现被格式化为符合VEX规范的数字签名、结构化的漏洞报告（如CSAF或OpenVEX）。每个条目包括组件哈希、CVE标识符、严重性指标和一个说明该问题是否在观察到的执行上下文中可被利用的陈述（例如，“不可利用：容器是出站受限的”）。这一过程在图5中得到了说明。

这种情境感知的方法确保了相关和可验证的风险被提升，减少了警报疲劳，并支持在联邦、隐私保护的研究环境中高保障的漏洞分类。

### 代理生成VEX和数字签名

在情境感知漏洞评估阶段之后，SACRO-TRE流程将结果格式化为数字签名、机器可验证的VEX文档。这一步骤对于确保每个CVE的确定性、可验证性和可移植性至关重要。为此，VEX按照SACRO扩展的模式进行构建，该模式包含特定于TRE的字段，如作业ID、容器哈希、执行时间戳和用户上下文（分析师的匿名标识符）以及通过MCP生成的模型上下文哈希。这些字段通过将漏洞评估直接链接到每个作业的计算和分析血统，实现数字取证。

在VEX负载构建阶段，代理自动从之前的流程阶段提取结构化数据并填充模板。对于每个检测到的漏洞，生成一个离散的块，包括漏洞ID（如CVE-2024-2197）、状态（分类为受影响、已修复或不相关）、采取的行动（如“通过包管理器修补”、“通过AppArmor阻止运行时”或“依赖项未调用”）和理由。理由字段尤为重要，它结合了运行时日志、代理分析和可利用性过滤的证据。为了建立分析来源，每个块还包括通过MCP捕获的模型艺术品、容器环境和输入数据集的确定性哈希，从而将评估绑定到特定的计算指纹。

在数字签名过程中，构建的VEX文档通过加密密封来确保其真实性和完整性。使用符合FIPS 140-2或FIPS 140-3的硬件安全模块（HSM）或云原生安全内核（如Azure Key Vault、AWS KMS或使用硬件支持的HashiCorp Vault）进行签名。这通常通过强哈希函数（如SHA-256或SHA-3）和公钥加密实现，生成PKCS#7或COSE签名块。这确保了VEX文档可以被独立验证，并且保证其未被篡改。图6中的图表展示了生成和签名SACRO兼容的VEX艺术品的结构化流程，从JSON模板构建到元数据绑定以确保审计链接。

每个阶段在图6中得到详细说明，包括模板创建、负载构建、数字签名和绑定，旨在确保VEX声明的加密完整性、可重复性和情境信任。签名的VEX文档随后绑定到相关的元数据艺术品，完成加密来源链。这些包括提交给TRE编排器的作业清单（详细说明容器镜像、资源限制和声明的数据源），以及所有运行时组件的相应SBOM艺术品，以及执行期间产生的任何输出数据集或模型文件。在适当的情况下，这些输出艺术品也被加密签名并进行版本控制，使下游研究人员或审计人员能够重建分析血统并验证VEX声明的正确性。

通过将代理AI工作流程嵌入VEX生成过程，SACRO实现了可审计的漏洞声明，同时支持安全的代理间通信、联邦信任传播以及符合隐私保护数据科学的可重复性验证。

### 模式验证和可重复性流程

SACRO-TRE漏洞评估流程的最后阶段专注于模式合规性验证、数字签名验证和联邦研究基础设施中的可重复性保证。这一阶段确保了在之前步骤中生成的VEX艺术品在技术上有效且加密可信，并且其中包含的漏洞声明可以在重新执行中被独立验证。

模式验证首先通过使用JSON Schema Draft 2020-12规范解析生成的VEX JSON文档来实现。首先，通过结构化合规性验证确保艺术品符合预期的语法和语义规则。随后，验证符合SACRO扩展的VEX模式，该模式对CVE块、理由字段和情境元数据（如作业ID、容器哈希和MCP来源绑定）施加额外的约束。模式合规性失败会被记录并报告给审计子系统以进行修复。

一旦确认模式合规性，艺术品会经历数字签名验证。签发的公钥会与TRE的可信根进行比较，通常是基于符合FIPS 140-2的硬件安全模块（HSM）。签名验证通过标准加密工具（如OpenSSL或Python中的加密库）进行，确保完整性、不可否认性和对漏洞评估报告的篡改证据。

为了确认可重复性，流程支持一个确定性的重放机制。原始作业容器在测试模式的TRE环境中被重新部署，使用相同的编排清单、输入数据集引用和容器哈希。整个VEX生成流程在这些相同条件下重新执行。生成的VEX艺术品随后与原始版本进行比较，使用结构化差异和哈希比较。如果CVE列表、可利用性状态和理由匹配成功，这将验证分析结果的可重复性，并加强原始评估的有效性。图7中的图表展示了VEX生成和签名的结构化流程，包括通过MCP捕获的元数据哈希、与作业执行的链接以及在重放测试中生成的VEX艺术品的比较。

图7展示了基于哈希的可重复性验证流程，确保VEX艺术品与特定的分析状态和执行上下文有可验证的链接，从而支持在联邦研究环境中进行可重复性声明。验证的VEX艺术品被输入SACRO注册表，这是一个安全的可重复性评估账本。这些艺术品还通过RDF编码与符合GRAIMatter的透明框架同步，并存储在一个知识图谱（如GraphDB）中，与原始数据集的DOI和作业UUID进行语义链接。这种分层注册方法为机器可读的可追溯性和政策审计的可问责性提供了保障，使VEX声明在TRE生态系统中具有长期验证、版本控制和信任互操作性。

### 实验结果

我们部署了一个容器化的Python应用程序，其中包含一个故意引入的易受攻击依赖项（flask==0.12），以模拟在SACRO兼容的TRE中的作业执行。这一设置使我们能够在受控环境中测试自动化的SBOM和VEX文档生成与解释。

使用Syft，我们从运行中的容器镜像中提取了SBOM。SBOM确认了易受攻击库的存在。然后，我们使用Grype扫描镜像，成功识别了与Flask 0.12相关的漏洞（CVE-2018-1000656）。通过一个结构化的JSON模式，生成了一个VEX文档，根据运行时条件和可利用性分析，将状态标记为“未受影响”。这确认了尽管漏洞存在于包中，但它在部署的容器中无法被利用。

这一演示证实了容器隔离、自动SBOM生成和漏洞分析工具可以支持细粒度的VEX文档创建。整个过程是可重复的，并且可以集成到TRE作业执行流程中，以实现实时漏洞跟踪。

### 讨论

本研究提出的框架在TRE中实现了代理生成和验证VEX艺术品的新方法。通过将SACRO流程与MCP和Agent2Agent协议相结合，该框架为捕捉、评估和验证情境感知的漏洞信息提供了一个端到端的机制。

除了架构设计，我们还评估了框架的实际性能特征。软件物料清单（SBOM）生成和漏洞扫描在几秒钟内完成，并且运行时监控的开销被限制在测试工作负载中的2-3%。重新执行的可重复性在大多数运行中得到了验证，仅有微小差异归因于外部存储库的变异性。这些结果表明，该框架在理论上是可行的，并且在操作上是可行的，提供了快速验证，同时保持了较低的性能影响。这加强了自动化、情境感知的漏洞报告可以整合到安全研究流程中的主张，而不会造成过高的延迟或资源需求。

该系统通过将确定性元数据捕获、运行时监控、可利用性逻辑评估和加密签名的VEX生成嵌入到TRE流程中，增强了可重复性和安全性。它不同于传统的漏洞扫描，考虑了隔离限制、环境缓解措施和运行时可追溯性，确保只有可利用的风险才会被标记。每个生成的VEX文档都可验证地链接到特定的作业、容器状态和分析血统，创造了一个稳健且可审计的安全足迹。

通过将可重复性与加密保证的VEX认证结合，这项工作解决了在监管研究基础设施中证明安全和政策合规分析活动的长期挑战。通过验证流程，包括作业重放、模式一致性检查和联邦艺术品签名，该框架为在符合GRAIMatter和SACRO透明度目标的环境中实现可扩展、互操作的信任基础设施奠定了基础。

### 研究局限性与建议

尽管所提出的系统在安全研究环境中展示了生成和验证情境感知漏洞声明的可行性，但仍存在一些局限性，需要进一步改进。解决这些挑战对于提升操作稳健性、互操作性和长期可持续性至关重要。

**系统复杂性和计算开销**。将多个监控层、元数据捕获代理和漏洞扫描器集成会引入性能成本，这可能影响资源受限环境中的可用性。为缓解这一问题，未来的实现应采用模块化的微服务架构和资源感知的编排策略，包括Kubernetes集群中的自动扩展机制。这符合NIST SP 800-190（2017）中概述的云原生最佳实践，确保高效资源利用而不损害可重复性保证。

**对外部工具的依赖**。对第三方扫描器如Syft和Grype的依赖引发了关于工具稳定性和长期维护的担忧。采用多重扫描引擎、结果交叉验证和本地缓存漏洞数据的冗余策略可以减少系统性风险，这与ISO/IEC 27036中的供应链安全指导相一致。

**通用性和外部有效性**。当前的验证已在受控案例研究中进行。为了增强外部有效性，应在医疗、基因组学和社会科学等异构领域进行试点部署。在标准化测试平台（如GAIA或类似联邦基础设施）上进行基准测试，将提供比较见解并支持在多样化的TRE中的采用。

**准确性与误报**。误报风险仍然是一个关键问题。采用结合自动化可利用性过滤和定期专家审查的混合方法，可以提高检测准确性。这种方法反映了NIST SP 800-53中提出的纵深防御原则。

**可扩展性和联邦性**。扩展到多租户环境需要分布式编排。一个联邦漏洞管理架构，其中本地环境与中心知识库同步，可以在保持自主性的同时提高一致性。这种模型与ISO/IEC 27001在分布式风险管理中的实践相兼容。

**标准化和互操作性**。标准的碎片化成为采用的障碍。通过与国际标准组织（如ISO、NIST、W3C）合作，并开发桥接工具以转换新兴格式（如SPDX用于软件物料清单和VEX用于情境漏洞信号），可以增强互操作性。

**隐私和监控影响**。广泛的运行时监控可能带来意外数据暴露的风险。这些风险可以通过差分隐私、匿名化和系统性应用数据保护影响评估（如GDPR第35条）来减少。这些保障措施确保了操作洞察力，同时保护了机密性。

**维护和可持续性**。持续的维护对环境操作员构成了负担。这可以通过利用自动化的安全CI/CD管道、同步的隔离漏洞数据库镜像和社区驱动的更新模型来缓解，这反映了开源生态系统的治理实践。

**可重复性和认证**。通过使用Docker或Singularity进行容器化、版本锁定环境和引入可重复性认证方案（如ACM Artifact Evaluation徽章），可以正式化保证声明，并通过研究社区激励采用。

**人工监督和可解释性**。最后，自动化不应取代人工判断。需要引入人工在环的审查机制，并结合可解释的漏洞报告，以保持问责并符合欧盟人工智能法案中关于可信人工智能的原则。

这些建议共同为完善所提出的系统提供了一条路径，将其发展为可扩展、可审计和符合标准的框架。通过解决已识别的弱点，未来的研究可以确保在可信研究环境中漏洞管理既在技术上稳健，又在机构上可信。