截图里只有一条 GitHub 安全公告，怎样找回原始记录？
转发来的 GitHub 安全公告截图通常丢链接、缺范围，按固定顺序用 GHSA 或 CVE 编号找回权威原始记录，并把本地依赖核查留在公告证据之外。
一张转发的 GitHub 安全公告截图并不是原始记录：图片通常会丢掉网址，也可能只截到受影响范围或修复版本。找回的办法是先把截图文字逐字保存，确认发布方域名，再用编号到 GitHub 的公告接口检索——在权衡严重性、可利用性和销售影响之前完成这一步。
GitHub Security Advisory（GHSA）是 GitHub 为它发布的每条安全公告分配的编号，格式为 GHSA-xxxx-xxxx-xxxx；Common Vulnerabilities and Exposures（CVE）是同一漏洞在跨厂商范围内的公开参考编号。GitHub 通过应用程序编程接口（API）发布公告记录——API 是一组返回结构化数据的文档化网络请求，分析师可以用脚本或手工把完整记录拉回来。漏洞说法常以这种方式到达销售侧：厂商或合作伙伴转发图片而不是链接，而缺失的字段恰恰是你需要的字段。恢复从编号开始，而不是从解读开始。
找回原始记录要恢复的六项事实
先采集六项字段：发布方域名；GHSA 编号；软件生态与包名；受影响版本范围；首个修复版本；以及来自记录本身、而不是截图时间戳的权威更新时间。
域名告诉你图片是否真的来自 GitHub；GHSA 或 CVE 是检索键，没有它就没有入口；生态和包名用来对照你的依赖清单，避免“编号正确但对象错误”；范围和修复版本决定升级建议；更新时间显示记录有多新，防止把旧公告当新威胁。对负责核实销售说法的分析师来说，六项缺一不可。把六项写进一份恢复记录，再开口评论，这份记录是后续一切判断的引用基础。
按分析师实际的检索顺序操作
按顺序走完以下步骤。跳过恢复直接看严重性，正是未经验证的说法进入销售简报的路径。
先逐字保留截图文字
把每一个可见字符串原样抄下来：编号、包名、版本号、日期、CVSS 分数。GHSA 编号打错一个字符，检索就会失败，所以抄写时不要顺手修正任何看起来奇怪的内容。这和状态页截图的做法一致：先保留画面，再从官方端点重建记录（参见从状态页截图恢复来源记录）。
确认发布方域名
在浏览器栏或网址片段里找 github.com 或 api.github.com。如果网址被裁掉，格式完整的 GHSA 编号仍指向 GitHub 公告；第三方追踪器转述公告数据的截图只是线索，不是来源。把域名写进恢复记录，来源证据才始终明确。
用 GHSA 或 CVE 检索
GitHub 的全球安全公告 REST API 支持按 GHSA 编号、CVE 编号或软件生态筛选公告列表并获取单条记录（GitHub Docs，“REST API endpoints for global security advisories”，2026 年 8 月 3 日访问）。把截图里的编号作为筛选条件，返回的是结构化编号和漏洞记录，可以直接与截图逐项比对。
核对软件生态与版本范围
返回的记录会写明生态（npm、PyPI、Maven 等）和受影响范围，把两者与截图文字逐一对照——这能抓住最典型的错误：CVE 正确但挂错了包。发现不一致时，以接口返回为准，并在恢复记录里标注差异。
记录修复版本与更新时间
把首个修复版本和记录的发布、更新时间抄进六项记录。销售简报会引用这些字段，所以它们必须来自记录本身，而不是转发时的配文。
本地依赖核查单独做
公告记录无法告诉你：公司是否依赖这个包、是否运行受影响版本、漏洞是否可利用。这是一项独立核查，需要工程或安全团队对照本地依赖清单和线上版本完成。两份记录分开保存：一份说明公告说了什么，另一份说明你的环境在跑什么。
关键事实：GHSA-wf43-fpp3-cf65 的恢复记录
2026 年 7 月 31 日，GitHub 发布了针对 npm 包 @apostrophecms/seo 的公告 GHSA-wf43-fpp3-cf65，关联 CVE-2026-53608。GitHub Advisory Database API 记录（2026 年 7 月 31 日 21:53:56 UTC 发布，一秒后更新；2026 年 8 月 3 日检索）给出的受影响范围为直至 1.4.2，首个修复版本 1.5.0，严重性为高，CVSS 3.1 基础分 8.7。
恢复记录：
- 发布方域名：api.github.com（GitHub Advisory Database）
- GHSA 编号：GHSA-wf43-fpp3-cf65
- CVE：CVE-2026-53608
- 生态与包：npm，@apostrophecms/seo
- 受影响范围：直至 1.4.2
- 首个修复版本：1.5.0
- 更新时间：2026 年 7 月 31 日（21:53:56 UTC 发布，一秒后更新）
- 严重性：高；CVSS 3.1 基础分 8.7
度量背景：CVSS 3.1 分数是公告的评分方法产出的严重性度量，描述的是公告评估的影响，不是你所在组织的暴露程度。发布日期是记录本身的属性，不能当作任何客户受影响或接近成单的证据。
为什么证据边界重要
记录确立的是公告自身的事实，不确立你的环境里发生了什么。为销售核实说法，意味着精确说明哪些被证实、哪些没有；这种精确，是简报在追问下仍然站得住脚的前提。
合成示例——不是真实客户消息。一位合作伙伴在 Telegram 群里转发了一张截图，配文是：“GHSA-wf43-fpp3-cf65 已生效，CVSS 8.7，我们所有账号都暴露了，周五前全部修补。”账号和截止日期仅作示意。
恢复记录能把配文干净地拆开：被证实的是公告、8.7 的 CVSS 分数和首个修复版本 1.5.0；未证实的是合作伙伴是否有账号运行受影响版本、该缺陷在其配置中是否可利用、以及周五截止日期——这三项都不在公告记录里。
仍然未知、且必须由谁核查：
- 你方或合作方是否以受影响版本依赖该包——由工程或安全团队对照本地依赖清单核查。
- 缺陷在你的配置中是否可利用——由安全团队对照受影响组件与环境核查。
- 周五截止日期是否是真实的业务约束——直接问合作伙伴；截图配文不是紧迫性的证据。
截图可能经由 Telegram 到达。Telegram 的隐私政策把机器人描述为独立的第三方服务，可以带或不带消息访问权限运行，界面会显示当前模式，并建议第三方机器人开发者访问数据前先征得许可（2026 年 8 月 3 日访问）。因此，任何收集转发消息的工具都只限于用户主动连接的群。哪个官方来源证明哪项说法，是另一套路由问题，见官方漏洞来源路由。
只有在上述独立恢复方法完成后，工具才进入画面，且边界相同。TOP Prospect 只处理你主动连接且有权访问的 Telegram 群，保留来源证据，输出供人工复核的候选项而不是事实认证，把最终判断留给真人，也不会自动联系群成员。它可以把转发的公告截图与其他提及一起呈现在你关注的群里；恢复记录与本地依赖核查仍由你自己完成。参见产品总览。
FAQ
截图里只有 CVE 编号、没有 GHSA，怎么办？
用 CVE 编号筛选 GitHub 的全球公告列表，返回的记录会包含对应的 GHSA。如果查不到，CVE 可能抄错了或来自其他发布方，如实标注为未证实。
用 GHSA 检索不到结果，是不是公告是假的？
不一定。GHSA 编号是三组各四位字符，抄错一个字符就会检索失败；公告也可能已被撤回或设为私有，或者截图本身不是 GitHub 页面。逐字符对照后再下结论。
公告已发布，是否意味着我们公司受影响？
不是。记录确立的是公告的事实；你是否受影响，取决于该包是否以受影响版本出现在你的本地依赖清单里。这是独立核查，属于工程或安全团队的职责。
下一步：拿起你最近收到的一张公告截图，在打开任何 GitHub 页面之前，先重建六项记录。字段与 API 记录一致，你就有了可引用的来源；不一致，你就提前抓住了一次转发错误。两种情况都值得这两分钟。
常见问题
截图里只有 CVE 编号、没有 GHSA，怎么办？
用 CVE 编号筛选 GitHub 的全球公告列表，返回的记录会包含对应的 GHSA。如果查不到，CVE 可能抄错了或来自其他发布方，如实标注为未证实。
用 GHSA 检索不到结果，是不是公告是假的？
不一定。GHSA 编号是三组各四位字符，抄错一个字符就会检索失败；公告也可能已被撤回或设为私有，或者截图本身不是 GitHub 页面。逐字符对照后再下结论。
公告已发布，是否意味着我们公司受影响？
不是。记录确立的是公告的事实；你是否受影响，取决于该包是否以受影响版本出现在你的本地依赖清单里。这是独立核查，属于工程或安全团队的职责。 下一步：拿起你最近收到的一张公告截图，在打开任何 GitHub 页面之前，先重建六项记录。字段与 API 记录一致，你就有了可引用的来源；不一致，你就提前抓住了一次转发错误。两种情况都值得这两分钟。