pip-audit仅扫描Python包的已知安全漏洞，不分析代码逻辑、不检测SQL注入或硬编码密钥；它比对包版本与CVE数据库，支持环境扫描和requirements.txt/pyproject.toml解析，输出含CVE详情的结构化报告。
pip-audit 不扫描你写的代码，只查已安装 Python 包里的已知安全漏洞。 它不分析 .py 文件逻辑，也不检测 SQL 注入、硬编码密钥这类代码层问题——那是 bandit 或 semgrep 的事。如果你在找“代码漏洞”，先确认你真正想查的是依赖包风险，还是自己写的代码缺陷。
pip-audit 能扫什么、不能扫什么
它的工作对象是 Python 包的元数据和版本号，比对 OSV 或 PyPI 的公开漏洞数据库（比如 CVE-2024-12345 是否影响 requests==2.28.1）。它不运行你的代码，也不解析 AST。
- ✅ 扫描当前环境所有已安装包：
pip-audit - ✅ 扫描
requirements.txt中声明但未安装的包：pip-audit -r requirements.txt - ❌ 不扫描
src/或app.py里的函数逻辑 - ❌ 不检测未在
pip list中出现的本地模块（如import myutils且未打包安装） - ❌ 不检查配置文件、环境变量、JSON/YAML 中的敏感信息
为什么 pip-audit -r requirements.txt 有时没结果？
常见原因是：你传的 requirements.txt 里用了注释、空行、或带 -e git+ 这类可编辑安装源，而 pip-audit 默认跳过它们（除非加 --skip-editable=False）。另外，如果文件里只有 django 没写版本号，pip-audit 就无法判断该查哪个版本是否存在漏洞。
- 确保
requirements.txt是“冻结式”格式（含精确版本），例如：requests==2.28.1，而非requests>=2.25.0 - 避免混用
pip-tools生成的requirements.in直接喂给pip-audit—— 先pip-compile requirements.in -o requirements.txt - 若依赖含本地路径（如
./mylib），pip-audit默认忽略；加--skip-editable=False可强制包含（但仅限已通过pip install -e .安装进 site-packages 的）
如何让 pip-audit 在 CI 中真正生效
关键不是“跑起来”，而是让它失败时能阻断流程，并且报告足够明确。默认输出是表格，不适合机器解析；CI 需要结构化反馈。
立即学习“Python免费学习笔记（深入）”；
- 用
--format json输出标准 JSON，便于脚本提取vulnerabilities数量或severity字段 - 加
--strict：只要发现任意漏洞，进程就返回非零退出码，GitLab CI / GitHub Actions 可直接识别为 job 失败 - 慎用
--fix：它只升级到首个修复版本（如从urllib3==1.26.5升到1.26.18），但不会改requirements.txt—— 你得自己pip freeze > requirements.txt同步，否则下次扫描还报 - 首次运行会下载漏洞数据库到
~/.cache/pip-audit，后续快很多；CI 环境建议复用该缓存目录提升速度
真正容易被忽略的一点：pip-audit 报出的某个 CVE，可能根本没影响你的用法。比如 CVE-2023-27997 只在启用 yaml.load() 且传入恶意输入时触发，而你的项目全程用 yaml.safe_load() —— 这时候不该盲目升级，而是加 --ignore 并附内部说明。工具只给线索，判断权永远在人手里。
