Zeroclaw 依赖安全审计策略cargo audit 与 cargo deny 双工具、双锁文件治理实战【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw导读本文是 zeroclaw 仓库维护者面向cargo audit/cargo denyCI 告警分流与忽略项治理的完整策略说明。它以.cargo/audit.toml与 deny.toml 两份配置的关系为骨架逐一解释每个被忽略 advisory 的来龙去脉并给出增删条目的标准工作流。读完本文你将掌握为何同一份Cargo.lock下两个工具会出现审计漂移如何区分必须修复的真实 CVE与无解可用的 unmaintained 告警以及如何在升级依赖、剔除 stale 忽略项时既不破坏 CI 门禁、又保持全锁文件噪音可控。一、两个工具两份配置同一份锁文件cargo audit与cargo deny check advisories读的是同一份Cargo.lock但二者的扫描范围截然不同cargo audit读取.cargo/audit.toml读取整个锁文件报告命中任何包的每一条 RustSec advisory——包括工作区依赖树之外的传递依赖。cargo deny读取 deny.toml基于依赖图graph-aware只遍历工作区实际解析出的依赖图仅报告真正被工作区拉入的 crate 的 advisory。因此即使两份配置针对同一Cargo.lockcargo audit仍可能报告cargo deny判定为不适用的 advisory。二者之间的这种漂移由 tracking issue#8519统一追踪。仓库当前的 .cargo/audit.toml 与 deny.toml 正是这一漂移的活样本audit.toml中记录了 23 条忽略项其中仅 3 条同时存在于deny.toml其余 20 条均为仅 audit条目。二、CI 中的安全门两个命令、两种失败语义Security 任务在 .github/workflows/ci.yml 中同时运行cargo audit与cargo deny check advisories任一工具非零退出都会阻塞 PR。但两个工具什么才算失败完全不同工具触发条件退出码cargo audit裸运行无--deny warningsvulnerability 类 advisory1失败cargo auditinformational / unmaintained 类 advisory0允许的警告cargo deny check advisories解析图内 crate 的 vulnerability 或 unmaintained advisory1失败cargo denystale 的图忽略项advisory-not-detected0警告两个关键推论为什么三个 unmaintained deny 必须留在deny.tomlrustls-pemfile、proc-macro-error2、bitmaps仍在cargo deny的解析图内unmaintained advisory 对图内 crate 是 errorexit 1所以必须保留。为什么 stale 图忽略不会破坏门禁条目对应 crate 已不在cargo deny解析图时输出的是advisory-not-detected警告exit 0且绝不会因为从.cargo/audit.toml删除条目而触发。此外还有一类audit-only 忽略它覆盖的 crate 不在cargo deny解析图内只影响cargo audit。删除它时只要 crate 仍被锁定advisory 会重新以允许的警告exit 0形式出现不会导致 CI 失败——所以保留它属于接受的全锁噪音控制而非硬门禁绕过。结论两个工具的区别是范围scope而非严重度severity。当cargo audit报告而cargo deny不报告时应以更窄的cargo deny结果确认 advisory 确实未被拉入同时只要 crate 仍被锁定就保留 audit-only 条目。三、忽略项的两大分类3.1 真实 CVE / 漏洞类必须修复临时忽略这类忽略标记存在可利用缺陷的 advisory临时生效修复落地后必须移除。截至当前该类别没有活跃条目曾在#8519追踪的 wasmtime-wasi CVE 组合RUSTSEC-2026-0149、-0182、-0188、-0222已由 PR #8542 的45.0.3升级和 PR #9589 的47.0.3升级清除临时豁免也从两份文件中移除。在 Cargo.lock 中可以确认 wasmtime 当前解析版本为47.0.4早于 CVE 影响范围。该类别的处理流程新增条目时reason必须是一行且以追踪 issue URL 或 PR 编号结尾修复落地后必须在同一个 PR中同时从.cargo/audit.toml和deny.toml删除该条目。只删一份会让cargo deny对该条目输出advisory-not-detected警告非门禁失败因此两份文件必须保持同步每个文件在其忽略块上方都有一行── tracking #... ──头注释。向同一类别追加条目时保留该头注释新增类别时引入新头注释。3.2 Unmaintained 类 advisory无修复可用半永久忽略这类 advisory 仅为信息性crate 在我们使用的依赖线上没有受维护的继任者。条目半永久存在直到底层依赖被替换例如 GTK3 → GTK4、rumqttc 升级拉入新的rustls-webpki。活跃条目deny audit两份文件都有rustls-pemfileRUSTSEC-2025-0134unmaintained传递依赖等待上游迁移到rustls-pki-types。deny.toml 与 .cargo/audit.toml 均存在锁文件中当前为2.2.0。proc-macro-error2RUSTSEC-2026-0173unmaintained 的 derive/attribute 宏辅助库。仍通过zeroclaw-channels中matrix-sdk的 dev-depsaquamarine存在于cargo deny解析图内Cargo.lock 中锁定2.0.1所以两份文件都需要忽略。bitmapsRUSTSEC-2026-0247unmaintained所有版本均受影响且无补丁版本。锁定的matrix-sdk通过imbl - bitmaps直接、并经eyeball-im间接到达matrix-sdk - eyeball-im - imbl - bitmapsCargo.lock 中bitmaps 3.2.1、eyeball-im/imbl均在解析树内。只有cargo deny不再解析受影响的bitmaps后才能删除deny.toml条目只有Cargo.lock中不再存在受影响的bitmaps后才能删除.cargo/audit.toml条目。追踪 #9899 与上游 matrix-org/matrix-rust-sdk#6859。特别说明RUSTSEC-2025-0167锁定的bitmaps 3.2.1还命中另一条独立的信息性 unsoundness advisoryRUSTSEC-2025-0167描述内存破坏风险无补丁版本。RUSTSEC-2026-0247的豁免不会覆盖它。在当前 Security 任务命令下它保持为允许的cargo audit警告而非被拒绝的 advisory属于按规则有意可见的条目。活跃条目仅 auditcargo deny解析图已不再拉入但仍在Cargo.lockcargo audit读整份锁文件所以这些条目只有从Cargo.lock中彻底移除 crate例如通过cargo update或依赖升级或 advisory 标记所有锁定版本均已修复/不受影响后才能从audit.toml删除rustls-webpki4 条RUSTSEC-2026-0049、-0098、-0099、-01040.102.x副本在 Cargo.lock当前0.102.8但不在解析依赖图中。cargo deny不标记cargo audit标记另有0.103.15副本未被命中。追踪 #8519。GTK3 栈11 条RUSTSEC-2024-0411..-0420、-0429gdk/gtk/atk家族的 gtk-rs 绑定与glib。zeroclaw-desktopTauri在 PR #8544 移除、PR #8565 重新引入后这些 crate 仍在Cargo.lock但cargo deny当前默认目标的解析图不需要它们cargo deny check bans与check advisories不带这些忽略也能干净通过。不要因此假设 crate 已离开依赖树——删除前必须用grep ^name crate$ Cargo.lock复核。追踪 #8519。unic-*5 条RUSTSEC-2025-0075、-0080、-0081、-0098、-0100Unicode 数据表此前经pulldown-cmark与mime_guess传递引入Cargo.lock 中unic-char-range 0.9.0等仍在。与上同理的漂移追踪 #8519。宏/字体辅助库1 条RUSTSEC-2024-0388derivativeCargo.lock锁定2.2.0同漂移追踪 #8519。bincodeRUSTSEC-2025-0141此前经probe-rs builtin-targets传递引入当前锁定2.0.1同漂移追踪 #8519。instantRUSTSEC-2024-0384纯信息性的 unmaintained advisory当前锁定0.1.13同漂移追踪 #8519。已解决可从两份文件安全删除randRUSTSEC-2026-0097自定义全局 logger 中的可重入 unsoundness。注意Cargo.lock仍然解析rand0.8.6、0.9.4 与 0.10.2——crate 并没有消失——但 advisory 将这三个版本都标记为已修复因此没有任何锁定副本受影响忽略不再需要。这也修正了一个常见误解从deny.toml删除只代表解析图事实从audit.toml删除才要求锁文件事实。该类别的处理流程使用简短 reason 说明 crate 角色例如gtk-rs GTK3 bindings; transitive via zeroclaw-desktop/tauri对稳定、且短期内不太可能解决的 unmaintained 警告不要附加; tracking #...牢记两个工具的删除判据不同条目一旦不在cargo deny解析图就应从deny.toml消失这是图事实下次依赖升级或特性变更就可能改变即使 crate 仍在Cargo.lock只有 crate 彻底离开Cargo.lock或所有锁定版本按 advisory 判定已修复/不受影响才从audit.toml删除。直接检查Cargo.lock与 advisory 的 patched-version 范围而不是只依赖cargo deny上次的结果。四、deny.toml 的 v2 配置全景deny.toml 采用 cargo-deny v2 schema除[advisories]外还有三层防线[licenses]默认全拒白名单放行 MIT、Apache-2.0、BSD-2/3-Clause、ISC、Unicode-3.0、OpenSSL、Zlib、MPL-2.0、0BSD、CC0-1.0 等并启用unused-allowed-license allow避免白名单条目失效时报错[bans]multiple-versions deny拒绝解析图中的同 crate 多版本分裂wildcards deny拒绝通配符依赖并维护一批版本精确锁定的[[bans.skip]]预存重复版本windows-* 系列、hashbrown、getrandom、strum 等任何未来出现的新重复版本都会失败 CIdeny块中还有一条临时例外lru:0.18.2RUSTSEC-2026-0253Nostr 缓存例外追踪 #9602[sources]unknown-registry deny、unknown-git deny仅放行 crates.io 官方索引allow-git为空。这一组合把advisory 表面与版本分裂同时纳入门禁是理解 audit-policy 的完整背景。五、追踪 issue 体系#8519Reconcile cargo-audit ignores and remediate wasmtime-wasi CVEs审计/拒绝漂移的 master issue。wasmtime-wasi CVE 组合已彻底修复PR #8542、PR #9589两份文件都不再需要忽略GTK3 栈、unic-*、宏/字体辅助库、bincode、instant已离开deny.toml解析图移除但作为 audit-only 忽略保留到离开Cargo.lockrand因所有锁定版本已修复而从两份文件移除而非离开锁文件。剩余 denyaudit 活跃忽略rustls-pemfile、proc-macro-error2、bitmaps剩余 audit-only 忽略rustls-webpki4 条加上述 19 条锁文件 stale 条目。#9899Triage and remove bitmaps unmaintained advisory waiver追踪RUSTSEC-2026-0247豁免并负责RUSTSEC-2025-0167可见警告的接受与复审。Matrix SDK 依赖变化时重新评估一旦Cargo.lock中无受影响的bitmaps或 advisory 标记所有锁定版本已修复即停止接受RUSTSEC-2025-0167。#8059Policy cleanup: deny.toml ignored-advisory tracking, multiple-versions, wildcards提出为deny.toml忽略块补充逐条目理由的 RFC。本文档是高层策略视图文件内注释是逐条目追踪。六、本地验证流程在推送任何触碰.cargo/audit.toml或deny.toml的 PR 之前按顺序执行cargo install cargo-audit --locked # 一次性安装 cargo audit # 绑定 CI 门禁的等价命令 cargo deny check advisories # 图感知的交叉校验 cargo fmt --all -- --check决策规则若cargo audit报告了不在忽略列表中的 error 级 advisory要么添加带理由与追踪号的临时忽略要么修复底层依赖信息性 advisory 只有在接受理由、负责人、复审/移除条件都被记录时才可以作为未忽略的警告保留——RUSTSEC-2025-0167正是按此规则有意可见若cargo deny报告了cargo audit未报告的 advisory说明两个工具再次漂移应新建或更新追踪 issue。仓库 CI 还有一道每日兜底.github/workflows/daily-audit.yml 每天 09:00UTC调度cargo deny check advisories失败时自动以security、risk:high标签开 issue 并附完整扫描输出且避免重复开单——即使 PR 门禁因路径过滤未触发日扫也不会漏掉新 advisory。七、策略变更日志要点2026-06 至 2026-082026-08-11将RUSTSEC-2026-0247bitmaps豁免从deny.toml镜像进.cargo/audit.toml记录依赖路径与 #9899 生命周期明确RUSTSEC-2025-0167是独立允许警告。2026-08-04合并 PR #9589wasmtime 45.0.3 → 47.0.3清除RUSTSEC-2026-0222并从两份文件移除豁免真实 CVE 类别清零。2026-08-03修正proc-macro-error2回到 denyaudit与wasmtime转为 audit-only的分类明确信息性 advisory 在 audit 是警告exit 0、在图内 crate 的 unmaintained 在 deny 是错误exit 1。2026-07-06 / 07-19从deny.toml移除 20 个已不在解析图的条目后发现其中 20 个仍在Cargo.lock且仍被cargo audit报告于是恢复为 audit-only 忽略——这是图事实 ≠ 锁文件事实最典型的一次教训。2026-06-30初始文档伴随 PR #8542wasmtime 43 → 45.0.3与 PR #8519 创建。这一系列日志本身就是策略迭代的教科书每次依赖升级都可能同时改变解析图与锁文件忽略项的增删必须同时核对两份文件、Cargo.lock实际版本与 advisory 的修复区间三者缺一不可。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考