WAMR（wasm-micro-runtime）安全策略全解：漏洞报告、披露流程与安全更新订阅指南

• 语言运行时
• 嵌入式
• 物联网

WebAssembly Micro Runtime（WAMR）是一个面向嵌入式与边缘场景的高性能 WebAssembly 运行时，由于它常被嵌入到网关、可信执行环境与资源受限设备中，其安全策略的严谨程度直接关系到宿主系统的安全边界。本文以仓库根目录的 SECURITY.md 为核心，系统梳理 WAMR 项目的安全漏洞报告渠道、报告偏好、披露政策（embargo、CVE 与公告节奏）以及安全更新订阅方式，并结合仓库内的 security_need_to_know.md、security_issue_runbook.md 与 CI 安全扫描配置，深入说明"什么样的缺陷才构成安全漏洞""上报之后团队如何响应"以及"安全补丁如何被审慎发布"。读完本文，你将能准确判断一个 WAMR 缺陷是否应作为安全漏洞上报、选择正确的上报渠道，并理解从受理到公开披露的完整时间线与规则。

安全在 WAMR 项目中的定位

WAMR 官方将安全列为最高优先级（"Security is a top priority"）。这并非一句口号：WebAssembly 的核心价值在于以沙箱机制隔离不可信模块，运行时一旦出现可被利用的缺陷，意味着宿主机的内存、文件系统与网络资源可能暴露给恶意模块。因此项目对疑似安全漏洞的每一条报告都认真对待（"we take all reports of suspected security vulnerabilities seriously"），并准备了多条上报通道与一套标准化的披露流程。

仓库内配套的安全文档体系为此提供了完整支撑，除本文主体 SECURITY.md 外，还包括：

• doc/security_need_to_know.md：帮助上报者与维护者判断"什么问题才算安全漏洞"；
• doc/security_issue_runbook.md：维护者处理安全公告（Security Advisory）的分步行动手册；
• doc/tiered_support.md：定义了 Tier A/B/C 支持级别，安全评估仅针对 Tier A 平台与特性展开。

上报安全漏洞：两条官方渠道

WAMR 提供两条并列的上报渠道，建议按以下优先级选择：

渠道一：GitHub 私有漏洞报告（首选）

对于特定仓库（即本 WAMR 项目仓库）中疑似存在的漏洞，官方明确建议优先使用 GitHub 的**私有漏洞报告设施（private vulnerability reporting facilities）**进行上报。该渠道的优势是：

• 报告内容对公众不可见，避免在修复完成前暴露漏洞细节；
• 维护者可以直接在私有空间内与上报者协作、创建临时私有分支来开发修复；
• 公告（Advisory）起草、CVE 申请与最终发布均可在同一套机制内完成。

渠道二：直接邮件联系核心团队（备选）

如果你认为私有漏洞报告渠道不适合你的特定问题，可以直接发送邮件至 WAMR 核心团队邮箱：wamr-core@googlegroups.com。团队收到邮件后会：

1. 确认收到报告（acknowledge receipt）；
2. 对严重性进行初步分析并设定优先级（prioritize initial analysis of severity）；
3. 持续向上报者通报修复进展与完整公告的时间安排，期间可能进一步索取与漏洞相关的补充信息或指导。

需要特别注意的是响应时限：如果上报后两天内未收到回复，请通过上述邮箱再次联系。

协作范围与保密原则

安全团队可能在不公开的范围内，与 WAMR 核心团队成员、支持 WAMR 的组织、受影响项目的核心贡献者，以及（在适用时）受影响的下游项目与产品进行协作。这意味着从上报到披露之间，信息始终被限制在最小必要范围内。

上报偏好：什么样的报告最有效

为保证安全团队能快速复现、定位与修复，官方对报告内容提出三条明确偏好：

