PyCharm 不安全的代码补全是否构成漏洞？

背景

三个月前，作者注意到 PyCharm 推出了一项名为“Full Line Completion”（整行代码补全）的插件功能。该功能利用本地深度学习模型，旨在根据上下文建议并生成整行代码。当用户开始输入时，系统会显示整行建议，用户只需按下 Tab 键即可接受。这本质上是一种针对整行代码的自动补全机制。

为了验证这一功能的安全性，作者进行了一系列测试。首先，作者输入了 import urllib3 并创建新行，随后输入字母 u。此时，IDE 给出了一行被虚线边框标记的建议代码。

核心内容

作者对测试结果的印象并不好。在输入 u 后，PyCharm 建议补全的代码如下：

import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

如果接受这行代码，意味着任何使用 urllib3 发起的不安全请求将不会向用户显示警告。作者并未接受该建议，而是继续实例化一个 urllib3.PoolManager。正如他所担心的那样，后续的建议进一步证实了安全隐患：

import urllib3
urllib3.PoolManager(
    cert_reqs='CERT_NONE',

这一建议试图禁用证书验证（CERT_NONE）。如果 PoolManager 接受此配置，其发出的所有请求都将容易受到中间人攻击（MITM）。如果作者直接接受这段代码，意味着他正在编写的程序存在严重的安全漏洞。如果作者之前也接受了第一条建议，那么 urllib3 甚至没有机会在代码投入生产环境前警告用户这一错误。

显然，这里存在不安全的行为，但要确定这是否应被分配 CVE（通用漏洞披露）编号，必须首先界定哪个软件组件存在漏洞。这种行为是否值得分配 CVE？作者对此表示不确定，并指出这是一个不幸的现状：如果没有安全角度的 Bug 报告，公司往往不太会优先处理此类报告。

作者向 JetBrains 报告了此行为，涉及版本为 “Full Line Code Completion” v253.29346.142。JetBrains 的支持人员显然也不确定这是否属于安全漏洞。当作者询问在确认该报告并非“直接安全漏洞”（作者对此表示同意）后，是否可以发布一篇关于此行为的博文时，JetBrains 要求作者不要公开报告，并指引其参考 PyCharm 的协调披露政策（Coordinated Disclosure Policy）。这让作者感到困惑：这究竟算不算安全漏洞？

最终，作者还是等待了 90 天的披露期，但未收到开发团队的任何实质性更新。作者今天再次使用 “Full Line Code Completion” v261.24374.152 版本进行了双重检查，发现行为完全相同，在两种上下文情境下均建议相同的不安全代码。

作者强调，这并非专门针对 PyCharm 或 JetBrains 的批评，他毫不怀疑此类示例存在于所有可用的代码生成模型中。作者也不认为使用 CVE 来处理此类问题对用户是适当或有帮助的。但是，如果不从源头上优先解决并处理这种行为，意味着需要投入更多工作来缓解用户因信任 IDE 提供的建议而接受不安全代码的风险。

文章最后，作者邀请读者分享对此类代码生成模型特定问题类别的看法，并提供了 Mastodon、Bluesky、电子邮件等联系方式，以及博客归档、RSS 订阅等信息。

关键要点

• 功能机制：PyCharm 的“Full Line Completion”插件利用本地深度学习模型，根据用户输入的前缀建议整行代码，通过 Tab 键一键接受。
• 测试发现：
  • 在导入 urllib3 后，IDE 建议禁用安全警告（disable_warnings），这会掩盖潜在的安全问题。
  • 在创建 PoolManager 时，IDE 建议设置 cert_reqs='CERT_NONE'，这将导致程序极易受到中间人攻击（MITM）。
• 厂商回应：JetBrains 支持人员承认该报告并非“直接安全漏洞”，但要求作者遵循协调披露政策，禁止公开报告细节，且作者在 90 天等待期内未收到实质性更新。
• 行业普遍性：此类不安全建议并非 PyCharm 独有，而是当前所有代码生成模型中普遍存在的问题。
• 责任归属困境：作者认为，虽然使用 CVE 标记此类问题可能并不恰当，但 IDE 厂商若不从源头优先解决模型生成不安全代码的问题，将导致用户因信任工具而引入严重漏洞，增加后续修复成本。

意义与影响

这一事件揭示了当前 AI 辅助编程工具在安全性方面的核心矛盾：便利性 vs. 安全性。

1. 信任陷阱：开发者倾向于信任 IDE 提供的自动补全建议，尤其是当建议看起来语法正确且能加快开发速度时。然而，AI 模型在训练数据中可能包含了大量不安全的编码模式（如禁用证书验证），导致其生成的代码在功能上可行，但在安全上存在致命缺陷。
2. 漏洞定义的模糊性：传统的安全漏洞（CVE）通常针对具体的软件缺陷或配置错误。而由 AI 模型生成的“建议性”代码是否应被视为产品本身的漏洞，目前缺乏明确的界定。JetBrains 的回应反映了行业在这一灰色地带的谨慎态度。
3. 开发者教育的重要性：此案例提醒开发者，在使用 AI 辅助编程时，必须保持警惕，对自动生成的代码进行严格的安全审查，特别是涉及网络请求、权限管理和数据加密等敏感操作时。
4. 厂商责任：代码生成模型厂商需要在算法层面加强安全过滤，或者在 UI 设计上对潜在的不安全建议进行显著警示，而不仅仅是依赖用户的自觉审查。否则，随着 AI 编程工具的普及，因盲目接受不安全建议而导致的安全事故可能会显著增加。