uv 中的漏洞与恶意软件检查
内容提要
uv 推出两项预览安全功能：uv audit 可扫描依赖漏洞及弃用状态，速度比 pip-audit 快 4 至 10 倍；uv add、uv sync 等同步操作可检查 OSV 恶意软件通告，需设置 UV_MALWARE_CHECK=1 启用。由于恶意依赖需主动补救，故采用轻量检查而非独立命令。未来可能默认启用，并探索漏洞感知解析、精准告警及多后端支持。
延伸解读
恶意软件检查为何不独立成命令
文章指出，恶意依赖需要主动补救，因为恶意软件常窃取凭证等敏感信息，一旦发现必须立即响应。与普通漏洞的被动修复不同，恶意软件检查被设计为同步操作中的轻量环节，而非独立的 uv audit 命令。这样能在安装前拦截恶意代码，避免锁文件直接安装已被隔离的恶意包。
锁文件与索引隔离的盲区
PyPI 隔离恶意包时通常只更新索引，底层对象存储中的文件并未删除。而 uv 等锁定安装器在锁文件中直接引用对象存储地址，因此索引层面的隔离状态在锁文件层面不可见。这意味着即使包已被隔离，锁文件仍可能直接安装恶意分发。轻量恶意检查正是为了弥补这一盲区。
性能对比的适用条件
uv audit 在典型项目上比 pip-audit 快 4 至 10 倍，但文章脚注提醒，这种比较并非完全对等。如果 pip-audit 使用完全预热的缓存，其速度可能与 uv audit 大致相当。因此，性能优势主要体现在常规调用场景，而非所有情况。
未来可能的方向与当前限制
两项功能均处于预览阶段，可能有不稳定和破坏性变更。恶意检查目前依赖公开通告，而恶意包从公开可见到被检测存在延迟，因此文章建议采用依赖冷却期。未来可能默认启用恶意检查，并探索漏洞感知解析、精准告警及支持 OSV 之外的后端。
Q&A
uv audit 是什么？它和 pip-audit 相比有什么优势？
uv audit 是 uv 新推出的安全扫描命令，用于检查依赖中的已知漏洞和不良项目状态（如已弃用）。它是 pip-audit 的 uv 原生替代品，在典型项目上速度比 pip-audit 快 4 到 10 倍。
uv 的恶意软件检查功能如何启用？它会在什么时候触发？
恶意软件检查功能默认不启用，需要通过设置环境变量 UV_MALWARE_CHECK=1 来开启。它会在执行 uv add、uv sync 等任何导致同步的操作时触发，uv 会向 OSV 查询当前锁定解析中是否存在恶意软件通告，如果匹配则终止同步。
为什么 uv 要内置漏洞扫描功能，而不是继续使用 pip-audit 等现有工具？
主要有两个原因：一是提供 uv 原生体验，让漏洞扫描成为工程流程中的一等公民，无需集成独立工具，并能利用 uv 的锁定解析、uv.toml 和 pyproject.toml 配置；二是性能，uv 可以利用高效的网络、缓存、包解析等原语，实现更快的扫描。
恶意依赖和普通漏洞在修复方式上有什么不同？为什么 uv 采用轻量检查而不是独立命令？
普通漏洞通常只需被动修复，即升级到非漏洞版本即可；而恶意依赖需要主动修复，因为恶意软件常窃取凭证等敏感信息，必须立即响应。此外，恶意软件会被索引隔离，但锁定文件可能仍直接指向底层存储，导致隔离后仍可安装。因此 uv 采用轻量检查，在同步时终止恶意安装，而不是依赖独立的审计命令。
uv 未来在安全扫描方面有哪些计划？
uv 计划进一步集成漏洞扫描与包管理，例如在解析时考虑已知漏洞以最小化风险，或仅在新增依赖时提示漏洞以减少告警疲劳；提高发现精度，结合静态分析和可达性分析；支持 OSV 以外的漏洞后端（如 PYSEC、ecosyste.ms）；支持 requirements.txt 和 pylock.toml 等其他打包格式。
uv 的恶意软件检查目前有什么局限性？
当前恶意软件检查依赖公开通告，而恶意软件（尤其是被入侵的包）通常不会在公开后立即被检测到。因此建议使用依赖冷却期，让安全方有时间审查包，避免过早暴露。
