Python 3.14.10 更新后怎样检查安全修订

Python 3.14.10 更新后，不能只看“安装命令成功”就认为安全修订已经生效。更稳妥的做法是把检查拆成三层：先核对 Python 官方发布页列出的安全条目，再确认目标进程使用的解释器确实是 3.14.10，最后单独记录 TLS 运行时和第三方依赖的状态。

官方发布页：https://www.python.org/downloads/release/python-31410/

如果目标环境中的 sys.version_info 已显示 3.14.10，且 ssl.OPENSSL_VERSION 与依赖审计结果都被单独记录，才算完成一次可追溯的升级后检查。pip list --outdated 只能说明有哪些包可升级，不能证明 Python 解释器的安全修订已经覆盖。

先确认发布页到底修了什么

Python 官方把 3.14.10 定义为 3.14 系列的第十个维护版，同时也是一次加急安全发布。页面说明它包含大约 120 项 bug 修复、构建改进和文档变更，并特别处理了被攻破的 eMudhra 中间 CA 密钥：ssl 模块将这些密钥加入阻断范围。

页面列出的安全内容还包括两个标准库边界：tarfile.tar_filter 拒绝会替换目标位置的链接，http.cookiejar 拒绝负版本 cookie。检查时应把这些条目当成“这次版本为什么值得更新”的依据，而不要自行把所有常规 bugfix 都描述成安全修复。

为什么只看安装输出还不够

同一台机器上可能同时存在系统 Python、虚拟环境和项目自己的解释器。升级命令使用的 python，未必是服务启动时使用的那个解释器；而且终端里看到的是当前 shell 的 PATH 结果，不等于应用进程的运行时结果。

先在目标虚拟环境或服务同款启动环境里执行下面的只读检查：

# 显示当前命令解析到的解释器路径
command -v python

# 显示解释器版本，确认不是只升级了 pip
python --version

# 让同一个解释器输出完整版本信息
python -c 'import sys; print(sys.executable); print(sys.version)'

这里最重要的是 sys.executable 和版本信息来自同一次解释器调用。若 python --version 与服务启动脚本使用的路径不一致，应优先修正运行入口，而不是继续重复安装。

把本机检查拆成三层证据

一份可追溯记录至少应区分解释器版本、TLS 运行时和第三方依赖。它们回答的是不同问题：第一层确认标准库代码来自哪个 Python 版本，第二层确认 SSL 模块连接到哪个底层 OpenSSL，第三层才是项目依赖是否还有已知漏洞或待升级项。

import ssl
import sys

# 输出解释器版本的结构化字段，避免只记录一行模糊文本
print("python:", sys.version_info[:3])
print("executable:", sys.executable)

# 记录 ssl 模块看到的底层 OpenSSL 标识
print("openssl:", ssl.OPENSSL_VERSION)

如果 sys.version_info 不是 (3, 14, 10)，就不能把这台环境视为完成升级。若解释器版本正确但 OpenSSL 标识与预期不符，应把它作为运行时依赖问题单独处理；不要用“Python 已更新”替代 TLS 组件的记录。

依赖检查和解释器安全修订不是一回事

pip 自身属于 Python 包管理工具，项目安装的包则属于第三方依赖。它们可以用来发现另一个风险面，但不能反向证明标准库安全条目已经安装。建议把包管理器绑定到目标解释器，并把结果作为依赖侧证据保存：

# 确认 pip 属于当前 Python，而不是系统中的另一份 pip
python -m pip --version

# 列出可升级包；这个结果不等同于 Python 解释器安全结论
python -m pip list --outdated

# 项目已配置 pip-audit 时，检查第三方依赖的已知漏洞
python -m pip_audit

最后一条命令依赖项目是否安装并配置了 pip-audit。没有这个工具时，不要把缺少命令写成“没有漏洞”；可以记录为“依赖审计尚未执行”，并由项目既有供应链流程补齐。

升级后的复查记录应该留下什么

一次检查的价值在于别人能复现判断，而不是只看到“已升级”四个字。建议在发布记录、变更单或内部工单中保存以下字段：

• 目标环境和 sys.executable 的实际路径。
• sys.version_info 的三段版本值，以及执行检查的时间。
• ssl.OPENSSL_VERSION 的原样输出。
• Python 3.14.10 官方发布页中与本次升级相关的安全条目。
• 第三方依赖审计是否执行、使用的工具和结果存放位置。

当服务由 systemd、容器或任务调度器启动时，还要把检查放到与服务相同的镜像或启动入口中。否则本地 shell 的成功输出仍然可能对应错误的 Python 路径。

几个容易混淆的判断

问：看到 pip list --outdated 有空结果，是否说明 3.14.10 安全修订完整？
答：不是。它只表示当前索引下没有列出可升级包，和 Python 标准库版本、OpenSSL 运行时是不同证据。

问：python --version 已经是 3.14.10，为什么还要看 sys.executable？
答：因为版本和路径一起记录，才能确认检查对象就是目标环境，而不是 PATH 中偶然排在前面的另一份解释器。

问：只要发布页写了安全发布，就不用做项目侧审计了吗？
答：仍然需要。官方发布页说明的是 Python 本身的修订范围，项目依赖和部署运行时属于另外的风险面。

总结

Python 3.14.10 更新后的检查可以压缩成一句话：用官方发布页确认安全修订，用 sys.version_info 确认目标解释器，用 ssl.OPENSSL_VERSION 记录 TLS 运行时，再用项目既有工具单独审计第三方依赖。四类信息分开保存，才能在后续回滚、迁移或复盘时解释“到底更新了什么、哪个环境生效了、哪些风险还没有覆盖”。