从日志开始，而不是从猜测开始
当你的 GitHub 账号上出现某些看起来不一样的情况时，有用的第一步是调取一份你自己掌控的记录，而不是凭记忆重建事件。GitHub 的个人安全日志就是这份记录。
GitHub 的个人安全日志包含最近 90 天内的操作。来源
由于日志只覆盖最近一段时间，应尽早导出。超出该时间窗口的事件之后不会出现，你也不能靠等待把它们找回来。
日志在哪里，可以筛选什么
该日志可在账号 Settings 的 Archives 下找到 Security log，并支持按操作者、仓库和操作类型等条件筛选。来源
筛选比原始数据量更重要。按操作者、仓库或操作类型缩小范围，可以让你聚焦于关心的时段和层面，而不是在无关的日常活动中翻找。
分析之前先导出一份私密副本
Export 菜单可下载 JSON 或 CSV；支持的筛选条件可以缩小导出范围。来源
请把导出的文件视为敏感资料。它包含账号活动记录，包括操作者和操作，可能透露个人或组织背景信息。请将其保存在私密位置，只与直接协助你调查的人分享，避免粘贴到公开讨论串或问题跟踪器中。如果之后需要把副本交给平台支持团队，请分享能回答其问题的最小筛选范围导出。
建立一份事件时间线工作表
日志导出是一份事件列表，而不是一段叙述。把它转换成工作表，让观察、解读和未解问题保持分离。一个简单的结构就够用：
| 列 | 填写内容 | 为什么重要 |
|---|---|---|
| 事件 | 对发生之事的简短标签 | 便于之后快速浏览每一行 |
| 时间 | 记录中的时间戳，并注明时区 | 避免顺序错误 |
| 操作者 | 记录中作为操作方的账号或标识符 | 标识记录来源，而非某个人 |
| 操作 | 日志称执行了什么 | 让该行保持事实性 |
| 置信度 | 你对这一行相关且读取正确的确信程度 | 区分可靠行与推测行 |
| 未解问题 | 你仍需核查的内容 | 防止假设固化为事实 |
根据导出文件填写工作表，每个你认为相关的事件占一行。诚实使用置信度列：直接从导出文件中读到的行，比从你注意到的变化推断出的行更可靠。如果你注意到了某项变化却找不到对应事件，请将其记为未解问题，而不是结论。
把观察到的操作与“是谁做的”证据分开
这是大多数时间线容易出错的地方。日志中的一条记录告诉你记录称发生了什么、附带了哪个操作者标识符。它本身并不能确定当时在键盘前的是哪个人。共享设备、复用的会话、被盗用的凭据以及合法的自动化，都可能产生看起来像人在操作的记录。
审查时在脑中保持两类思考：
- 已观察： 记录中的事件、时间、操作者和操作。
- 未确立： 在物理上由谁执行、为什么执行，以及操作者标识符是否对应你假设的那个人。
只有在你拥有独立证据时，才把结论写入第二类。在此之前，它们属于未解问题列。
不要把缺失的事件当作什么都没发生的证据
导出文件中的空白并不代表没有活动。日志只覆盖一段明确的近期窗口，导出结果也反映你应用的筛选条件。如果你按某个仓库筛选，其他仓库的事件就不会出现。如果你担心的变化发生在窗口之外，它就不会在那里。请把缺失记录为待调查的空白，而不是安心理由。
如果你已失去访问权限
如果你完全无法登录以访问日志，请停止从外部重建事件，改用 GitHub 的官方账号恢复流程。恢复是让你重新能够审查账号的途径。不要请第三方代你访问账号，也不要把仅重置密码当作调查已完成；一旦恢复访问，就导出日志并围绕变动前后时段建立时间线。
一份简短清单
- 在 90 天窗口向前滚动之前导出安全日志。
- 私密保存导出文件，并记下导出的日期和时区。
- 应用筛选条件，聚焦你关心的时段和层面，如有帮助再导出缩小后的视图。
- 建立包含事件、时间、操作者、操作和置信度列的工作表。
- 将每一行标记为已观察或推断，并把未解问题单独保留。
- 把缺失的事件记录为空白，而不是什么都没发生的证据。
- 如果失去访问权限，先使用官方恢复流程，然后回到第 1 步。
有用的下一步
有了时间线之后，下一个问题往往是还有哪些账号与同一个名字或标识符相关联。这与阅读安全日志是另一项任务，也有自己的方法：参见如何找到与一个名字关联的所有账号。请把两项调查分开，以免其中一项的发现被误当作另一项的证据。