---
title: 系統日誌
eyebrow: Guidant AI 資安檢視 · 模組報告
h1: 系統日誌（jedi-log）
lede: 把系統日誌送到客戶自己的資安監控系統，以及記錄「誰對系統做了什麼操作」供事後稽核。**這塊的內容物本身就是最敏感的那一份**——日誌裡曾經有使用者的登入密碼與登入憑證原文（已補上遮蔽）。而「日誌要送去哪裡」這個設定，目前任何一家客戶的管理員都改得動，改到的卻是全系統共用的那一份——已裁定只給平台管理員改。
---

## 這塊在產品裡做什麼

這塊管兩件事：

1. **把系統日誌即時送到外部伺服器**——客戶通常有自己的資安監控系統，希望我們的日誌也彙整過去一起看。
2. **記錄誰對系統做了什麼操作**——每一次請求都留一筆，供事後稽核查閱，也可以匯出成 Excel。

::: grid2
::: {.card .plain}
#### 它平常在做什麼
1. 系統跑的時候不斷產生日誌
2. 依照「系統設定 → 日誌轉送設定」這一頁填的伺服器位址，**即時轉送**過去
3. 同時把每一次操作記進資料庫，管理員可以在「操作日誌」頁查閱與匯出
:::
::: {.card .crit}
#### 為什麼這塊的風險形狀不一樣
別的模組出事，是「某一份資料外洩」。

**這塊的內容物本身就是最敏感的那一份**——日誌裡曾經有使用者的登入密碼與登入憑證原文（那是共用地基那塊的問題，2026-09-17 之後已經補上遮蔽）。

所以「日誌要送去哪裡」這個設定被改掉，等於把整個系統的內部活動**持續、悄無聲息地**導向別人的機器。
:::
:::

---

## 檢視軌跡

**檢視期間**：2026-09-15 ～ 2026-09-16，另 2026-09-23 補一輪｜**範圍**：模組本體 82 個檔案；另加我們主系統這一端的接線 5 個檔｜**共 3 輪**

