先從日誌入手，不要靠猜測
當你的 GitHub 帳戶有地方看起來不對勁，最實用的第一步是取出由你控制的記錄，而不是憑記憶重組事件。GitHub 的個人安全日誌就是這份記錄。
GitHub 的個人安全日誌包含過去 90 日內的動作。來源
由於日誌只涵蓋近期一個固定時段，應盡早匯出。超出這個時段的事件日後不會再出現，你亦無法靠等待把它們找回。
日誌的位置與可用的篩選條件
日誌可在帳戶「設定」的「Archives」下找到「Security log」，並支援按操作者、儲存庫及動作等條件篩選。來源
篩選條件比原始資料量更重要。按操作者、儲存庫或動作收窄範圍，可讓你集中查看關心的時段和層面，而不必在無關的日常活動中逐項翻查。
分析之前，先匯出一份私人副本
「Export」選單可下載 JSON 或 CSV；支援的篩選條件可縮窄匯出範圍。來源
應將匯出檔案視為敏感資料。它包含帳戶活動記錄，包括操作者及動作，並可能透露個人或組織背景。請存放在私密位置，只與直接協助你調查的人分享，避免貼到公開討論串或問題追蹤器。如日後需要向平台支援團隊提供副本，應只分享能回答對方問題、範圍最窄的篩選匯出檔案。
建立事件時間表工作紙
日誌匯出是一份事件清單，不是敘述。把它整理成工作紙，讓觀察、解讀和待查問題分開記錄。簡單結構如下：
| 欄目 | 填寫內容 | 重要性 |
|---|---|---|
| 事件 | 為發生的事情加上簡短標籤 | 方便日後快速掃視 |
| 時間 | 按記錄填寫時間戳，並註明時區 | 避免次序出錯 |
| 操作者 | 記錄中顯示的帳戶或識別碼 | 識別記錄來源，而非真實人物 |
| 動作 | 日誌所述已完成的動作 | 保持該行的事實性 |
| 可信度 | 你對該行相關性及理解準確度的信心 | 區分有力記錄與推測記錄 |
| 待查問題 | 仍需核實的事項 | 防止假設變成事實 |
從匯出檔案填寫工作紙，每個你認為相關的事件佔一行。可信度一欄要誠實填寫：直接從匯出檔案讀取的一行，比從你察覺的變動推斷出來的一行更可靠。若你察覺有變動但找不到對應事件，應記為待查問題，而非結論。
區分已觀察動作與「由誰執行」的證據
這是大多數時間表出錯的地方。日誌中的一項記錄告訴你記錄所述發生了甚麼，以及附有哪個操作者識別碼。但這本身不能確定當時坐在鍵盤前的是哪個人。共用裝置、重用的工作階段、被盜用的憑證，以及合法的自動化程序，都可能產生看似由人操作的記錄。
檢視時，請在腦中保持兩欄思考：
- 已觀察： 記錄中的事件、時間、操作者及動作。
- 未確立： 實際由誰執行、原因為何，以及操作者識別碼是否對應你假設的人。
只有在取得獨立證據後，才把結論寫入第二類。在此之前，這些都應歸入待查問題一欄。
不要將缺失事件當作「甚麼都沒發生」的證據
匯出檔案中的空白並不代表沒有活動。日誌只涵蓋一個固定的近期時段，而匯出結果反映你所套用的篩選條件。若你按某個儲存庫篩選，其他儲存庫的事件就不會出現。若你擔心的變動發生在該時段之外，它也不會在日誌中。應將缺失記錄為待查缺口，而非安心理由。
如果你已失去存取權
如果你完全無法登入查看日誌，請停止從外部重組事件，並使用 GitHub 的官方帳戶復原程序。復原程序是恢復你檢視帳戶能力的途徑。不要要求第三方代你存取帳戶，也不要將單純重設密碼視為調查完成；一旦恢復存取，便應匯出日誌，並圍繞變動發生的時段建立時間表。
簡短檢查清單
- 在 90 日時段向前推移之前，匯出安全日誌。
- 私下保存匯出檔案，並記下匯出日期及時區。
- 套用篩選條件，集中查看關心的時段和層面，如有幫助，再匯出收窄後的檢視結果。
- 建立包含事件、時間、操作者、動作及可信度欄目的工作紙。
- 將每一行標示為已觀察或推斷，並將待查問題分開記錄。
- 將缺失事件記錄為缺口，而非「甚麼都沒發生」的證據。
- 若失去存取權，先使用官方復原程序，然後返回第 1 步。
一個有用的下一步
建立時間表後，下一個問題往往是：還有哪些帳戶與同一個名稱或識別碼有關連。這與閱讀安全日誌是不同任務，有其自身方法：參閱如何找出與某個名稱關連的所有帳戶。請將兩項調查分開進行，以免將其中一項的發現誤當成另一項的證據。