应显式指定官方源、禁用不可信索引、校验哈希、用safety扫描依赖、避免盲目升级、结合ci自动检测并评估实际风险。
pip install 时怎么避免下载恶意包
直接用 pip install 不加约束，等于把信任全交给 PyPI 上的包作者。很多漏洞其实不是代码本身有 bug，而是依赖了带后门的“影子包”（比如 requests 拼错成 requesrs）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 始终加上
--trusted-host pypi.org和--trusted-host files.pythonhosted.org，防止中间人劫持重定向到镜像站投毒 - 用
pip install --index-url https://pypi.org/simple/ --trusted-host pypi.org显式指定官方源，绕过本地配置里可能被篡改的index-url - 禁用
--find-links或--extra-index-url，除非你完全信任那个第三方源——它们常被用来注入伪造包 - 检查包签名：运行
pip install --require-hashes -r requirements.txt，前提是requirements.txt里每行都带--hash=sha256:...
如何快速发现项目里用了已知漏洞的依赖
靠人工查 CVE 不现实。真正有效的是在 CI 或本地开发时跑自动扫描，但工具选错或参数不对，结果要么漏报、要么全是误报。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先用
safety：它基于 pyup 的公开数据库，命令简单——safety check -r requirements.txt；注意加--full-report看具体触发哪条 CVE - 别用
bandit扫依赖，它是静态分析代码逻辑的，对第三方包无效；bandit只适合扫你自己写的.py文件 -
pip-audit更严格，会校验包哈希和已知漏洞，但默认只查安装后的环境——想扫未安装的依赖，得先pip install --dry-run配合--report输出 json 再喂给pip-audit - 扫描结果里看到
CVE-2023-1234，别急着升级；先查这个 CVE 是否真影响你的用法——比如只在 flask 的调试模式下触发，而你生产环境关了 debug，就不用动
修复依赖漏洞时为什么不能无脑 pip install –upgrade
升级看似最直接，但 Python 项目依赖树复杂，一个 pip install --upgrade requests 可能导致 urllib3 版本冲突，或者让 django 因为底层 HTTP 库 API 变更而崩溃。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 永远用
pip install --upgrade --no-deps先单独升级目标包，再手动验证是否破坏其他依赖 - 查清楚漏洞影响范围：运行
pip show requests看当前版本，再查对应 CVE 的affected versions字段——有时只需升到2.28.2，而不是跳到2.30.0 - 如果项目用了
poetry或pipenv，别绕过锁文件直接pip install；该用poetry update requests或pipenv update requests，让工具重新解依赖并写入poetry.lock或Pipfile.lock - 升级后必做：跑一遍
python -m pytest tests/ -x，尤其关注网络请求、JSON 解析、证书验证相关测试——这些是漏洞高发区
github Actions 里自动扫描依赖漏洞的最小可行配置
本地扫完不等于上线就安全。CI 里漏掉扫描，等于把风险留给部署环节。但配置太重，会拖慢构建；太轻，又容易跳过关键检查。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用 GitHub 官方的
dependabot+code scanning组合：在.github/workflows/security.yml里启用actions/setup-python后，加一步pip install safety && safety check -r requirements.txt || exit 1 - 别在
on: push下运行完整扫描——改个 README 也触发，浪费资源；改成on: [pull_request, schedule]，且只在requirements.txt或Poetry.lock变更时才执行 - 扫描失败要阻断合并：确保 workflow 中这步设置了
if: always()并且 exit code 非 0 时标记 job 失败，否则safety报出中危漏洞也会被忽略 - 输出结果别只写日志：加
safety check -r requirements.txt --output=json > safety-report.json，再用github/codeql-action/upload-sarif推送到 GitHub Security tab，方便团队统一查看
真正的难点不在工具链，而在判断“这个 CVE 对我到底有没有实际风险”。同一行 requests.get() 调用，在内网调用和外网调用，风险等级可能差两个数量级。得结合网络拓扑、输入来源、错误处理方式一起看，不能光盯着 CVE 描述里的“远程代码执行”四个字。