1. 提供详细报告，包含可复现步骤与清晰的影响描述（"detailed reports with reproducible steps and a clearly defined impact"）。可复现性是安全缺陷验证的基石，缺少它，维护者无法确认缺陷真实性，也无法评估影响范围与严重性分级。
2. 每个报告只提交一个漏洞（"Submit one vulnerability per report"）。单一漏洞对应单一报告，便于独立跟踪、修复与分配 CVE，避免多个漏洞耦合导致披露节奏被拖慢。
3. 禁止社会工程攻击（"Social engineering (e.g. phishing, vishing, smishing) is prohibited"）。报告渠道仅用于技术性漏洞沟通，任何钓鱼、语音钓鱼、短信钓鱼等社工行为都被明确禁止。

如何判断你的发现是否构成安全漏洞

在上报之前，建议先参照仓库内的 doc/security_need_to_know.md 进行自查。该文档给出了通用定义——一个安全问题通常指：

• 向未授权方暴露敏感信息；
• 允许对数据或系统状态进行未授权修改；
• 影响系统或其服务的可用性；
• 允许对系统的未授权访问；
• 使使用者能够执行本不该执行的操作；
• 允许使用者否认其已执行的操作。

WAMR 特有的信任模型

该文档同时明确了 WAMR 场景下的信任边界，这是判断漏洞归属的关键：

• Wasm 二进制被视为不可信（untrusted）：任何导致 Wasm 沙箱被突破或运行时崩溃的 Wasm 二进制，都被视为潜在安全问题；
• AoT（Ahead-of-Time）二进制被视为可信（trusted）：AoT 二进制假定由可信来源使用受支持的 toolchain 生成。因此，畸变或被篡改的 AoT 二进制导致沙箱突破或崩溃，通常被归为普通 bug 而非安全问题；
• AoT 编译器/工具链自身的缺陷：如果 wamrc 等工具在正确配置下产出的 AoT 二进制会突破沙箱或导致运行时崩溃，则属于 AoT 工具链的潜在安全问题；而误用/错误配置工具选项导致的后果不被视为安全问题。

上报者自查清单

如果你发现的问题使某个 WebAssembly 二进制能够做到以下任意一点，就应作为安全问题上报；否则可作为普通 bug 处理：

• 突破 Wasm 沙箱（break out of the Wasm sandbox）；
• 读取或修改本不应访问的主机内存、运行时内存或另一个模块的数据；
• 在没有被授予相应 capability 的情况下使用文件、socket、设备访问或其他主机资源；
• 以绕过预期检查的方式调用主机函数或原生 API；
• 使运行时不可用或进入不可恢复状态。

另外，文档特别强调：如果 bug 导致崩溃或挂起（crash or hang），请一律按潜在安全问题上报，由维护者复核后视情况调整分类；"拿不准时，就按安全问题上报"。

维护者视角的分类准则

doc/security_need_to_know.md 也为维护者提供了反向判定准则，理解这些规则有助于上报者预判分类结果：

• 仅影响 Tier A 平台或特性 的 bug 才会被纳入安全评估范围；
• 在沙箱内的行为偏差（如计算结果错误）不视为安全问题；
• 原生 API 与 CLI 遵循**调用方保证（caller guarantee）**原则：调用方传错参数、用户输入畸形选项不属于安全问题（例如向fd_read传入非法文件描述符）；
• 畸形的 .wasm 文件应被优雅处理，若导致运行时崩溃或挂起即为安全问题；而用户构造的 .aot 文件导致任何后果均不被视为安全问题；
• DoS 判定：如果运行时能够恢复并启动另一个模块或在同一实例内执行另一个函数，则不视为不可用，也就不构成 DoS；
• 由无限循环或不正确的递归调用链导致的执行问题，通常也不归为安全问题。

维护者发现潜在漏洞时的即时行动

一旦维护者意识到某个 issue 或 PR 描述的是真实或可能的安全漏洞，应迅速行动以最小化暴露面，具体包括：关闭或编辑公开讨论（感谢上报者并说明安全问题应走 Security Advisory 流程）、创建安全公告并邀请上报者以协作者或报告者身份加入（若上报者不便使用 GitHub Security Advisories，可改用邮件等私有沟通方式），随后遵循 security_issue_runbook.md 进入处理流程。

