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 等等中，将以下内容添加到你的 .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库版本呢？

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

这能防止供应链攻击吗？

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

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

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

什么阻碍了将其提升到 Cargo？

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