16 个版本

0.6.4 2024 年 5 月 8 日
0.6.2 2024 年 2 月 19 日
0.6.1 2023 年 3 月 6 日
0.6.0 2022 年 12 月 7 日
0.1.2 2022 年 7 月 31 日

#16Cargo 插件

Download history 2959/week @ 2024-05-01 2568/week @ 2024-05-08 2247/week @ 2024-05-15 2436/week @ 2024-05-22 2433/week @ 2024-05-29 2601/week @ 2024-06-05 3819/week @ 2024-06-12 3787/week @ 2024-06-19 3053/week @ 2024-06-26 5344/week @ 2024-07-03 2899/week @ 2024-07-10 4032/week @ 2024-07-17 3599/week @ 2024-07-24 2725/week @ 2024-07-31 2185/week @ 2024-08-07 2076/week @ 2024-08-14

11,555 每月下载量

MIT/Apache

74KB
1K SLoC

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)

用法

# 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

常见问题解答

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

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

我可以让 cargo 总是使用 cargo auditable 构建吗?

是的!例如,在 Linux/macOS 等系统上,将其添加到您的 .bashrc 文件中:

alias cargo="cargo auditable"

如果您使用的是 bash 以外的 shell,或者使用别名不是一种选择,请参阅[此处](https://github.com/rust-secure-code/cargo-auditable/blob/a0ed9cb5b98a0c927fa8d78aed04065144b136e7/cargo-auditable/REPLACING_CARGO.md)。

有工具可以消费这些数据吗?

漏洞报告

  • cargo audit v0.17.3+ 可检测二进制文件中的此数据并报告漏洞。详情请见这里
  • trivy v0.31.0+ 可检测二进制文件中的此数据并报告漏洞。有关端到端示例,请参阅v0.31.0 版本说明

恢复依赖列表

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

它还可以与通过 JSON-to-TOML 转换器消费 Cargo.lock 的现有工具进行互操作。然而,我们建议原生支持此格式;该格式旨在非常容易解析,即使您的语言还没有相应的库也是如此。

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

是的。数据格式旨在与替代实现互操作。实际上,使用 Python 解析它只需要 5 行代码。有关解析数据的文档请见 这里

数据格式是什么?

数据格式由 JSON 模式 此处 描述。JSON 是 Zlib 压缩的,并放置在名为 .dep- 的链接器部分。有关解析更多信息,请见 这里

嵌入式平台怎么办?

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

这会影响可重复构建吗?

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

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

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

关于记录编译器版本怎么办?

编译器本身从 v1.73 开始嵌入

在旧版本中,它已经在调试信息中存在。在Unix上,您可以通过以下命令查看:strings your_executable | grep 'rustc version'

那么,如何跟踪静态链接的C库版本呢?

这是一个好问题。我认为目前还没有合理的曝光方式。这将是一个非常好的补充,但不是初始发布的必需品。我们可以在以后以向后兼容的方式添加它。采用-srccrate规范将使其自然发生,并且还将带来其他好处,所以这可能是最好的途径。

这能保护免受供应链攻击吗?

不。为此请使用cargo-vetcargo-crev

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

在处理供应链攻击时,不要依赖于SBOM!

什么阻止了将其提升到Cargo中?

Cargo本身目前正在特性冻结中

依赖项

~4MB
~83K SLoC