pip-audit是最直接轻量的python依赖漏洞扫描方式，因其默认扫描真实运行环境所有已安装包、支持osv.dev实时漏洞库、可递归检测子依赖，而safety仅查直接依赖且不解析pyproject.toml。
用 pip-audit 扫一遍，5 秒内出结果 —— 这是最直接、最轻量、也最贴近生产环境的检测方式。
为什么不用 safety 直接扫 requirements.txt
很多人第一反应是跑 safety check -r requirements.txt，但容易踩两个坑：
-
safety默认只查直接依赖，不递归分析子依赖（比如你装了django，它不会自动检查django依赖的sqlparse或asgiref是否有漏洞） - 它的漏洞库
safety-db不是实时同步 NVD 或 OSV.dev，高危 CVE 通常几小时后才收录，低危可能滞后数天 - 若项目用
pyproject.toml但没生成requirements.txt，safety就完全失效 —— 它压根不解析pyproject.toml
pip-audit 怎么扫才真正覆盖所有已安装包
pip-audit 默认扫描当前 Python 环境中所有已安装的包（即 site-packages 下的全部），这才是真实运行时的风险面。关键操作如下：
- 别只扫文件：
pip-audit -r requirements.txt是“假设性”扫描，而pip-audit（无参数）才是“实况快照” - 指定漏洞源更准：加
--vulnerability-service osv，对接 Google 维护的OSV.dev数据库，覆盖更全、更新更快（尤其对新兴包） - 想看详情别跳过
--desc on：否则只显示包名和版本，看不到漏洞描述、影响范围或是否可被利用 - CI 中要防误报：加
--cache-dir /tmp/pip-audit-cache避免多任务竞争写缓存，再配--timeout 30防网络抖动超时
发现 CRITICAL 漏洞后，升级不是唯一解
看到报告里标着 CRITICAL，别急着 pip install --upgrade。先确认三件事：
- 该漏洞是否真在你的调用路径里？比如
urllib3的某个 CVE 只影响HTTP/2场景，而你项目根本没启用 HTTP/2 ——osv-scanner的调用链分析能帮你判断 - 升级会不会破坏兼容性？
pip-audit不提供修复建议，但osv-scanner会给出“最小升级版本”，比如从requests==2.28.0升到2.29.0而非直接上2.32.0 - 有没有临时缓解方案？某些漏洞可通过配置关闭危险功能（如禁用
yaml.load()改用yaml.safe_load()），比升级更可控
真正容易被忽略的是：扫描工具只能发现“已知”漏洞。一个包没出现在 OSV 或 PyPI 漏洞 API 里，不代表它安全 —— 它可能只是还没被披露，或者漏洞类型不在静态数据库覆盖范围内（比如逻辑缺陷、供应链投毒）。所以，pip-audit 或 osv-scanner 是守门员，不是保险柜。
