安全漏洞通告核验：从公告到本地范围

通告核验的目标不是快速给出“有影响”或“无影响”的结论，而是形成可复查的关联链：公告所说的能力、实际启用的产品或插件、受影响的工作流、以及能够证明范围的配置记录。最后核验：2026年7月15日 08:39 UTC。页面引用的外部事实限于指定来源；本页不会假定读者使用了某个版本、某项订阅或特定部署方式。

读取日期与范围字段

已确认：一则2026年7月14日的更新说明，GitHub Copilot for JetBrains 扩展了自带密钥相关能力，并提及插件、提供方和对话体验变化。该表述不能推出所有 JetBrains 工作站已经启用该功能，也不能判断本地凭据是否曾被读取。核验时先抄录页面日期、产品名称和行为描述，再把每个陈述改写成可验证问题，例如“本机是否安装相关插件”“是否配置外部提供方”“密钥由何处保存”。原始页面：来源记录。

将产品名称映射为资产

不要只搜索一个产品词。应在终端管理、软件清单、配置管理和单点登录记录中分别查找编辑器版本、插件标识、启用日期和设备拥有者。检查一：同名插件是否来自不同发布者；检查二：共享模板是否在多个项目目录复制；检查三：离职或闲置设备是否仍保有令牌；检查四：团队设置与个人设置是否覆盖。找不到记录并不表示不存在，只能表示当前证据不足，需要扩大查询范围或要求设备确认。

核对密钥与连接边界

涉及外部提供方的配置时，应检查密钥是否通过受控变量注入、是否可被日志打印、是否具有超出工作所需的权限，以及撤销后是否会影响构建。建议先在非生产项目验证配置读取路径：使用专门测试凭据，执行一次最小请求，确认日志只显示状态而不显示秘密内容。若来源页面没有说明某个具体实现细节，该细节应保持未知；不要从产品更新标题推断网络传输方式或数据留存规则。

写出可审计的结论

核验记录应由“结论、证据、限制、后续动作”四部分组成。例如：已确认某设备存在相关插件，已确认其配置引用受控变量；尚未确认历史日志是否包含敏感值；后续在指定日期前检查日志保留区间。这样的写法让接手人员知道结论来自哪里，也避免把临时观察写成永久保证。若范围很大，应先按高权限项目、共享构建节点和公共模板排序，而不是平均分配检查时间。

关联任务

要建立总览和分级入口，请回到更新入口；要检查变更是否通过代码审查，请打开代码审查；要处理编辑器与工具接入，请阅读开发环境；要安排响应节点，请使用处置时间线；要保存截图、日志摘要和结论，请参照证据记录。