# 漏洞登记库

框架版本：2.0.0-draft.1。状态：拟议的登记库设计与治理流程。本文档并不设立一个运行中的机构，也不宣布任何已被接纳的发现。

## 目的与条目类型

登记库记录主张、证据、决定及其修订历史。被收录并不代表其有效，也不代表获得框架认可。分类属于分类体系的范畴；登记库保存的是评估某项具体发现或提案所依据的记录。

应区分具体发现与类别提案。具体发现涉及一个有限的系统和配置。类别提案则请求设立新的或修订后的机制、家族或安全属性。事件报告可以为二者提供证据，但不应被悄然转化为一个一般性类别。应明确记录条目类型，并关联相关条目。

登记库应保留被驳倒的、重复的、已撤回的以及无法定论的案例。它们可以防止没有依据的主张一再出现，并保存有用的阴性证据。保留须遵守隐私和披露方面的义务；并不要求公开保留个人数据或可操作的利用细节。

## 带版本的记录结构

每个条目都有一个按照《版本与标识符》中的方案编制的稳定标识符，以及条目修订号、模式版本和分类时所用的框架版本。分配标识符表示记录已创建，而不表示已被接纳。除非依法删除或必要的保护措施要求受限处理，早期修订版本仍可被引用；此类变更应留下不含敏感信息的审计说明。

| 字段组 | 必填内容 |
| --- | --- |
| 身份 | entry_id、entry_revision、schema_version、framework_version、entry_kind、title、created_at、updated_at |
| 主张 | 有界的陈述、主张标识符、预期契约、假设、证伪性观测 |
| 范围 | 目标版本、配置引用、部署边界、生命周期、概况标识符及其版本 |
| 威胁 | 参与者或扰动、访问、知识、控制、反馈、预算、时机、排除项 |
| 分类 | property_ids、mechanism_ids、dimension_ids、entry_points、failed_contracts、participating_domains、interaction_locus、propagation、impact_scope |
| 证据 | 评估结果、E0–E6 各方面、协议、判据、对照、单元、执行记录汇总、分析、制品引用 |
| 后果 | 已证实的与潜在的影响、严重性依据、可能性假设、可逆性、恢复的局限 |
| 审查 | review_status、审查人员、独立性披露、利益冲突、理由、尚未解决的标准、决定历史 |
| 披露 | confidentiality_status、适当时与所有者联系的记录、禁发或发布条件、脱敏处理、访问与保留规则 |
| 关系 | 相关条目、重复或取代关系的链接、与既有类别的比较、迁移历史 |

缺少必填信息时，必须给出明确的原因并标记为未决状态。“未知”不等同于空值、布尔值“假”或零。对于类别提案，针对具体目标的字段可以引用提供支持的评估，而不必假装该类别只有一个目标版本。

分类引用确切的规范领域：L1 模型与计算；L2 软件与基础设施；L3 数据与知识；L4 感知与世界表示；L5 解释与目标；L6 记忆与状态连续性；L7 规划与行动；L8 人机交互；L9 集体与系统交互。该模式允许存在多个失效的契约，并允许把失效定位在节点、边、共享资源、群体或子图层面。主要领域是可选的。仅仅经过某个领域，并不意味着该领域失效。

## 证据与结果字段

评估结果为 supported、refuted、inconclusive、quality_issue、hazard_only 或 out_of_scope，每一项都附有对应的主张和理由。它们与行政层面的审查状态相互独立。一个条目可以同时包含一项得到支持的窄主张和一项无法定论的推广。

E0 假设、E1 单次观测、E2 已复现的观测、E3 受控实验、E4 跨条件证据、E5 跨模型证据和 E6 独立重复验证，是《评估方法》中定义的证据方面。每一项都记录 supported、unsupported、not_tested、inconclusive 或 not_applicable，并附上制品和范围。它们不是累进的分数，也不能替代审查人员的判断。对一个窄主张的独立重复验证，并不能证明其具有广泛的适用性。

“尚未解决的标准”字段可以合理地注明：就这一有限决定而言，已不存在尚待满足的标准，前提是残余的局限另行记录。不得为了填满表格而要求臆造一个未满足的标准。不公开的证据并不自动就是薄弱的，但审查人员必须说明他们是否检查过这些证据。无法获取的证据，不能获得与已检查证据相同的验证声明。

## 拟议的审查状态

使用 submitted、under_review、accepted、rejected、withdrawn 和 superseded 作为 review_status 的取值。接纳一项具体发现，意味着所规定的主张满足了成文的审查标准。接纳一项类别提案，还需要满足分类体系中的新颖性和纳入标准。两者都不是对目标系统的认证，也不是对每一个相关部署的断言。

提交后，条目进入 submitted 状态。初步筛查可以把它转入 under_review，或在维持原状态的同时要求补充缺失的信息。经过说理的审查可以得出 accepted 或 rejected；提交者可以请求撤回。被取代的记录会链接到替代它的记录。新的证据可以通过 under_review 重新开启任何实质性决定。应保留先前的决定，并说明其为何发生变化。

重复条目应链接到相关条目，并保留其中任何不同的证据，而不是各自获得独立的接纳声明。一项被否决的提案仍可能包含一项有效的具体发现，只是其新颖性主张未能成立。应把这两项决定分开。撤回并不会抹去一个得到独立支持的事件；当新证据削弱了原有解释时，接纳的决定也可以修改。

