项目能运行不代表依赖是安全的。pip install 成功只说明安装流程完成无法证明包来自预期源也无法证明今天安装的内容与上次一致。先锁定解析结果开发阶段应保存明确的依赖版本python -m pip freeze requirements.txt python -m pip checkfreeze 记录当前环境但它不是完整的供应链证明。团队还应在变更评审中说明直接依赖避免只提交一份包含大量间接依赖的无差别清单。检查来源和哈希安装时显式指定可信索引并在高敏感项目使用哈希约束python -m pip install --require-hashes -r requirements.txt启用哈希后清单中的每个分发文件都必须匹配预期摘要。它能降低镜像被替换或同版本文件变化的风险但前提是哈希文件本身经过可信渠道审核。检查当前配置python -m pip config list python -m pip index versions requests不要把带有内部凭据的索引地址提交到仓库。CI 中也应通过密钥管理注入认证信息而不是写进脚本或 requirements 文件。漏洞扫描不能替代评审可以使用组织批准的扫描器发现已知漏洞但结果需要结合实际调用路径判断。一个包存在漏洞不等于项目一定可被利用反过来没有 CVE 也不代表维护者、发布来源和代码行为完全可信。评审新依赖时至少记录维护状态、发布来源、许可证、实际使用模块、变更范围和回滚方式。依赖越小越容易审计功能重复的包不必同时引入。在流水线中设门槛建议把依赖变更拆成独立提交在测试环境中执行安装、单元测试和安全扫描再把锁文件一起评审。生产构建应使用固定的构建环境避免每次从网络即时解析最新版本。还要把依赖变更和发布事件关联起来。出现异常时先比较最近一次成功构建与当前构建的锁文件、镜像摘要和安装日志再决定是否回滚。不要只删除虚拟环境后重新安装因为这会丢失定位问题所需的证据。对于内部私有包应限制发布权限并开启双人审核。包名相近的公共包可能造成依赖混淆构建系统应固定索引优先级禁止在不受控的公共源和内部源之间自动切换。开发者本地能安装不等于 CI 和生产环境应该接受同样的来源。如果项目会执行外部脚本或加载插件还应单独审查安装脚本和构建钩子。依赖包的风险不只在导入后的 Python 代码也可能发生在安装阶段。如果你想系统补齐 Python、代码审计和网络安全工程实践可以参考马士兵网络安全课程学习入口
