Vulnerability and malware checks in uv

uv 中的漏洞与恶意软件检测

We’re announcing two new security features for uv: uv audit is a new command that scans your dependencies for known vulnerabilities and “adverse” project statuses (such as being deprecated). It’s a uv-native alternative to pip-audit, and is between 4x and 10x faster on typical projects.

我们宣布为 uv 推出两项新的安全功能：uv audit 是一项新命令，用于扫描你的依赖项中是否存在已知漏洞和“不利”的项目状态（例如已被弃用）。它是 pip-audit 的 uv 原生替代方案，在典型项目上的速度比后者快 4 到 10 倍。

uv add, uv sync, etc. can now perform a lightweight OSV-based lookup for previously-resolved malware on every sync operation. This feature is not enabled by default, but you can try it by setting UV_MALWARE_CHECK=1. Both of these features are in preview for now. They’re considered unstable and there may be breaking changes as we iterate on their design. We encourage you to read our docs, try these out and share your feedback with us!

uv add、uv sync 等命令现在可以在每次同步操作时，基于 OSV 对已解析的恶意软件进行轻量级查找。此功能默认不开启，但你可以通过设置 UV_MALWARE_CHECK=1 来尝试。这两项功能目前均处于预览阶段。它们被视为不稳定版本，随着我们对其设计的迭代，可能会出现破坏性变更。我们鼓励你阅读我们的文档，试用这些功能并与我们分享你的反馈！

Why uv audit?

为什么需要 uv audit？

Developers are reasonably and rightfully concerned about the security of their dependencies, and expect tooling that helps them address those concerns. This is particularly true with the rise of “supply chain” concerns, including: Large, complex and/or opaque dependency graphs; Year-over-year increases in the number of known (i.e. disclosed) vulnerabilities; Decreases in the cost of discovering vulnerabilities, in part due to recent advances in LLM-guided vulnerability discovery and exploitation.

开发者理所当然地关注其依赖项的安全性，并期望有工具能帮助他们解决这些顾虑。随着“供应链”问题的兴起，这一点尤为突出，包括：庞大、复杂且/或不透明的依赖关系图；已知（即已披露）漏洞数量逐年增加；以及由于近期 LLM 引导的漏洞发现和利用技术的进步，导致发现漏洞的成本降低。

At the same time, Python packaging already has tools for auditing dependencies, like pip-audit and safety. So why build a new tool? Two big reasons:

与此同时，Python 打包生态中已经有了用于审计依赖项的工具，如 pip-audit 和 safety。那么为什么要构建一个新工具呢？主要有两个原因：

A uv-native experience: vulnerability scanning should be a first-class citizen in engineering flows, rather than an afterthought. By building auditing directly into uv, we can ensure that users receive a consistent experience and don’t need to integrate a separate tool into their development and testing workflows. Similarly, we believe that a vulnerability scanning should take full advantage of its surrounding context. In uv’s case, that means accelerating audits by leveraging uv’s locked resolutions, as well as supporting configuration in uv.toml and pyproject.toml.
uv 原生体验： 漏洞扫描应该是工程流程中的一等公民，而不是事后补救措施。通过将审计功能直接构建到 uv 中，我们可以确保用户获得一致的体验，无需在开发和测试工作流中集成额外的工具。同样，我们认为漏洞扫描应充分利用其周围的上下文。对于 uv 而言，这意味着利用 uv 的锁定解析（locked resolutions）来加速审计，并支持在 uv.toml 和 pyproject.toml 中进行配置。
Performance: implementing auditing in uv means we can take advantage of performant primitives for networking, caching, package resolution, parsing, etc.
性能： 在 uv 中实现审计意味着我们可以利用其在网络、缓存、包解析、解析器等方面的高性能原语。

Why malware scanning?

为什么需要恶意软件扫描？

The dependency risk environment has shifted dramatically over the past few years: remediating normal vulnerabilities continues to be critical, but users are increasingly affected by actively malicious dependencies as well. The threat of malware in open source dependencies has a subtly different detection and remediation profile than ordinary vulnerabilities.

过去几年，依赖项风险环境发生了巨大变化：修复普通漏洞固然至关重要，但用户也越来越多地受到主动恶意依赖项的影响。开源依赖项中的恶意软件威胁，其检测和修复方式与普通漏洞有着微妙的区别。

Ordinary vulnerabilities often require only passive remediation: patching to a non-vulnerable version is often sufficient unless the vulnerability is being actively exploited. By contrast, malicious dependencies tend to require active remediation: malware frequently steals credentials or other sensitive materials. This means that a malware presence signal requires immediate response.