## 拟议的治理职责

以下角色只是一项治理提案，而不是声称审查人员或委员会目前已经存在。受理管理人检查完整性并保护敏感材料。技术审查人员审查契约、可达性、控制措施和因果证据。在需要专门知识时，领域审查人员审查后果以及概况中的假设。决定管理人记录结果，并确保所声明的标准得到执行。

在小型项目中，一人可以兼任多个行政角色，但必须披露这种重叠。提交者不应成为其自身条目能否被接纳的唯一实质性审查人员。如果无法获得独立审查，应让该提交保持待审状态，而不是假装具有独立性。财务、雇佣、署名、个人和竞争方面的利益冲突都应予以披露和评估；可能需要回避或增加一名审查人员。

决定记录应写明主张、所审查的证据、适用的标准、尚未解决的局限、审查人员的角色、利益冲突、不同意见以及日期。审查不应取决于所属机构或发表渠道的声望。重要的是可复现性和相关的专业知识；对专有系统访问受限的情况应予以说明，而不应被当作自动取消资格的理由。

申诉应指出程序错误、被忽略的证据或有争议的技术推断。在可行的情况下，应由未参与被申诉决定的审查人员进行审查。结果及其理由始终与原始记录相关联。如果没有独立的申诉审查人员，应记录这一局限，并让争议保持可见。本提案并不创设其目前无法行使的权力。

## 接纳与引用

一项具体发现需要具备：规定的安全契约、可信的条件、所主张违反的证据、有界的影响说明、对替代解释的考量以及审查记录。所需的证据取决于主张和概况。一个确定性的实现缺陷，并不需要仅仅为了具备可操作性而进行跨模型测试。

类别提案还需要与最接近的现有类别进行比较，说明区别所在，提供支持性案例，并检验合理的证伪情形。应根据所主张的普适程度，相应地寻求跨条件证据和独立证据。缺少经过审查的概况，是一个需要明确处理的、尚未解决的验收问题，而不是采用任意数值证据阈值的理由。

引用应包括条目标识符、修订号、框架版本、审查状态和主张范围。已提交和正在审查中的条目，是正在评估中的提案。已接纳的条目可以被描述为依照成文流程获得接纳，并注明其局限。被否决或被取代的条目，仍可作为历史决定加以引用。公开摘要应保留这些限定说明，以免脱离上下文的概述把假设变成公认的漏洞。

## 披露与证据访问

对于已部署系统中的具体弱点，在公开可操作的细节之前，需要与负责的所有者进行协调处理。记录联系尝试、相关回复、在有约定时的约定时限，以及作出发布决定的依据。本文档不规定通用的期限，也不允许违反适用义务进行发布。

使用 public、restricted 和 embargoed 作为 confidentiality_status 的取值。公开记录可以描述契约、在适当时受影响的版本、证据摘要和修复措施，同时限制那些会实质性助长滥用的细节。以最小必要的访问权限、保留期限和审计记录存储敏感制品。删除凭据、个人数据和无关的组织信息。

研究人员应向经授权的审查人员提供充分的证据，而不应让有害的复现说明为所有人所获取。如果披露限制妨碍了独立验证，应记录这一具体局限。隐私保护与证据质量是相关但不同的两项决定。保护隐私的摘要值可以确认制品的身份，却不能证明主张的内容。

## 说明性条目

以下是一个说明性的、未执行的示例，而不是已提交或已接纳的登记库发现。其本地示例标识符为 EXAMPLE-RETRIEVAL-01，不得作为正式的登记库条目进行分配。

该主张是：由攻击者控制的检索内容，可能导致某个合成助手在未经授权的情况下更新一项保留的偏好。参与者控制着一份文档，无法更改系统指令或工具权限。拟议的属性为 P04“指令完整性”和 P07“记忆完整性”。入口点是 L3 中的一个信息来源；假设失效的契约涉及 L5 中的解释和 L6 中的持久化。拟议引用的机制为 M05“语义操纵”和 M08“记忆操纵”，有待证据确认。在没有关于行动契约的观测之前，不主张存在 L7“行动完整性”违反。

计划使用的判据是回读保留的状态，以匹配的无害检索作为阴性对照，并对会话进行隔离重置。由于该示例尚未执行，试验次数、观测到的事件和影响均无从获得。评估结果为 inconclusive；E0 可以描述明确的假设，而 E1–E6 为 not_tested。只有在真正创建了提交时，审查状态才会保持为 submitted；这条说明性记录没有任何审查决定。

证伪情形可以是：有证据表明该状态变化需要经授权的用户更新，或者所声称的持久化根本不会发生。另一种可能的解释是测试框架自己写入了该偏好。这个示例说明了如何陈述缺失的证据，而不捏造一项发现。

## 维护与迁移

模式结构的校验应独立于科学上的接纳。一条格式正确的记录，可能包含一项没有依据的主张。应依据指定的框架版本校验标识符引用，并拒绝悄然复用 P、M 或 D 的含义。迁移应记录原有分类、拟议的映射、审查人员和理由；领域的实质性变化需要人工重新分类，而不是自动重新贴标签。

把决定耗时、未解决的争议、披露处理以及反复缺失的字段作为流程证据进行审计。不要把条目数量当作科学质量的证明。当读者能够分辨哪些内容是被提出的、被观测到的、被确立的、受到限制的以及后来被修订的时，登记库才算是成功的。
