Lib.rs

cargo-auditable

了解构建您的 Rust 可执行文件所使用的确切 crate 版本。在生产环境中以规模审计二进制文件以查找已知错误或安全漏洞，无需零账目记录。

这是通过将依赖树的数据嵌入到编译可执行文件的专用链接器部分中实现的，数据格式为 JSON。

官方支持 Linux、Windows 和 Mac OS。从 v0.6.3 版本开始也支持 WebAssembly。所有其他 ELF 目标都应工作，但在 CI 上未进行测试。

最终目标是让 Cargo 本身将此信息编码到二进制文件中。有一个关于 Cargo 中实现此功能的 RFC，本项目为其铺平了道路：[https://github.com/rust-lang/rfcs/pull/2801](https://github.com/rust-lang/rfcs/pull/2801)

使用方法

# Install the tools
cargo install cargo-auditable cargo-audit
# Build your project with dependency lists embedded in the binaries
cargo auditable build --release
# Scan the binary for vulnerabilities
cargo audit bin target/release/your-project

cargo auditable 与任何 Cargo 命令兼容。所有参数都按原样传递给 cargo。

常见问题解答

这不会使我的二进制文件膨胀吗？

简而言之，不会。即使在包含 400 多个条目的大型依赖树中，嵌入的依赖列表也仅使用不到 4KB。这通常相当于二进制文件大小的 1/1000 到 1/10,000。

我能否让 cargo 总是使用 cargo auditable 构建？

是的！例如，在 Linux/macOS 等 Unix-like 系统上，您可以将以下内容添加到您的 .bashrc

alias cargo="cargo auditable"

如果您使用的是 bash 之外的其他 shell，或者使用别名不是一种选择，请参阅这里。

有任何工具可以消费此数据吗？

漏洞报告

• cargo audit v0.17.3+ 可以检测二进制文件中的此数据并报告漏洞。有关详细信息，请参阅这里。
• trivy v0.31.0+ 在二进制文件中检测这些数据并报告漏洞。请参阅 v0.31.0 版本说明，以获取端到端示例。

恢复依赖项列表

• syft v0.53.0+ 对在二进制文件中检测这些数据提供了实验性支持。在图像或目录上使用时，必须通过添加 --catalogers all 命令行选项来启用 Rust 审计支持，例如 syft --catalogers all <包含可审计 Rust 二进制的容器镜像>。
• rust-audit-info 从二进制文件中恢复依赖项列表并以 JSON 格式打印。

它还可以与通过 JSON-to-TOML 转换器使用 Cargo.lock 的现有工具进行互操作。然而，我们建议原生支持该格式；该格式旨在非常易于解析，即使您的语言还没有为该功能提供库也是如此。

我能否使用用不同语言编写的工具读取这些数据？

是的。数据格式旨在与替代实现进行互操作。实际上，仅需要 5 行 Python 来解析它。请参阅 此处 的数据解析文档。

确切的数据格式是什么？

数据格式由以下 JSON 模式描述 此处。JSON 是 Zlib 压缩的，并放置在名为 .dep-v0 的链接器部分中。您可以在 此处 找到有关解析它的更多信息。

关于嵌入式平台呢？

在不惜任何字节的嵌入式平台上，不应在可执行文件中添加任何内容。相反，它们应在数据库中记录每个可执行文件的哈希值，并将哈希值与其 Cargo.lock、编译器和 LLVM 版本、构建日期等关联起来。这将是一个非常出色的 Cargo 包装器或插件。由于这可以在 5 行 shell 脚本中完成，因此编写此工具的任务留给了读者。

这对可重复构建有影响吗？

数据格式专门设计为不会干扰可重复构建。它不包含时间戳，并且生成的 JSON 已排序，以确保在编译之间是相同的。事实上，这甚至有助于可重复构建，因为现在您知道给定二进制文件的所有版本。

这会泄露任何敏感信息吗？

不会。所有 URL 和文件路径都已删除，但 crate 名称和版本按原样记录。目前 panic 消息已经泄露了所有这些信息以及更多。此外，您可能依法有义务披露对特定开源 crate 的使用，因为 MIT 和许多其他许可证都要求这样做。

关于记录编译器版本呢？

编译器本身 在 v1.73 及以后的版本中嵌入。

在旧版本中，它已在调试信息中存在。在 Unix 上，您可以通过运行 strings your_executable | grep 'rustc version' 来查看它。

关于跟踪静态链接 C 库的版本呢？

这是个好问题。我认为目前还没有任何合理的方式暴露它们。这将是一个很好的补充，但对于初始发布不是必需的。我们可以稍后以向后兼容的方式添加它。采用 该 -src crate 规范 可以使其自然发生，并且还会带来其他好处，所以这可能是最合适的途径。

这能防止供应链攻击吗？

不。请使用 cargo-vet 或 cargo-crev 来实现这一点。

软件物料清单 (SBOMs) 不能防止供应链攻击。即使攻击被发现后，也无法用来评估这种攻击的影响，因为任何值得其字节的恶意库都会从 SBOM 中删除。这适用于几乎所有语言和构建系统，而不仅仅是 Rust 和 Cargo。

处理供应链攻击时，不要依赖 SBOM！

是什么阻止了将此提升到 Cargo 中？

Cargo 本身目前处于 功能冻结状态。