普通漏洞通常只需要被动修复：除非漏洞正被主动利用，否则修补到非漏洞版本通常就足够了。相比之下，恶意依赖项往往需要主动修复：恶意软件经常会窃取凭据或其他敏感材料。这意味着一旦发现恶意软件，必须立即做出响应。

Malware is remediated in parallel by both users and indices: PyPI, for example, will quarantine known and suspected malware to limit its spread. This is a critical part of remediation, but it presents a new challenge for locking installers like uv: quarantine status means that the malware gets removed from the index, but a lockfile that points directly to the underlying object storage is still capable of directly installing malicious distributions.

恶意软件由用户和索引库并行修复：例如，PyPI 会隔离已知和疑似的恶意软件以限制其传播。这是修复过程中的关键一环，但它为像 uv 这样的锁定安装程序带来了新的挑战：隔离状态意味着恶意软件会从索引中移除，但指向底层对象存储的锁文件（lockfile）仍然可以直接安装这些恶意分发包。

Together, these differences mean that defending users against malicious packages requires a different approach than a discrete uv audit command. The approach we’re exploring is a lightweight malware check when installing packages: whenever you run uv add or any other command that causes a sync, uv will ask OSV whether it has any MAL advisories for your currently locked resolution. If a package in your lockfile matches any known malware advisories, the sync will be terminated before the malicious code has a chance to run.

总之，这些差异意味着保护用户免受恶意包侵害需要一种不同于独立 uv audit 命令的方法。我们正在探索的方法是在安装包时进行轻量级恶意软件检查：每当你运行 uv add 或任何导致同步的命令时，uv 都会向 OSV 查询你当前锁定的解析结果是否存在任何 MAL（恶意软件）公告。如果锁文件中的某个包匹配任何已知的恶意软件公告，同步将在恶意代码有机会运行之前被终止。

Malware checks are currently opt-in: you’ll need to set UV_MALWARE_CHECK=1 to enable them. We’ll evaluate enabling them by default in a future release.

恶意软件检查目前是可选的：你需要设置 UV_MALWARE_CHECK=1 来启用它们。我们将在未来的版本中评估是否将其设为默认开启。

Looking forwards

展望未来

The design space for vulnerability and malware scanning and management is large. These new features are in preview to give us the flexibility to iterate on their design. Some of the things we’re evaluating:

漏洞和恶意软件扫描与管理的领域非常广阔。这些新功能目前处于预览阶段，旨在让我们能够灵活地迭代其设计。我们正在评估的一些方向包括：

Future proofing through further integration: our broader perspective on tooling is that tight integrations between historically devolved features unlock new capabilities that the next generation of developers will take for granted. At the moment, the typical developer’s experiences with vulnerability scanning is either discrete (performing audits as a separate step in CI) or frustratingly integrated (npm install telling you that you have hundreds of vulnerabilities at exactly the moment you don’t want to deal with them).

通过深度集成实现面向未来： 我们对工具的宏观愿景是，将历史上分散的功能进行紧密集成，从而解锁下一代开发者视为理所当然的新能力。目前，开发者在漏洞扫描方面的典型体验要么是离散的（在 CI 中作为单独步骤执行审计），要么是令人沮丧的集成（在 npm install 时，在你最不想处理的时候告诉你存在数百个漏洞）。

But there’s a third way: tools that adapt based on known vulnerabilities and other security signals. For example, imagine a future in which locking a resolution also takes into account any known vulnerabilities among candidate versions, and produces a resolution that preserves compatibility while also minimizing the number and severity of known vulnerabilities. Similarly, imagine a future in which uv add tells you about vulnerabilities, but only when they’re present in a newly added dependency. This is a plausible way to reduce some of the alert fatigue that comes with the npm install-style approach: users still receive in-flow alerts, but only on dependencies they’re considering depending on.

但还有第三种方式：基于已知漏洞和其他安全信号进行自适应的工具。例如，设想未来在锁定解析时，会同时考虑候选版本中的已知漏洞，并生成一个既能保持兼容性，又能最大限度减少已知漏洞数量和严重程度的解析结果。同样，设想未来 uv add 会向你提示漏洞，但仅限于新添加的依赖项中存在漏洞时。这是一种减少 npm install 式方法所带来的“警报疲劳”的可行方案：用户仍然会收到流程内的警报，但仅针对他们正在考虑添加的依赖项。