uv 中的漏洞和恶意软件检查

# uv 中的漏洞与恶意软件检查 来源：https://astral.sh/blog/uv-audit 我们宣布为 `uv` (https://github.com/astral-sh/uv) 推出两项新的安全功能： - `uv audit` 是一个新命令，用于扫描依赖项中的已知漏洞和"不良"项目状态（例如已被弃用）。它是 `pip-audit` 的 uv 原生替代方案，在典型项目上速度快 4 到 10 倍¹ (https://astral.sh/blog/uv-audit#user-content-fn-faster)。 - `uv add`、`uv sync` 等命令现在可以在每次同步操作时执行轻量级的基于 OSV (https://osv.dev/) 的已解析恶意软件查询。此功能默认不启用，但您可以通过设置 `UV_MALWARE_CHECK=1` 来尝试。 这两个功能目前均为预览版。它们被认为不稳定，并且随着我们迭代设计，可能会发生破坏性变更。我们鼓励您阅读我们的文档 (https://docs.astral.sh/uv/reference/cli/#uv-audit)，尝试这些功能，并向我们分享您的反馈 (https://github.com/astral-sh/uv/issues/18506)！ 来自 uv audit 的输出，标识出 aiohttp 和 pyjwt 依赖项中的漏洞 --- ## 为什么需要 `uv audit`？(https://astral.sh/blog/uv-audit#why-uv-audit) 开发者合理且理所当然地关心其依赖项的安全性，并期望有工具能帮助他们解决这些问题。随着"供应链"问题的日益突出，这一点尤为明显，包括： - 庞大、复杂和/或不透明的依赖关系图； - 已知（即已披露）漏洞数量逐年增加 (https://www.cve.org/about/Metrics)； - 发现漏洞的成本降低，部分原因是近期 LLM 引导的漏洞发现和利用方面的进展。 与此同时，Python 打包领域已经有用于审计依赖项的工具，例如 `pip-audit` 和 `safety`。那么为什么还要构建一个新工具呢？两个主要原因： - **原生 uv (https://github.com/astral-sh/uv) 体验**：漏洞扫描应成为工程流程中的一等公民，而非事后补充。通过将审计直接构建到 uv (https://github.com/astral-sh/uv) 中，我们可以确保用户获得一致的体验，无需将单独的工具集成到其开发和测试工作流程中。同样，我们认为漏洞扫描应充分利用其周围的环境。就 uv 而言，这意味着通过利用 uv 的锁定解析来加速审计，并支持在 `uv.toml` 和 `pyproject.toml` 中进行配置 (https://docs.astral.sh/uv/reference/settings/#audit)。 - **性能**：在 uv (https://github.com/astral-sh/uv) 中实现审计意味着我们可以利用网络、缓存、包解析、解析等方面的高性能原语。 ## 为什么需要恶意软件扫描？(https://astral.sh/blog/uv-audit#why-malware-scanning) 过去几年中，依赖项风险环境发生了巨大变化：修复常规漏洞仍然至关重要，但用户也越来越多地受到 (https://openai.com/index/our-response-to-the-tanstack-npm-supply-chain-attack/) **主动恶意** 依赖项的影响。 开源依赖项中的恶意软件威胁，其检测和修复模式与常规漏洞略有不同： - 常规漏洞通常只需要**被动修复**：除非漏洞被积极利用，否则修补到无漏洞版本通常就足够了。相比之下，恶意依赖项通常需要**主动修复**：恶意软件经常窃取凭证或其他敏感材料。这意味着恶意软件存在的信号需要**立即**响应。 - 恶意软件由用户和索引并行修复：例如，PyPI 会隔离 (https://blog.pypi.org/posts/2024-12-30-quarantine/) 已知和可疑的恶意软件以限制其传播。这是修复的一个关键部分，但它给锁定安装器（如 uv (https://github.com/astral-sh/uv)）带来了一个新的挑战：隔离状态意味着恶意软件会从**索引**中删除，但直接指向底层**对象存储**的锁文件仍然能够直接安装恶意发行版² (https://astral.sh/blog/uv-audit#user-content-fn-index)。 总之，这些差异意味着防御用户免受恶意包侵害需要采取与独立的 `uv audit` 命令不同的方法。 我们正在探索的方法是在安装包时进行轻量级恶意软件检查：每当您运行 `uv add` 或任何其他导致同步的命令时，uv (https://github.com/astral-sh/uv) 会向 OSV (https://osv.dev/) 查询其当前锁定的解析中是否有任何 MAL 建议 (https://github.com/ossf/malicious-packages)。如果您的锁文件中存在任何符合已知³ (https://astral.sh/blog/uv-audit#user-content-fn-known) 恶意软件建议的包，同步将在恶意代码有机会运行之前**终止**。 目前恶意软件检查是选择加入的：您需要设置 `UV_MALWARE_CHECK=1` 来启用它们。我们将在未来版本中评估默认启用此功能。 ## 展望未来 (https://astral.sh/blog/uv-audit#looking-forwards) 漏洞和恶意软件扫描及管理的设计空间很大。这些新功能以预览版 (https://docs.astral.sh/uv/concepts/preview/) 形式提供，以便我们在迭代设计时具有灵活性。 我们正在评估的一些事项： - **通过进一步集成面向未来**：我们更广泛的工具视角是，历史上分散的功能之间的紧密集成能够释放新能力，这些能力将被下一代开发者视为理所当然。目前，典型开发者对漏洞扫描的体验要么是离散的（在 CI 中作为独立步骤执行审计），要么是令人沮丧地集成（`npm install` 恰好在你不想处理的时候告诉你存在数百个漏洞）。但还有第三种方式：根据已知漏洞和其他安全信号**自适应**的工具。例如，想象一个未来，锁定解析还会**同时**考虑候选版本中的任何已知漏洞，并生成一个既能保持兼容性，又能最小化已知漏洞数量和严重程度的解析。同样，想象一个未来，`uv add` 会告诉你漏洞信息，但**仅**在新添加的依赖项中存在漏洞时。这是减少 `npm install` 式方法带来的警报疲劳 (https://en.wikipedia.org/wiki/Alarm_fatigue) 的一种可行方式：用户仍然会收到流程内警报，但仅限于他们正在考虑依赖的依赖项。构建这样的未来，唯一的方法就是漏洞扫描与包管理之间的紧密集成。 - **提高发现精度**：漏洞通常只影响依赖项中的特定 API，用户不应收到与其使用无关的警报。要做到这一点，需要传统上三个分离的 Python 工具组（漏洞管理、打包和静态源代码/可达性分析）的参与；我们正在积极探索如何更好地整合 `uv` 和 `ty` 对世界的看法，以提供此类功能。 - **支持除 OSV (https://osv.dev/) 之外的其他漏洞"后端"**，例如 PYSEC (https://github.com/pypa/advisory-database)（通过 PyPI 的 JSON API）和 ecoste.ms (https://ecosyste.ms/)。这些后端在覆盖范围、新鲜度、可缓存性、查询性能等方面具有不同的权衡。在考虑集成时，我们将评估每个后端。 - **支持其他打包格式**，例如 `requirements.txt` 和 PEP 751 (https://peps.python.org/pep-0751/) 的 `pylock.toml`。 您也可以在我们的路线图 (https://github.com/astral-sh/uv/issues/18506) 上查看更多信息。 ## 脚注 (https://astral.sh/blog/uv-audit#footnotes) 1. `uv audit` 和 `pip-audit` 之间的比较有点类似于苹果和橙子，因为两者的典型用途往往不同。简单来说：`uv audit` 比大多数等效的 `pip-audit` 调用要快得多，但使用完全预热的缓存的 `pip-audit` 速度大致与 `uv audit` 相当。↩ (https://astral.sh/blog/uv-audit#user-content-fnref-faster) 2. 当 PyPI 删除（或在此情况下隔离）一个发行版时，它**通常不会**从底层对象存储中删除该发行版；只有索引本身会被更新。换句话说，指向发行版的"指针"被删除，而不是发行版本身。其原因有三：(1) 修改底层对象存储成本高昂，(2) 删除有时需要撤销，撤销索引删除比恢复对象更便宜、更简单，(3) Python 打包整体上认为索引是所有可解析发行版的"权威"视图，因此从索引中删除旨在在逻辑上等同于"硬"删除。相比之下，像 uv (https://github.com/astral-sh/uv)（以及使用 `pylock.toml` 时的 `pip`）这样的锁定安装器会在对象存储中存储对发行版的直接引用。这是一个性能优势（解析被锁定后，安装程序无需获取索引响应），但也意味着索引级别的元数据更改（如隔离状态）在锁文件层不再可见。↩ (https://astral.sh/blog/uv-audit#user-content-fnref-index) 3. 需要注意的是，当前的恶意软件检查实现依赖于公开的建议：恶意软件（尤其是在受感染的包中）通常不会在其公开可见后立即被检测到。这就是为什么我们建议采用依赖冷却期 (https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns)——它为生态系统中的安全方提供了在你暴露于这些包之前审查它们的机会。↩ (https://astral.sh/blog/uv-audit#user-content-fnref-known)