披露政策：从受理到公开的完整流程

SECURITY.md 的 Disclosure Policy 部分详细规定了漏洞从受理到公开披露的标准化流程，核心环节如下：

1. 受理与指派

安全报告被接收后，会指派一名主要处理人（primary handler），由其协调修复与发布的全过程。

2. 确认与影响面评估

• 确认问题真实性，确定所有受影响版本清单；
• 对代码进行审计，排查是否存在同类潜在问题；
• 为所有仍在维护中的版本准备修复。

关键细节是：这些修复在公告发布前不会提交到公共仓库，而是本地暂存，以确保公开前零信息泄露。

3. CVE 申请与预公告

• 选择一个建议的embargo（禁运/保密）日期，并为漏洞申请CVE（Common Vulnerabilities and Exposures）编号；
• 可在 wamr-dev 邮件列表发布预通知（prenotification），披露受影响项目、严重性等级与 embargo 日期等信息；
• 在 embargo 日期当天，向 wamr-dev 邮件列表发送公告副本，同时将修复推送到公共仓库并部署新构建。

4. 时间线：默认 72 小时

通常 embargo 日期设定为 CVE 发布后的 72 小时，但具体时长可能因漏洞严重性或修复难度而浮动。整体流程可能耗时较长，尤其是在需要与其他项目维护者协调的情况下；官方强调必须遵循上述流程以确保披露方式的一致性与可控性。

5. 事后复盘

鼓励核心团队成员为 WAMR 博客撰写事后分析（post-mortem），详细记录漏洞本身以及为识别和预防同类漏洞所采取的步骤。

维护者视角：安全公告处理手册

仓库内的 doc/security_issue_runbook.md 将上述披露政策细化为可执行的六步操作手册，供维护者（Incident Manager，通常指开启公告的维护者）参考：

1. 初始响应：收到新安全公告后，事件经理应第一时间确认接收，并告知上报者调查将立即开始——安全问题具有最高优先级；
2. 漏洞调查：复现问题、确定受影响版本与平台、填写公告细节；接受报告并创建临时私有分支用于协作修复，邀请必要的协作者与干系人；
3. 沟通与协作：全程使用非公开渠道（优先邮件）；涉及第三方依赖时，若第三方无法快速发布修复，可考虑先以 workaround 快速缓解；
4. 定稿与发布准备：修复完成后定稿公告细节，通过公告页面的按钮向 GitHub 申请 CVE 编号；确定披露日期（通常在一周内），并向 sec-announce@bytecodealliance.org 发送预披露邮件；
5. 补丁版本准备与测试：在私有分支为每个待修补版本创建 PR（需能干净合入、附带各发布分支的 release notes）；在本地对 main 分支运行完整测试套件，并尽量覆盖 CI 矩阵；
6. 公开发布与沟通：发布日当天，先在公共仓库打开不含补丁与发布说明的版本号升级 PR，再从私有分支手工制作公共 PR（不要通过 GitHub Security Advisory 直接合并），合并版本号 PR 并触发发布流程，删除私有分支后用按钮发布公告，最后向 sec-announce@bytecodealliance.org 发送安全发布邮件。

该手册还给出了预披露邮件与安全发布邮件的模板，涵盖发布预计日期、最高严重性问题分级（基于 CVSS 分类方案）、版本号与公告链接等要素。

接收安全更新：订阅 wamr-dev 邮件列表

安全通知会通过wamr-dev 邮件列表分发。如果你希望第一时间获知 WAMR 的安全公告、预通知与披露信息，请订阅该列表（https://groups.google.com/g/wamr-dev）。

需要注意的是，安全预披露与正式公告均通过该列表发送，因此对于将 WAMR 用于生产环境的团队，订阅该列表应视为安全运营的基本动作。

仓库中的安全实践佐证

WAMR 的安全承诺在仓库工程实践中同样有迹可循，以下证据可作为深入研究的入口：