> **原始技術報告**放在需求中心的 [FR-097 站](https://guidantai-feature-doc.jedicotech.com/FR-097-2609-log-security-scan/)，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。

| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---:|---|---|---|
| **L1** | 日誌轉送的整條路——誰改得動目的地、路上有沒有保護、送出去的內容 | 39 | 6 票全投完 | 自動檢視找到 2 條（皆中）；**統籌者補查另外找到 1 條高風險** | `scan-L1-log-forwarding` |
| **L2** | 操作記錄的整條路——記什麼、誰查得到、匯出的檔案 | 43 | 3 票全投完，**三票一致** | 自動檢視找到 1 條高風險；執行者人工補查命中 1 個已知缺口 | `scan-L2-api-log` |
| **W5**（主系統接線） | 我們主系統這一端每個請求怎麼被記進操作日誌、記之前怎麼遮密碼、轉送設定誰改得動 | 5 | 1 個疑點、3 票全投完、被否決 | **自動檢視零發現**；執行者開檔實測追出 3 條：第 6、7 條屬這塊，另一條（不必登入就能讓產品停擺）出問題的程式在共用基礎，記在[共用基礎那頁](M04-common.html)第 15 條。**並查證「只給客戶總部改」擋不住第 1 條**（見第 1 條） | `scan-W5`（在 FR-115 站） |

::: {.callout .warn}
**工作單上標為「本輪最重要」的那個疑點，自動檢視完全沒有碰**

第一輪開工時，工作單就寫明最該查的是「改日誌目的地這個權限，是不是客戶層級的」。**自動檢視報的兩條都是「送出去的資料本身」的問題**（沒加密、可以塞假紀錄），沒有碰「誰改得動目的地」。

那一條是統籌者依工作單自己補查出來的，**而且它比工具報的兩條都嚴重**。

詳見[檢視方法與工具 → 為什麼不能只看 AI 的結果](GUIDE-01-method-and-tools.html#why-human)。
:::

::: {.callout .ok}
**兩輪掃的程式版本不同，這裡說明一下**

第一輪與第二輪之間，程式改了一次。統籌者比對過兩版之間的那一筆改動，**沒有動到第二輪範圍內的任何一個檔案**，所以結果有效。
:::

---

## 問題一覽

**排序按風險，同風險的同一類排在一起。**「出事會怎樣」那欄講的是**業務影響**——誰受影響、損失什麼，不是技術現象。

| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| **1** | 管理員打開「系統設定 → 日誌轉送設定」，填一台伺服器位址按儲存。**任何一家客戶的管理員都按得下去**——不分總部還是子公司——而這一存改到的是全系統共用的那一份設定 | 🟠 高 | 客戶資料沒隔開 | **全系統只有這一份設定**（包含平台管理員在內）。任何一家客戶的管理員改掉它，**所有客戶的系統活動紀錄都會被持續送到他填的那台機器上**，而且沒有人會察覺 | **已裁定：只給平台管理員改**。「只開放給客戶總部的管理員」擋不住——轉送全系統只有一條，總部管理員一改照樣是全部客戶的日誌送去他那台 | ✅ **已修（CM-2054）** |
| **2** | 管理員在「操作日誌」查詢頁按下「匯出」，拿到 Excel 檔並打開。**攻擊者不必登入就能事先在那個檔案裡種一顆「公式炸彈」** | 🟠 高 | 外部送什麼就收什麼 | **種下去完全不需要帳號**——因為系統在任何權限檢查之前就把每一次請求原封不動記下來了。之後管理員打開那個檔案，攻擊者準備的內容就會在**管理員自己的電腦上**執行：可以是釣魚連結，也可以把整張表的內容送到外部網址 | 在匯出的那一個出口統一處理，把會被 Excel 當成公式的開頭字元**標示成純文字**——**字元一個都不刪，只是告訴 Excel「這是文字、不要執行」**。實際做法：匯出前把開頭是 = + - @ 的字加標記，Excel 讀成純文字 | ✅ **已修（CM-2055）** |
| **6** | 已登入的人只要把網址加長，這次操作就不會出現在操作日誌裡 | 🟡 中 | 外部送什麼就收什麼 | **刪資料、改設定都一樣照做，平台管理員事後查操作日誌會以為沒發生過。** 日誌表的「網址」欄最多 500 字，系統把完整網址直接塞進去，超過就寫入失敗；而寫日誌失敗被設計成「不拖垮使用者的請求」，只印一行錯誤、請求照常執行。另一條管道（系統稽核事件）是分開寫的，不受影響 | 所有有長度上限的欄位（網址 500、IP 255、瀏覽器資訊 5000）寫入前一起截斷；寫入失敗時至少留一筆替代紀錄；順手讓網址上的參數也走密碼遮蔽 | ✅ **已修（FR-114 CM-2171，BE commit `908f9dd0e`）** |
| **4** | 系統把日誌一行一行送到客戶的資安監控系統時，**沒有處理使用者填進來的換行**，有心人可以藉此在對方系統裡塞入偽造的稽核紀錄 | 🟡 中 | 外部送什麼就收什麼 | 只要有一個使用者填得到、又會被原樣記下來的欄位（例如登入時輸入的帳號），攻擊者就能在裡面藏一段假的日誌內容。送到客戶的監控系統之後，**多數解析程式會把它當成一筆獨立的紀錄**——可以捏造「某某管理員授予了超級權限」這種紀錄，混淆事後追查。**這條不需要任何權限，連登入都不用**（登入失敗的帳號也會被記下來） | 組出那一行文字之前，把換行**編碼成看得見的兩個字元**，其他看不見的控制字元同理——**內容一個位元都不少，只是讓它不再被讀成「下一筆」**。實際做法：送出前把換行編成可見的 \n，一筆不會被拆成兩筆，內容不減 | ✅ **已修（CM-2055）** |
| **3** | 管理員在日誌轉送設定頁選「傳送方式」時，**畫面上只有兩個選項，兩個都是明文**——想開加密的客戶開不了 | 🟡 中 | 密碼外流 | 明文轉送是這類功能的業界常態，通常靠「部署在受信任的網段」來保護。**我們的缺口不在於沒有加密，在於沒有提供加密選項**——客戶就算自己的監控系統收得了加密、也想開，設定上根本沒有那個選擇。能在網路路徑上看封包的人（同機房網段、被入侵的網路設備）就能讀到整份日誌 | **提供加密選項，讓需要的客戶開得起來**。對方收不收得了加密，屬於客戶自己的部署決定。實際做法：加獨立的傳輸加密開關（僅 TCP 可開），憑證驗證恆開、自簽憑證改貼信任憑證，syslog 與 GELF 兩條路都支援 | ✅ **已修（CM-2056）** |
| **5** | 兩張日誌表的「按月分開存放」失效，連帶保存期限完全沒有生效 | 🟡 中 | 資料清理不完整 | **依規定該在 90 天／180 天後刪掉的日誌，實際上會無限期留著**——而那段期間的日誌裡還有密碼原文。另外資料持續堆進同一張表，查詢與清理會愈來愈慢 | 把負責每月建新分區、清掉過期舊分區的維護程式接上排程 | ✅ **已修**——維護程式已接上每日 03:30 的排程（2026-09-18），並修正了它先前會因權限不足而每晚失敗的問題；開發環境實查確認：本月與未來兩個月的分區都已建好、備用表已清空歸零 |
| **7** | 操作日誌的「來源 IP」全部記成前端代理伺服器 | ⚪ 低 | 要先做產品決策 | **出事時查不出操作是從哪台電腦來的。** 系統記的是直接連進後端的那一台（前端代理伺服器），不是使用者電腦——STG 22.8 萬筆全是同兩個內部位址。不是攻擊造成、也不外洩東西 | ⚠️ **不能直接改讀「前端代理轉過來的原始 IP」那個欄位**——任何人都能自己帶一個假的，比現在更糟。要讓後端只相信前端代理那一跳；而且系統裡另外兩處讀 IP 的地方（防竄改、登入）現在就直接相信那個欄位，三處一起統一 | ✅ **已修（FR-114 CM-2171，BE commit `908f9dd0e`，套件 jedi-iam commit `960d737e`）** |

---

::: {.callout .plain}
**下面只展開需要你自己判斷、或容易被誤解的幾條。** 其餘的修法明確，看上面表格的「怎麼修」那一欄就夠了——**沒有展開不代表沒查，也不代表不重要。**
:::

## 第 1 條：任何一家客戶的管理員，都改得動全系統共用的日誌去向 {#forwarding-target}

::: {.callout .crit}
**這條要跟「日誌裡有什麼」一起看，才看得出完整的影響。**

單看「可以改一個設定」不嚴重。**但改的是整個系統的活動紀錄要送去哪裡**，而那份紀錄裡曾經有使用者的登入密碼與憑證原文——而且這條路上**沒有加密可以開**（第 3 條），攻擊者連收都不用收，站在網路路徑上看就行。
:::

### 在哪個畫面發生

管理員打開「系統設定 → 日誌轉送設定」這一頁，填上一台伺服器的位址、選好傳送方式，按儲存。**畫面上沒有任何跡象告訴他：這一存改到的不是他自己公司的設定，而是全系統共用的那一份。**

### 問題是什麼

這個轉送功能本身是客戶要求的，**設計沒有問題——落地版裝在客戶自己的機房，日誌要送去哪台伺服器本來就是客戶自己的事。**

問題出在**改得動它的人，層級不對**：

| | |
|---|---|
| **這個權限的層級** | 標記成「客戶層級」——所以每開一個新客戶，**那家底下的管理員角色就自動拿到它**，不分總部還是子公司 |
| **設定表實際的樣子** | **全系統只有一列**（客戶欄位是空的），實查確認就是 1 筆 |
| **寫入的程式** | 把客戶欄位寫死成空值，一律更新那唯一的一列 |

換句話說：**一個客戶層級、而且連子公司都拿得到的權限，改的是一份全系統共用的設定。**

::: {.callout .plain}
**開發環境實查——這是「機制確實會這樣運作」的佐證，不是「已經有客戶暴露」**

開發環境裡建了 9 個測試客戶，其中 8 個的管理員角色實際持有這個權限。**那 9 個全部是我們自己建來測試用的假資料，產品從未出貨，沒有任何真實客戶。**

這份數字要讀的是：**「開一個新客戶，這個權限就自動發下去」這件事確實會發生**，不是推測。
:::

### 這不是單一事件

**同一種形狀的問題在系統設定那一塊也出現過**（客戶底下的管理員可以改掉全公司的登入規則），那一條已經證實成立。**兩條是同一種病。**

### 怎麼修（已裁定：只給平台管理員改）

::: {.callout .decided}
**裁定：這個設定只給平台管理員改**

**為什麼不是「只給客戶總部的管理員改」**：主系統接線那一輪逐檔查過——設定表全系統只有一列、讀的那端永遠讀這一列，而把日誌送出去的那條管道**一個程式裡只有一條**，所有客戶的日誌都走它。所以不管是總部還是子公司的管理員，**只要改得動，改到的就是全部客戶的日誌去向**——限縮成總部，只是能動手的人變少，不是只影響他自己公司。

**怎麼做**（二擇一，都在主系統）：寫入那支改掛「必須是平台管理員」的檢查（同一支檔案裡操作日誌那半已經這樣做）；或把「看／改日誌轉送設定」這兩個權限改標成平台層，再用一支資料庫調整收回已經發給客戶管理員的權限。

**根源**：模組本身把一個全系統共用的設定宣告成「客戶層級的權限」，主系統照單接上。

**修好這條，也同時關掉[證據分類那頁](M07-evidence-classification.html)第 14 條（原廠 AI 金鑰逾時時明文寫進日誌）的主要外洩出口。**

**考慮過但未採用的方向**

| 方案 | 為什麼不採用 |
|---|---|
| **只開放給客戶總部的管理員** | **擋不住**——理由見上 |
| **每家客戶各自設定自己的轉送** | 這是新功能、不是修正，要動資料表結構與轉送管道的設計 |
:::

---

## 第 2、4 條：同一個根——進來時照實記，交出去時沒把關 {#output-encoding}

::: {.callout .crit}
**這兩條建議合成一張工單。**

根是同一個：**使用者填的東西會被原樣記進日誌，不需要任何權限**（系統設計成「先記錄、再檢查權限」，**那個順序是對的、不該改**——稽核紀錄本來就該如實）。

差別只在**引爆的出口不同**：一個是 Excel 把等號當公式執行，一個是客戶的日誌系統把換行當成「下一筆紀錄」。
:::

### 在哪個畫面發生

| | 場景 |
|---|---|
| **第 2 條** | 管理員打開「操作日誌」查詢頁，按下「匯出」拿到一個 Excel 檔，雙擊打開它 |
| **第 4 條** | 系統依設定把日誌一行一行即時送到客戶的資安監控系統，對方收下後解析成一筆一筆紀錄 |

兩邊被引爆的，都是**攻擊者事先填進系統、被原樣記下來的那段文字**。

### 第 2 條：不必登入，就能在管理員電腦上種一顆炸彈 {#formula-bomb}

系統會把**每一次請求**原封不動記下來——包含使用者的瀏覽器識別字串、網址、查詢條件。**而且這件事發生在任何權限檢查之前**（已核對確認）。

於是：攻擊者隨便對系統送一個請求，把瀏覽器識別字串換成一串公式，這串文字就原文進了資料庫。管理員匯出並打開那個檔案時，**那串公式就在管理員自己的電腦上執行了**。

| | |
|---|---|
| **要先有什麼** | 什麼都不用。**連帳號都不需要**，隨便對任一個系統入口送一個請求就行 |
| **會發生什麼** | 管理員打開匯出的檔案時，攻擊者準備的內容在他的電腦上執行——可以是釣魚連結，可以把整張表的內容送到外部網址 |
| **範圍比想的大** | 匯出的 17 個欄位裡，**有 6 個吃得到外部輸入**——不是只有瀏覽器識別字串那一欄 |

::: {.callout .warn}
**嚴重程度要講準：不是「打開就完蛋」**

現代 Excel 打開來路不明的檔案時，通常會**先跳出安全警告**，要使用者按下確認才會啟用內容。

**但這擋不住兩件事**：做出來的釣魚連結**看起來就是一個正常連結**，點了才知道；而管理員匯出的是**自己系統的報表**，心理上信任它，警告很容易直接按掉。

**風險是真的，但讀者不該把它讀成「一打開就中」。**
:::

### 第 4 條：塞一筆偽造的稽核紀錄進客戶的監控系統

送出去的每一筆日誌是**一行文字**。使用者填的內容如果裡面有換行，送到對方系統之後就被讀成**兩行、也就是兩筆紀錄**——第二筆完全由攻擊者決定內容，可以是「某某管理員授予了超級權限」。

**連登入都不需要**：登入失敗時輸入的帳號一樣會被記下來。

核對時另外發現：目前那段負責清理的程式**只處理了訊息的第一段，完整內容那一欄仍是原樣帶出**——修的時候兩處要一起改。

### 怎麼修：是編碼，不是刪除

::: {.callout .decided}
**被竄改的是現況，不是修法。**

攻擊者填的是**一個值**，現在的系統卻讓收件方讀成**兩筆紀錄**——**這本身就是紀錄失真。** 編碼是把它**修正回忠實呈現**，不是抹掉證據。

日誌有不可竄改的規範，我們自己又是稽核產品——**所以資訊一個位元都不能少**。
:::

| | 做什麼 | 修完之後 |
|---|---|---|
| **第 4 條**（轉送） | 把換行**編碼成看得見的兩個字元**，其他看不見的控制字元同理 | 收件方看到的是**攻擊者填了什麼一清二楚的完整內容**，而且它仍然是**一筆紀錄的一個欄位**，不會被解析成兩筆 |
| **第 2 條**（匯出） | 把會被當成公式的開頭字元**標示成純文字** | Excel 打開來看到的還是完整字串，**只是不執行** |

**修法都在出口，入口不能修**：

- 欄位太多，逐一過濾一定漏——匯出的 17 個欄位就有 6 個吃得到外部輸入。
- 會擋掉正常輸入——有人在備註裡真的想寫等號開頭的文字。
- **最重要的是：記錄本來就該如實。**

**一句話原則**：

> **進來的照實記，交出去的時候才負責讓它安全。**

修的時候要**順便盤點還有沒有第三個出口**——螢幕顯示、匯出成其他格式、送給別的系統。**只要是「把記錄交出去」的地方，都該問一次同樣的問題。**

---

## 第 3 條：不是我們沒加密，是我們沒給客戶選擇 {#no-encryption}

### 在哪個畫面發生

管理員在日誌轉送設定頁選擇「傳送方式」時，**下拉選單裡只有兩個選項，兩個都是明文**。

實查確認：轉送只支援**兩種常見的日誌格式**、每種**兩種傳送方式**，**四種組合全部沒有加密**；傳送方式只認那兩個值，填別的會直接被擋掉。

### 評級理由

**明文轉送是這類功能的業界常態**，多數同型產品預設也是明文，靠「部署在受信任的網段」來保護；而且加不加密還要看**對方的監控系統收不收**。

**所以缺口不在「我們沒加密」，在「我們沒給客戶選擇」**——客戶就算自己的監控系統收得了加密、也想開，設定上根本沒有那個選項。

**修法**：提供加密選項，讓需要的客戶開得起來。**對方收不收得了加密，屬於客戶自己的部署決定**，我們只負責把選擇權給出去。

::: {.callout .warn}
**這一輪沒有查的一件事，會決定這條的最終評級**

日誌裡曾經有使用者的登入密碼與憑證原文，**已經補上遮蔽**。但**這一輪沒有查證那道遮蔽涵蓋得完不完整**。

- **若遮蔽完整** → 明文轉送的風險就與業界常態相當，維持中等。
- **若還有漏網的敏感欄位** → 明文轉送就是實質問題，要再往上調。

**這條的最終評級取決於此。**
:::

---

## 第 5 條已經修好了——但修好的原因值得一提 {#partition-fixed}

::: {.callout .ok}
**這條在檢視報告寫成之後被修好了，我們重新查證確認過。**
:::

### 原本的狀況

兩張日誌表設計上是**按月分開存放**的，另外寫了一支維護程式，負責「每月建新月份、清掉過期的舊月份」（操作記錄留 90 天、系統日誌留 180 天）。

**但那支維護程式從來沒有被任何排程呼叫過。** 檢視當時開發環境實查：兩張表只有 5 月到 8 月四個月份，9 月份根本不存在，資料全部堆進了備用表——操作記錄 2 萬多筆、系統日誌 8 萬多筆。

**最麻煩的是它沒有任何症狀**：資料照常寫入、查詢照常有結果，不會有任何錯誤訊息。自動檢視因此判成「還沒發作、10 月才會開始」，統籌者連開發環境實查才看清楚——**它早就已經在發作了**。

### 現在的狀況

| 檢查項目 | 結果 |
|---|---|
| 維護程式有沒有接上排程 | ✅ 有，每日 03:30 執行 |
| 分區有沒有補上 | ✅ 本月與未來兩個月都已建好 |
| 備用表清空了嗎 | ✅ 兩張都是 0 筆 |

修的過程中還發現一件事：**那支維護程式即使接上排程也會每晚失敗**——它要做的是建表與刪表，但當初設定成「用呼叫者的身分執行」，而應用程式的連線帳號沒有建表權限。這一點一併修好了，而且是隨出貨走的，**日後裝出去的機器會直接拿到正確版本**。

---

## 已裁定：日誌表的定位是「原廠維運用的全系統資料」 {#log-positioning}

::: {.callout .decided}
**決策者 2026-09-26 裁定：系統日誌與 API 連線日誌只給原廠維運看，定位為全系統資料，不做客戶之間的隔離。**

| | |
|---|---|
| **誰看得到** | 畫面上只有平台管理員（原廠）看得到這兩份日誌，客戶的管理員進不去 |
| **為什麼不隔離** | 這兩份日誌是給原廠排查整台系統用的，本來就要看全貌；按客戶切開反而查不出跨客戶的問題 |
| **要守住的前提** | 「只有平台管理員看得到」這道門必須一直在。哪天要讓客戶自己看日誌，要先回頭做隔離 |

這是產品定位的決定，不是遺漏；程式不必為此改動。
:::

---

## 這塊的結論

::: {.callout .warn}
**一句話**：這塊的內容物本身就是最敏感的那一份——**日誌裡曾經有登入密碼與憑證原文**（已補上遮蔽）。七條裡有一條已經修好，**其餘六條分成四種性質完全不同的問題，不該混在一起講**。

**六條未修的分法**

| 性質 | 哪幾條 | 怎麼處理 |
|---|---|---|
| **權限層級錯置** | 第 1 條 | 已裁定**只給平台管理員改**（「只給客戶總部」經查證擋不住） |
| **紀錄本身記不完整** | 第 6、7 條 | 第 6 條（網址太長就漏記）與第 7 條（IP 記成代理伺服器）是主系統接線那一輪查出來的，都是「事後查不到」的問題，建議同一張卡 |
| **交出去時沒把關** | 第 2、4 條 | **合併成一張工單**，修法都在出口、**都是編碼而不是刪除** |
| **設定上少了一個選項** | 第 3 條 | **提供加密選項即可**，對方收不收得了屬客戶自己的部署決定 |

**建議的處理順序**

1. **第 2、4 條**——改動小、只在出口、不影響任何現有行為，**可以先做**。
2. **第 1 條**——只給平台管理員改，修法小；修好同時關掉證據分類那頁第 14 條的外洩出口。
3. **第 6、7 條**——同一張卡，讓操作日誌記得完整、記得對。
4. **第 3 條**——提供選項，優先度看「日誌遮蔽補得完不完整」的查證結果。

**另外要提醒**：第 5 條雖然已經修好，但它揭露的模式值得記住——**一個保存期限完全沒生效的缺陷，可以無症狀地持續數個月**，因為資料照樣寫得進去、查詢照樣有結果。
:::

::: {.callout .plain}
**可信度要老實講**

模組本體兩輪、82 個檔案，另加主系統接線一輪 5 個檔。**但工作單上標為「本輪最重要」的那個疑點，自動檢視完全沒有碰**——自動檢視報的兩條都是「送出去的資料本身」的問題，**沒有碰「誰改得動目的地」**。

**第 1 條（最嚴重的那條）是統籌者依工作單自己補查出來的。** 主系統接線那一輪同樣是自動檢視零發現、三條全靠執行者開檔實測追出。
:::

| 統計 | |
|---|---|
| 檢視輪數 | 3 輪（模組本體 2 輪 82 個檔案＋主系統接線 1 輪 5 個檔） |
| 找到的問題 | 7 條 |
| 高風險 | 2 條 |
| 已修 | 3 條（第 5、6、7 條） |
| 未修 | 4 條（第 1、2、3、4 條） |
| 已開工單 | 0 張（依決策者裁定，全部掃完後統一開） |

**還沒查的**：

- 主系統接線那一端已在 2026-09-23 補查（第 6、7 條與第 1 條改裁都出自那一輪）。
- **日誌遮蔽涵蓋得完不完整，這一輪沒有查證**——它會決定第 3 條的最終評級（見該條說明）。

---

| 你想知道 | 看哪裡 |
|---|---|
| 我們用什麼方法查、結果有多可信 | [檢視方法與工具](GUIDE-01-method-and-tools.html) |
| 其他模組的檢視結果 | [回總報告首頁](index.html) |