Reading List Verification

正式引用前,所有论文、CVE、GHSA 和会议出处都需要核验。

核验不是行政步骤,而是内容质量控制。ToLO 站点会同时引用学术论文、工业 advisory、GitHub issue、博客和 release note;这些来源的可信度和粒度不同,必须显式标注状态。

这一页的结构

先修概念:来源层级
三种核验状态(verified / pending / unverified)
写入正文前的检查项
来源优先级表
常见冲突处理
常见问题
实战示例

先修概念:来源层级

不是所有链接的权重一样。

来源	可信度	注意点
项目自己的 security advisory	高	通常比二次转载更可靠
NVD / GHSA	高	适合查 CVE 和 CWE,但版本口径有时和项目 release note 不一致
会议官方页面 / DOI / arXiv	高(论文)	注意会议归属年份 vs arXiv 上传年份
项目 release note	中-高	通常是最准确的版本信息,但未必标 CVE 编号
修复 commit	中-高	可以验证 fix 内容,但需要看是否真的对应 CVE
独立研究员博客	中	适合学习背景,不应单独支撑版本范围
二次转载 / news article	低	优先回原始来源
未署名 / 仅 LinkedIn / 仅推文	低	不能作为事实来源

三种核验状态

`verified` — 已核对

已核对官方页面、论文页面、DOI、arXiv、NVD、MITRE、GHSA 或 vendor advisory。

要求:所有事实字段都有可访问的权威来源。

正文可以用确定语:“CVE-2023-XXX 影响 X 项目 ≤ Y.Z 版本”。

`pending` — 待核验

已经列入待写内容,但还没有完成来源核验。

pending 可以进入站点,但正文必须使用限定语:

“据 NVD”
“据 GHSA”
“公开来源显示”
“据论文”

`unverified` — 暂无可靠来源

暂时找不到可靠来源,不能作为事实写入正文。只能作为维护 TODO 或候选线索。

⚠ unverified 不应进入事实性叙述。

写入正文前检查清单

逐项打钩:

CVE ID、GHSA ID、项目名和版本范围是否来自官方或权威来源?
论文标题、作者、会议、年份和 arXiv ID 是否一致?
安全案例是否只描述公开事实和抽象模式?
是否避免写入可直接复现攻击的步骤、私有 PoC 或未披露细节?
版本口径冲突是否显式标注?

来源优先级

安全案例(CVE / GHSA)

按优先级:

项目 security advisory / GHSA(项目自己的)
NVD / MITRE(国家级)
release note + 修复 commit
issue tracker 上 maintainer 的官方回复
第三方 security 网站(Snyk / Mend.io 等)
博客(仅作为线索 / 学习视角)

学术论文

按优先级:

会议官方页面(NDSS / USENIX Security / CCS / S&P / ICLR / NeurIPS / ICML)
DOI 解析(出版社官网)
作者主页 / 实验室主页
arXiv / OpenReview
二次转载 / news article

博客与工具

应核验原始作者和项目仓库,而不是二次转载。
工具:确认许可证、维护状态、最近 commit / push 时间。

当来源层级不一致

优先保留更权威、更接近项目上游的说法。

例如版本范围以 GHSA 或项目 advisory 为准,但如果 NVD 有不同口径,也应在案例页中标出差异。

常见冲突处理

冲突 1:NVD 和 GHSA 版本范围不同

保留两者,frontmatter 写:

case:
  affected_versions: "NVD: < 0.0.236; GitHub Advisory: < 0.0.247"
  fixed_in: "NVD: 0.0.236; GitHub Advisory: 0.0.247"
  verification: pending

正文写:

据 NVD,受影响范围是 < 0.0.236;据 GHSA,< 0.0.247。
两个口径不一致,本站保持 verification: pending。

冲突 2:advisory 写 CWE,但 description 与 CWE 不符

以 advisory CWE 为主,正文说明 mismatch。

冲突 3:commit hash 已查到,但未对应到具体 tag

fixed_in: unknown

正文用 “commit X 之后”。

冲突 4:论文 arXiv 年份和会议年份不同

两者都写清楚:

paper:
  venue: NDSS 2026
  arxiv_id: "2504.19793"   # arXiv 通常先于会议
  year: 2026               # 取会议年

会议归属未确认前标 pending。

冲突 5:博客和官方说法不一致

以官方为准。博客可作为”另一种解读”放入参考链接,但事实陈述必须基于官方。

常见问题

CVE ID 存在就算 verified 吗?

不算。还要核验:

影响组件
版本范围
修复版本
CWE / 描述是否与本站归类一致

博客文章可以作为事实来源吗?

可以作为观点或案例线索,但安全事实仍优先回到官方 advisory 或项目来源。

能否引用私有研究报告?

不能。私有报告只用于校准术语和边界,网页不复制其未公开内容。

一个 fix commit 我看了,但 release note 没提它

只用 commit 信息 + fixed_in: unknown。不要推断它进入了某个 release(除非有 release artifact diff 证实)。

旧 CVE 的修复 commit 我自己核验过,但 NVD 还没更新

仍写 pending,正文说明”本站观察到 commit X 已修复,NVD 尚未同步”。只有当 NVD/GHSA 也同步后,才升级到 verified。

实战示例

示例 1:`verified` 的案例页 frontmatter

case:
  cve_id: CVE-2024-XXXXX
  project: SomeFramework
  affected_versions: "<= 1.2.3"
  fixed_in: "1.2.4"
  public_sources:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-XXXXX
    - https://github.com/example/repo/security/advisories/GHSA-xxxx-xxxx-xxxx
    - https://github.com/example/repo/commit/abcdef
  verification: verified

正文:

CVE-2024-XXXXX 影响 SomeFramework 1.2.3 及之前版本,1.2.4 修复。

示例 2:`pending` 的案例页 frontmatter

case:
  cve_id: CVE-2024-YYYYY
  project: AnotherFramework
  affected_versions: "NVD: <= 2.0; GHSA: <= 2.1"
  fixed_in: "GHSA: 2.2; NVD: unknown"
  public_sources:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-YYYYY
    - https://github.com/example/another/security/advisories/...
  verification: pending

正文:

据 NVD,CVE-2024-YYYYY 影响 AnotherFramework ≤ 2.0;据 GHSA,影响范围 ≤ 2.1。本页保持 verification: pending,待来源对齐。

读完检查

写入一个新案例前,至少回答:

✅ CVE / GHSA / advisory 链接是否可访问?
✅ 版本范围是否来自权威来源?
✅ ToLO 归类是否来自公开事实,而不是推测?
✅ 页面是否避免复制私有报告或未披露细节?
✅ 多个来源之间冲突是否显式处理(标 pending 或注明差异)?

下一步阅读

回到 Public CVE Case Studies,按这个核验状态逐个补案例页。

或回论文消化总览,按相同规则维护论文条目。