SurrealDB 供应链安全实践基于 cargo-vet 与 cargo-deny 的 Rust 依赖审查机制【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb导读供应链攻击已成为开源软件面临的主要安全威胁之一——攻击者不再直接攻击项目自身代码而是通过向第三方依赖中注入恶意代码来间接渗透。本文以 SurrealDB 仓库一个可扩展、分布式、面向实时 Web 的文档图数据库的 supply-chain/README.md 为核心骨架系统讲解该仓库如何通过cargo-vet与cargo-deny建立依赖审查机制、如何在 CI 中落地执行、贡献者遇到依赖检查失败时的完整处理流程以及工作区内 crates.io 发布包的信任策略。读完本文你将掌握一套可复制的 Rust 依赖供应链安全基线方案并能直接对照仓库中的 deny.toml、supply-chain/config.toml、supply-chain/audits.toml 与 supply-chain/imports.lock 理解每一处配置背后的安全意图。一、供应链安全目标压缩攻击面抬高攻击门槛SurrealDB 将供应链安全的核心目标定义为减轻攻击者向 SurrealDB 所依赖的第三方依赖中注入恶意代码所造成的影响。在当前阶段其具体目标有三层在 CI 流程中考虑依赖的来源与访问权限——建立一套基础机制让依赖是否可信成为持续集成过程的一部分限制完全暴露于供应链攻击的依赖数量——缩小 SurrealDB 的依赖攻击面抬高针对现有依赖发起成功供应链攻击所需的成本——即便攻击者想动手也面临更高门槛。这与仓库根目录 SECURITY.md 中声明的整体安全策略相互呼应后者负责已知漏洞known vulnerabilities的检查cargo deny check、Dependabot alerts、OSS-Fuzz 模糊测试而本文所讲的供应链机制则着眼于未知的恶意代码注入风险。两者共同构成 SurrealDB 依赖安全的两道防线。二、核心机制cargo-vet 基础配置 CI 强制执行当前阶段SurrealDB 的供应链安全实现为对主仓库进行的一版基础cargo-vet配置该工具作为 CI 的一部分执行。相关配置文件的所有权归属为surrealdb/security团队这一点在 .github/CODEOWNERS 中有明确登记——不仅是supply-chain/*目录包括Cargo.lock、Cargo.toml、deny.toml、SECURITY.md甚至CLAUDE.md等安全敏感文件都由该团队负责审阅。2.1 为什么需要 cargo-vetRust 生态的依赖数量庞大SurrealDB 的Cargo.lock中锁定了数以千计的传递依赖项目自身无法对每个依赖进行深度人工审计。cargo-vet的设计思路是审计复用将哪些 crate 被谁、以什么标准审计过以结构化数据形式沉淀下来并支持从其他可信组织导入审计结论从而让项目以较小的成本获得较广的覆盖。SurrealDB 的仓库目录中恰好保存了该工具的三个关键状态文件文件作用supply-chain/config.tomlcargo-vet主配置版本、外部审计源导入、工作区 crate 信任策略、豁免清单supply-chain/audits.toml项目自身的审计与信任记录[[audits.*]]、[[trusted.*]]supply-chain/imports.lock从外部导入审计数据的锁定记录以及 crates.io 上 crate 发布者身份[[publisher.*]]的哈希锁定2.2 外部审计源信任的传导网络config.toml 通过[imports.*]段落从 7 个可信组织导入审计结论实现一次审计、多方受益[imports.bytecode-alliance] url https://raw.githubusercontent.com/bytecodealliance/wasmtime/main/supply-chain/audits.toml [imports.embark-studios] url https://raw.githubusercontent.com/EmbarkStudios/rust-ecosystem/main/audits.toml [imports.fermyon] url https://raw.githubusercontent.com/fermyon/spin/main/supply-chain/audits.toml [imports.google] url https://raw.githubusercontent.com/google/supply-chain/main/audits.toml [imports.isrg] url https://raw.githubusercontent.com/divviup/libprio-rs/main/supply-chain/audits.toml [imports.mozilla] url https://raw.githubusercontent.com/mozilla/supply-chain/main/audits.toml [imports.zcash] url https://raw.githubusercontent.com/zcash/rust-ecosystem/main/supply-chain/audits.toml这些组织字节码联盟、Embark Studios、Fermyon、Google、ISRG、Mozilla、Zcash 生态均长期维护自己的cargo-vet审计数据。配合 imports.lock 中记录的发布者身份信息cargo-vet得以判断一个依赖要么由可信发布者发布、要么已被某个可信组织直接审计过。2.3 明确承认的当前妥协文档坦率地承认由于缺少专职资源对依赖进行深度审计当前实现做了三方面妥协SurrealDB 员工发布的依赖默认受信任——条件是这些员工是唯一发布者被某些可信组织直接非传递性审计过的依赖默认受信任任何尚未被审计的依赖都豁免于审查流程。同时文档特别强调在本实现中cargo-vet仅作为信息收集工具使用SurrealDB 并不会对第三方依赖进行实质性的安全审查。工具的实际职责是收集第三方审计信息以及盘点哪些依赖由可信开发者发布。换句话说这一机制的定位是降低攻击面、提高攻击成本的防御纵深而非替代人工安全审计的最终保障。三、本地工具安装与依赖检查失败的处理流程3.1 安装依赖检查工具贡献者如需在本地复现 CI 的依赖检查需要安装两个工具cargo install --locked cargo-deny cargo install --locked cargo-vet--locked参数确保安装的版本与Cargo.lock中锁定的版本一致避免工具本身被悄悄升级引入意外行为。3.2 分支一cargo-deny 检查失败已知漏洞cargo-deny的职责是扫描已知安全漏洞RUSTSEC 公告、许可证合规、依赖来源与重复版本等。当依赖检查 action 因cargo-deny失败时按以下流程处理定位受影响的依赖在单独分支上运行cargo update PACKAGE尝试升级如果没有修复版本或无法升级在 deny.toml 的[advisories]段中添加例外条目在例外条目上附加注释说明豁免理由及移除条件通过独立 PR 提交变更并在 PR 中粘贴cargo-deny提供的漏洞详情该依赖更新 PR 由surrealdb/security批准Rebase 你的原始分支使依赖升级生效。关于第 3 步仓库 deny.toml 的[advisories]段正是这一机制的落地样本——文件顶部用多行注释详细记录了每个被忽略公告的来龙去脉例如# TODOs: # - for RUSTSEC-2025-0134, rustls-pemfile is unmaintained (archived) but pulled in transitively # by tonic and axum-server. Upstream crates need to migrate to rustls-pki-types. # - for RUSTSEC-2025-0141, bincode is unmaintained but considered complete and stable at v1.3.3. # Plan migration to wincode, postcard, bitcode, or rkyv in future. Also need surrealmx to update. # - for RUSTSEC-2023-0071, rsa gas a constant-time implementation allowing attackers to recover keys # - for RUSTSEC-2024-0436, paste is now unmaintained and archived, but we only use paste in tests # - for RUSTSEC-2026-0097, rand ThreadRng unsoundness under a narrow combination ... # - for RUSTSEC-2026-0098 and RUSTSEC-2026-0099, rustls-webpki 0.101.7 has name-constraint # handling bugs ... ignore [RUSTSEC-2025-0134, RUSTSEC-2025-0141, RUSTSEC-2023-0071, RUSTSEC-2024-0436, RUSTSEC-2026-0097, RUSTSEC-2026-0098, RUSTSEC-2026-0099]这是一份极佳的例外管理范本每个被忽略的公告都附有上游迁移计划或使用场景限制如仅在测试中使用等待上游 crate 升级 tonic使得例外不是永久免责而是可追踪、有条件、带退出路径的临时处置。此外 deny.toml 还配置了依赖来源白名单[sources]段仅允许 crates.io 索引、许可证白名单[licenses]段允许 MIT、Apache-2.0、BSD、MPL-2.0 等 14 类许可并对 SurrealDB 自家 crate如surrealdb、surrealdb-core、surrealdb-server、surrealism-runtime、surrealml-core等通过[[licenses.exceptions]]单独放行 BUSL-1.1 / Apache-2.0 许可。3.3 分支二cargo-vet 检查失败依赖未经信任/审计/豁免当 action 因cargo-vet失败时含义是该依赖尚未被信任trusted、未被审计audited也未获得豁免exempted。处理流程如下若是新依赖先思考它是否真的有必要引入 SurrealDB若确定要引入分两种情况依赖由 SurrealDB 员工发布且所有发布者都是 SurrealDB 员工可标记为safe-to-deploy信任cargo vet trust PACKAGE其他情况现阶段可将其豁免于审查流程cargo vet add-exemption PACKAGE清理审计列表移除过时条目cargo vet prune变更由surrealdb/security批准。从 supply-chain/audits.toml 的条目格式可以看出这一流程沉淀后的实际形态# 由项目成员亲自审计的 crate可精确到具体版本或版本增量区间 [[audits.easy-parallel]] who Emmanuel Keller emmanuel.kellersurrealdb.com criteria safe-to-deploy version 3.3.1 notes A very simple one file library, no unsafe code. [[audits.quick-xml]] who Micha de Vries michadevrie.sh criteria safe-to-deploy delta 0.26.0 - 0.37.2 # 按发布者身份信任的 crate带发布者 user-id 与信任时间区间 [[trusted.aho-corasick]] criteria safe-to-deploy user-id 189 # Andrew Gallant (BurntSushi) start 2019-02-25 end 2026-11-06值得注意的细节versionvsdeltaversion x.y.z表示对特定版本做了完整审计delta a.b.c - d.e.f表示基于上一版本的审计结论、仅审查了增量变化是升级审计的高效形式criteria常见值为safe-to-deploy可发布到生产与safe-to-run仅可本地运行后者用于deadpool、globset、asn1-rs等 crate可见 SurrealDB 对部署级与运行级信任做了明确区分notes审计者可用简短注释说明审计依据如easy-parallel的单文件库、无 unsafe 代码[[trusted.*]]不针对具体版本而是基于 crates.io 发布者身份的长期信任例如 BurntSushiaho-corasick、regex系列、dtolnayanyhow、serde相关、epageclap系列等知名 Rust 生态维护者。四、工作区 crate 的 crates.io 发布策略文档明确指出本仓库的所有工作区 crate如surrealdb、surrealdb-core、surrealdb-server、surrealism、surrealml-core等中部分同时发布到 crates.io。仓库根 Cargo.toml 的工作区成员列表证实了这一点除了根包外还包含surrealdb/common、surrealdb/ast、surrealdb/parser、surrealdb/core、surrealdb/server、surrealdb/types、surrealism系列与surrealml/core等多个 crate。对于这些自有 crateSurrealDB 在 config.toml 中统一设置了[policy.demo] audit-as-crates-io false [policy.surreal] audit-as-crates-io false [policy.surrealdb] audit-as-crates-io false [policy.surrealdb-core] audit-as-crates-io false [policy.surrealdb-profiling] audit-as-crates-io false [policy.surrealdb-server] audit-as-crates-io false [policy.surrealdb-types] audit-as-crates-io false [policy.surrealdb-types-derive] audit-as-crates-io false [policy.surrealism] audit-as-crates-io false [policy.surrealism-macros] audit-as-crates-io false [policy.surrealism-runtime] audit-as-crates-io false [policy.surrealism-types] audit-as-crates-io false [policy.surrealml-core] audit-as-crates-io falseaudit-as-crates-io false的含义默认情况下cargo-vet会把依赖视为从 crates.io 拉取的第三方包并要求审计而这里显式关闭该行为使这些 crate 无论版本如何都被视为可信的第一方代码。这样做的收益是避免在升级自有 crate 版本时维护逐版本的豁免或审计记录同一份工作区代码既服务于仓库内开发也服务于 crates.io 发布场景无需两套信任体系下游消费者若使用了这些发布到 crates.io 的 crate需要在自己的cargo-vet配置中独立处理信任关系——仓库并不替下游消费者做决定。五、整套机制的落地拼图将本文涉及的文件串起来可以得到 SurrealDB 依赖供应链安全的完整拼图deny.toml——cargo-deny配置扫描已知漏洞RUSTSEC 公告库数据库路径~/.cargo/advisory-db、限制依赖来源仅为 crates.io、白名单化许可证、并携带一份带理由与退出条件的公告豁免清单supply-chain/config.toml——cargo-vet配置声明工具版本version 0.10、导入 7 个外部可信组织的审计数据、为全部自有工作区 crate 设置audit-as-crates-io false并存放未被信任/审计 crate 的豁免条目[[exemptions.*]]每条附criteria多数为safe-to-deploy部分为safe-to-runsupply-chain/audits.toml——审计状态的核心状态机[[audits.*]]成员亲自审计的版本/增量、[[trusted.*]]基于发布者身份的长效信任、[[certified.*]]按需声明的认证结论三类记录共存supply-chain/imports.lock——外部导入数据的锁定快照与 crates.io 发布者身份指纹含user-id、user-login、user-name、发布时间保证信任判断可复现、可审计.github/CODEOWNERS——将supply-chain/*、deny.toml、Cargo.lock、Cargo.toml、SECURITY.md等全部安全敏感文件划归surrealdb/security团队把关配合 PR 审批流程形成人工复核闭环。六、结论与适用边界SurrealDB 的这套供应链安全实现本质上是在资源有限与风险现实之间做出的务实平衡用cargo-vet复用具名组织与可信发布者的审计成果用cargo-deny挡住已知漏洞与不合规许可证用audit-as-crates-io false免去第一方 crate 的重复审查再用 CODEOWNERS 与双 PR 流程引入人工把关。它不声称提供深度人工审计而是以信息收集 攻击面收缩 门槛抬高的方式为大规模 Rust 项目提供了一条低成本、可演进的依赖安全基线。对于想在自己项目中复用的读者建议按以下顺序落地先引入cargo-deny建立漏洞与许可证红线再配置cargo-vet导入外部审计源并对自有 crate 设置audit-as-crates-io false最后将deny.toml、supply-chain/目录与Cargo.lock纳入安全团队的 CODEOWNERS 范围——完整配置均可直接对照本仓库的上述文件逐项参考。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考