徽章实际记录了什么
已验证提交徽章是签名检查的结果，而非品行证明。当你在 GitHub 上看到提交旁的“已验证”标记时，平台只告诉你一件很窄的事：它检查了附加到该提交的加密签名，并且检查通过了。
GitHub 在签名成功验证时将已签名提交标记为已验证。来源
徽章附加在提交上，而非附加在个人身上。它也不是你当前查看的账号的实时安全指标。验证结果是检查在某一时间点发生的历史记录。
一旦验证被记录，即使签名密钥被撤销或过期，该记录仍可能保留。来源
这种持久性对调查者很重要。即使生成徽章的签名密钥已被撤销或过期，旧提交上的徽章仍可能可见。被撤销的密钥不会追溯擦除徽章，过期的密钥也不会使旧提交变为未验证。因此，徽章告诉你的是签名在记录时通过了检查，而不是密钥仍然可信、账号仍然安全，或当前账号持有人就是签名者本人。
第 1 步：区分三个问题
当有人用已验证提交作为开发者声明的证据时，他们通常混淆了三个不同的问题。在评估任何内容之前，先将它们分开。
| 问题 | 已验证徽章能显示什么 | 它本身不能显示什么 |
|---|---|---|
| 该提交是否已签名并验证？ | GitHub 记录了该提交的成功签名验证。 | 谁编写了代码，或代码质量如何。 |
| 现在谁控制该账号？ | 不能直接显示。徽章与提交绑定，而非与当前登录控制权绑定。 | 同一个人是否仍拥有该账号，或账号是否已易手。 |
| 此人是否是其声称的人，或在声称的地方工作？ | 不能直接显示。 | 身份、雇佣关系或代表组织发言的授权。 |
已验证徽章只回答第一行。第二行和第三行需要单独的证据。这与我们关于公开资料搜索能揭示和不能揭示个人什么的指南中描述的纪律相同：公开产物是线索，不是结论。
第 2 步：阅读提交，而不仅仅是徽章
徽章是捷径，而捷径会隐藏上下文。打开提交本身，查看验证结果周围的内容。
- 提交作者字段和提交者字段。 这些是元数据条目，不是谁输入代码的证明。在许多工作流中，它们可以被设置为任何内容。
- 显示的签名密钥。 GitHub 将验证结果与密钥关联。注意密钥是呈现为属于某个账号、组织还是机器人。
- 仓库和分支。 个人分叉中的已验证提交比合并到维护项目中的提交组织权重更低，但两者都不能证明雇佣关系。
- 日期。 旧的已验证提交是历史数据点。它不能说明账号当前的安全状况。
这些字段中的任何一个，单独或一起，都不能确立账号持有人就是传记中指名的人，或此人在资料所述的地方工作。
第 3 步：单独检查当前账号控制权
已验证提交是关于提交的记录。账号控制权是另一个问题，公开页面很少直接回答。你能做的是寻找一致性和连续性。
- 比较账号随时间变化的公开历史。长期、连贯的贡献历史是线索，不是证明。
- 在其他平台上寻找相同的用户名或显示名称。匹配的用户名是线索。它们不能证明账号属于同一个人，因为用户名在不同平台间并不唯一，可能被重复使用或抢注。
- 将个人资料文本、头像和传记视为账号持有人提出的声明，而非已验证的事实。
如果有人将已验证徽章作为其当前控制账号的证明，那是范畴错误。徽章不衡量当前登录安全性，也不确认与你交谈的人就是账号持有人。
第 4 步：寻找独立证据
独立证据是任何不来自提出声明同一账号的内容。例子包括组织自己发布的团队成员列表、会议网站上的演讲列表，或以组织账号维护并有其自身公开记录的仓库。即使是这些也只是佐证，而非身份证明。你的工作是决定组合应获得多少权重，而不是宣布确定性。
决策表：给已验证徽章多少权重
| 情况 | 合理解读 | 剩余不确定性 |
|---|---|---|
| 徽章存在，密钥仍与账号关联，近期提交 | 签名已验证，密钥关联是当前的。 | 不能证明此人控制账号或编写了代码。 |
| 徽章存在，密钥已撤销或过期 | 验证在发生时被记录。 | 不能说明当前密钥信任或账号安全。 |
| 徽章仅存在于旧提交上 | 历史验证记录。 | 不暗示当前活动或控制权。 |
| 徽章缺失 | 该提交上没有已验证签名。 | 缺失不是不当行为的证据；许多合法工作流不会对每个提交签名。 |
| 徽章加上其他地方匹配的用户名 | 值得跟进的线索。 | 用户名不唯一；账号可能属于不同的人。 |
| 徽章加上组织资料提及 | 对可能隶属关系的佐证。 | 不能证明雇佣关系或代表组织发言的授权。 |
常见错误
- 将徽章视为身份检查。 它是签名结果，不是背景调查。
- 假设历史徽章证明当前账号安全。 记录在密钥撤销或过期后仍可能保留，因此徽章不是实时状态灯。
- 将作者和提交者元数据与作者身份混淆。 这些字段是提交对象中的声明，不是关于谁编写代码的已验证事实。
- 将匹配的用户名视为同一人的证明。 两个平台上的相同用户名是线索。它不是账号属于同一人的证明。
- 将分叉上的徽章解读为组织认可。 个人分叉中的已验证提交不能确立组织审查或认可了该工作。
- 假设未签名提交可疑。 许多合法贡献者和工作流不会对每个提交签名。
自我审查清单
在重复基于已验证徽章的开发者声明之前，运行此清单。
- 我是否打开了提交并记录了作者、提交者、密钥、仓库和日期？
- 我是否将“签名已验证”与“账号控制权”以及“身份或雇佣关系”区分开来？
- 我是否检查了密钥是否仍与账号关联，或记录是否可能在撤销或过期后保留？
- 我是否寻找了至少一个不来自同一账号的来源？
- 我是否将匹配的用户名描述为线索而非同一人的证明？
- 我是否避免声称徽章证明当前安全、作者身份或雇佣关系？
保护你自己的数字足迹
如果你签署提交，请记住已验证徽章是你留下的记录。它可能比生成它的密钥更长久。在撤销或轮换签名密钥之前，决定你希望旧提交如何被解读，并保留自己关于何时使用哪些密钥的笔记。如果你维护公开资料，回顾你随时间使用过的用户名，并检查旧账号是否仍指向你。像 TraceSeek 这样的用户名搜索可以帮助你审查自己在 3,000+ 个平台上的已知公开用户名；首次扫描免费，无需注册或登录，结果通常在 20–30 秒内返回。将输出视为待审查的线索列表，而非身份验证。TraceSeek 不更改平台设置，不保证匹配，也不验证任何人的身份。关于我们如何构建证据和限制，请参阅我们的方法论。
关键事实
- GitHub 在签名成功验证时将已签名提交标记为已验证。
- 一旦验证被记录，即使签名密钥被撤销或过期，记录仍可能保留。
- 已验证提交徽章是针对特定提交的签名结果，不是当前账号控制权或身份的证明。
- 跨平台匹配的公开标识符是线索，不是账号属于同一人的证明。
- TraceSeek 覆盖 3,000+ 个平台，提供免费首次扫描，无需注册或登录。