pip-audit 默认只报告不修改文件，--fix 参数不存在；自动升级需解析其输出后调用 pip install 并结合版本约束精准替换，避免破坏兼容性。
线上项目不能靠人工定期跑 pip-audit 或 safety check，必须把扫描、判断、升级、验证串成可自动触发的闭环。核心不是“能不能扫”，而是“扫完之后敢不敢自动动生产环境的依赖”。
pip-audit --fix 会直接改 requirements.txt 吗？
不会。pip-audit 默认只报告，不修改任何文件。--fix 参数也不存在——这是常见误解。它连 pip install --upgrade 都不调用，更不会写回 requirements.txt 或 pyproject.toml。
- 它只做比对：已安装包版本 vs PyPI 官方漏洞数据库 + GitHub Advisory DB
- 输出是只读报告，哪怕加
--json或--format=markdown，也只是格式变化 - 想自动升级，必须自己解析输出，再调用
pip install和版本写入逻辑
怎么安全地自动升级高危依赖（比如 CVE-2024-12345）？
不能无差别 pip install --upgrade。很多包升级主版本会破坏兼容性，必须结合约束条件做精准替换。
- 优先查官方修复公告：确认漏洞是否在某个补丁版本中被修复（如
django>=4.2.10,） - 用
pip install "package>=safe_version"而非pip install package，避免跳到不兼容的大版本 - 升级后必须运行关键测试（至少
pytest tests/test_auth.py这类核心路径），失败则立即回滚 - 写入
requirements.txt前，先用pip freeze | grep package校验实际安装版本是否符合预期
GitHub Actions 里怎么实现“发现高危就自动 PR 升级”？
别在 main 分支上直接改，而是生成一个带描述的 PR，人工确认后再合入。这是线上项目最稳妥的自动化节奏。
立即学习“Python免费学习笔记（深入）”；
- 用
pip-audit -r requirements.txt --json获取结构化结果，过滤"severity": "critical"或"high"的条目 - 对每个高危包，用
pip index versions查可用版本（如pip index versions requests），选满足修复条件的最小安全版 - 用
sed -i '' 's/requests==.*/requests==2.31.0/' requirements.txt（Linux/macOS）或perl -i -pe（跨平台）替换版本号 - 提交时 commit message 写明 CVE ID 和影响范围，例如：
chore(deps): upgrade requests to 2.31.0 for CVE-2024-12345 - PR 标题自动带
[SECURITY] requests: CVE-2024-12345，便于快速识别优先级
真正难的不是脚本写法，而是定义“什么算可自动升级”：比如 urllib3 出现高危漏洞，但你的项目没用到相关 API，升级反而可能引入新 bug。这类上下文判断目前还无法完全自动化，得靠团队维护一份 security-allowlist.json 明确哪些包允许自动修、哪些必须人工评估。
