上一篇完成 SCC 調查 Skill。這次我們來看實際報告，關注讀者看不看得懂、證據和推論有沒有分開、查不到資料時 AI 會不會自己補結論。

測試情境

這次用 Terraform 建立隔離的 GKE Autopilot 測試環境，觸發一筆 SCC THREAT finding，類別是 Execution: Container Escape。

測試環境使用 private 節點、private 的 control plane 和沒有 public IP 的 bastion。測試人員透過 IAP 連進 bastion，再從 VPC 內執行一次性 Pod。

Pod 執行以下指令：

cp /bin/ls /tmp/botb-linux-amd64
/tmp/botb-linux-amd64 -autopwn

這兩行只模擬 Container Threat Detection 要觀察的 process 名稱與參數。執行後會發出的 finding 是：

• Source：Container Threat Detection
• Category：Execution: Container Escape
• Finding class：THREAT

檢視報告

Agent 收到 finding 後，依照 Skill 呼叫調查工具，產出以下報告(內容已做去識別化)。

摘要

摘要列出 finding 類別、severity、state、GKE cluster、用來設定查詢範圍的事件時間和實際執行的 process，也寫出 cluster 目前仍是 RUNNING。建立 cluster、bastion 等資源的帳號、現有 IAM 授權和目前無法確認是否可用的日誌資料也都放在這裡。

這段有寫出重點，可以先知道發生什麼事。不過摘要塞了工具 function 名稱和參數，沒有做到一眼看懂。

事件時間線

時間線從 service account 和 IAM 授權建立開始，接著是建立 cluster、bastion 和查詢 subnet 等 GCP 操作紀錄，最後放入 SCC finding 的 Cloud Logging timestamp、event_time 和 create_time。

AI 把 Terraform 建置、IAM 異動和 finding 放在同一條時間線，每一列也標出資料來源。不過「actor raw 事件」、「IAM 異動 raw 事件」和「cluster 資源 raw 事件」都是工具內部用語，讀者看不出這些是什麼意思。iam.serviceAccounts.actAs 也沒有用白話說明這項權限檢查在確認什麼。時間順序雖然整理出來了，報告卻沒有把工具輸出翻成人話，讀起來還是很吃力。

影響與範圍

這一段說明查了哪段時間、找到幾筆資料，也確認在這次查詢條件下已經讀到最後一頁，沒有尚未取得的結果。接著分成「已觀察到」與「目前無法確認」兩組。可以確認 cluster 仍在執行、兩個 service account 目前仍有直接專案授權；實際執行容器內 process 的身分、角色是否涵蓋該操作，以及網路和資料存取紀錄仍無法確認。

這章節是寫得相對較好的一段。VPC Flow Logs 和 Data Access Audit Logs 的前置檢查無法確認資料是否可用，AI 沒有直接寫成沒有網路活動或資料存取；報告也把 finding 前已存在的 IAM 授權，和 finding 發生時實際使用的身分分開處理，沒有把「擁有授權」當成「實際使用授權」的證據。已知和未知分得清楚，讀者可以直接看出目前能確認到哪裡。

調查結果

調查結果分別整理 finding 證據、用來設定查詢範圍的事件時間、cluster 現況、GCP 操作紀錄、IAM 時序和資料來源可用性。AI 找到 Pod、PID 1、process 路徑與參數，也確認 cluster 仍為 RUNNING，IAM 授權異動則發生在 finding 前約 18 分鐘。

這段還可以，有按照資料類型整理，不會把所有查詢結果混在一起。不過工具名稱和參數還是很多，讀者得自己把這些資料翻成事件經過。

待確認事項

待確認事項列出實際執行容器內 process 的身分、Pod 使用的 Google 身分、Pod 操作紀錄、VPC Flow Logs、Data Access Audit Logs、角色涵蓋性和檔案現況。每一項都能對應到前面提到的資料不足。

這段有明確寫到後續要查什麼，內容算好。若能再標出優先順序會更實用，例如先確認 Pod 使用的 Google 身分和操作紀錄，再補網路與資料存取紀錄。

附錄

附錄保留每個工具的主要輸入、找到幾筆資料、是否發生錯誤，以及查詢有沒有讀到最後一頁。後續調查者可以確認實際查過的範圍，也能知道是否還有結果尚未取得。

這些技術細節放在附錄合理。主要內容負責讓人看懂事件，附錄負責留下核對依據，報告仍需要有重新檢查與重跑的線索。

結論

我覺得這份報告還是出現了 AI 寫內容時常見的通病：AI 不講人話。

有透過工具查到 finding、cluster 狀態、IAM 異動和 GCP 操作紀錄，也知道哪些資料不能直接下結論。技術的判斷沒有太大問題，寫成報告後卻塞滿 control plane、actor raw 事件、scope、binding 和工具函式名稱。讀者就算先理解工具內部設計，也不一定能看得懂。

調查報告的用途，是讓收到告警的人快速掌握事件。主要內容應該直接寫誰做了什麼、查到什麼、目前還缺什麼；工具名稱、欄位路徑和完整查詢紀錄留在附錄，但 AI 在章節內卻混著說明。連我這個設計工具的人都需要停下來翻譯，代表這份報告的文字還需要加強。

關於「不講人話」的問題，我想透過提示詞改善，但目前還沒想到要怎麼描述，才能讓 AI 穩定輸出白話文。之後我還會持續找方法調整，如果大家有什麼好方法，歡迎交流。

今天就寫到這，我們明天見。