自动化代码安全扫描（CodeQL）

仓库通过 .github/workflows/codeql.yml 在 CI 中集成 GitHub CodeQL 扫描，对 C++ 代码执行security-and-quality查询集，并配合 .github/codeql/codeql_config.yml 指定扫描路径（核心运行时core/iwasm、平台公共层、产品入口等）与排除路径（构建产物、测试目录、第三方依赖core/deps/等）。工作流支持推送（fork CI）、PR 评审门禁、每日定时扫描（UTC 午夜 cron）以及手动触发（workflow_dispatch），并在扫描后对 SARIF 结果过滤已知的误报模式（如cpp/alloca-in-loop、cpp/path-injection等在 WAMR 中属于预期用途的规则），随后上传结果并调用 .github/scripts/codeql_fail_on_error.py 对错误结果执行失败门禁。这说明安全扫描是持续运行的，而非一次性动作。

供应链安全与版本校验

仓库工作流目录下还包含 supply_chain.yml 与 dependabot.yml，并配套 .github/scripts/reuse_latest_release_binaries.py、.github/scripts/fetch_and_compare_version.py 等版本校验脚本，用于降低依赖投毒与版本漂移风险。发布说明 RELEASE_NOTES.md 中也记录了安全相关修复的历史条目，例如wasi_path_symlink中old_path校验的 CVE 修复、LLVMJIT 模式潜在挂起问题的修复，以及"安全公告处理手册（security issue runbook）"文档的引入（#4450），可作为了解历史漏洞形态与修复模式的参考。

沙箱语义的运行时实现

安全文档所描述的"沙箱不可突破"保证，最终落实在运行时的加载校验与执行期检查上。可参考 core/iwasm/interpreter/wasm_loader.c（模块加载与验证）、core/iwasm/interpreter/wasm_interp_fast.c（快速解释器执行期内存访问检查）以及 core/iwasm/common/wasm_memory.c（线性内存边界管理）等实现文件，进一步理解沙箱边界的代码级保障。

常见问题与最佳实践小结

我应该上报还是开普通 issue？

如果问题涉及崩溃/挂起、越权内存访问、沙箱逃逸或未授权资源使用，且影响 Tier A 平台与特性，请走安全上报渠道；在沙箱内的纯计算错误、调用方错误参数导致的问题、用户自造 .aot 导致的问题，可走普通 bug 流程。

上报后多久能收到回复？

官方承诺的核心时限是两天：若两天内未收到回复，应主动再次通过 wamr-core@googlegroups.com 跟进。

修复多久公开？

从 CVE 申请到公开披露默认间隔约72 小时（embargo 期），但会因严重性与修复难度浮动；预披露与正式公告均通过 wamr-dev 邮件列表发布。

给生产环境使用者的建议

• 将 wamr-dev 邮件列表纳入日常安全监控，及时获取预通知与公告；
• 保持对 RELEASE_NOTES.md 中安全修复条目的追踪，及时升级受影响版本；
• 部署时遵循调用方保证原则，对传入原生 API 的参数进行宿主侧校验；
• 对 AoT 二进制仅使用受支持的官方 toolchain 与正确配置生成，并维护可信的二进制分发链路。

结语

WAMR 的安全策略可以概括为一条清晰的闭环：明确的信任模型（Wasm 不可信、AoT 可信、调用方保证）划定了"什么问题才算漏洞"的边界；双渠道上报机制（GitHub 私有漏洞报告 + 核心团队邮箱）保证了上报的私密性与可达性；标准化的披露流程（指派处理人 → 私有修复 → CVE 申请 → 72 小时 embargo → 邮件列表公告）保证了修复在公开前不泄露、公开时口径一致；而CodeQL 定时扫描、供应链校验与历史 CVE 修复记录则展示了安全治理在日常工程中的持续投入。对于将 WAMR 嵌入产品的团队而言，理解并遵循这套策略，是守住 WebAssembly 沙箱安全边界的第一步。

• 语言运行时
• 嵌入式
• 物联网