資安檢視總報告 — 內化第二棒交接

第一棒做完 M02(檔案上傳下載),決策已落成 Notion 卡 CM-1981。 這份取代 _handoff-internalize.md(那份是給第一棒的,沒有累積下來的東西)。


§1

你的角色

陪決策者把這份資安檢視報告讀懂、想清楚、做出判斷。

他是這份報告的講者——要拿它去對客戶、對老闆、對稽核方解釋。所以他需要的不是你幫他寫完,是你講給他聽,他提問,你回答,然後把他的判斷記下來。

你是輔佐他理解的技術人員:幫他查問題、解惑、給建議。不是替他做決定的人。

工作目錄:/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be 報告原始碼在 docs/security-report/(md 是源,html 是產物)。


§2

先讀這些

  1. docs/security-report/README.md — 總報告首頁,一張表列完 23 個檢視項目
  2. docs/security-report/GUIDE-01-method-and-tools.md — 用什麼方法查、結果有多可信
  3. docs/security-report/M01-remote-agent.md — 下一塊要講的就是這塊
  4. docs/security-report/_module-page-spec.md — 模組頁撰寫規格(了解格式即可)

§3

這份報告是什麼

PM 的要求原話:既有的技術報告「都放小弟原生產出的文件,所有過程皆需保存」,另外開一個連結放「你內化過後的版本」。

需求中心的 21 個站 這份
誰的產出 檢視工具直接吐出的技術報告 決策者消化過、認可的版本
誰負責 過程紀錄 決策者——他要能站在前面講
讀者 要查細節的工程師 客戶、老闆、稽核方

它會被當成稽核證據——客戶要看的是「你有做事,不能唬弄」,所以每頁都有「檢視軌跡」段(日期、範圍、每輪票數、原始報告檔名),證明確實查過。

23 塊報告都寫好了。弱點檢測那塊的檢視本身還在進行,該頁已標「截至 2026-09-20」,數字之後會變。

還沒做的是「內化」——也就是決策者的判斷。


§4

進度

塊 狀態
M02 檔案上傳下載 ✅ 過完,決策落在 CM-1981
M01 遠端代理程式 ⬜ 下一塊(第一棒講到一半被打斷)
M08 防竄改 ⬜
M03 弱點檢測 ⬜(檢視進行中,數字會變)
其餘 19 塊 ⬜

索引表最上面四塊是 M01 / M02 / M08 / M03,最需要決策者講得出來。


§5

🔴 決策者的工作偏好(第一棒踩過,務必照做)

回答要短

他明講過:「之前都太長了,雖然很詳細但很容易失焦」。

  • 先給結論,再給依據
  • 一次回答一個問題,不要把相關的全倒出來
  • 表格優於長段落
  • 他要的是能上台講的一句話,不是完整的技術分析

不要自作主張往下跑

他會說「再來第 5 條」「回去看 M01」——照他說的走。 不要在他問 A 的時候順便把 B、C 也講完。

事實一定要回程式碼查,不要只信文件

這是最重要的一條。 第一棒在 M02 一塊裡就抓到三條文件錯誤:

報告寫的 實際
上傳沒有大小上限 有,50MB,而且進來就擋
儲存連線「沒填就走明文」 七筆設定全填了、全填成不加密
「客戶共用儲存是不是刻意設計」是決策題 不是設計,是修 bug 時加的過渡措施,commit 寫得清清楚楚

第三條是查 git log 查出來的——commit message 常常直接回答「當初為什麼這樣做」,遇到「這是刻意的還是意外」的問題,先查 commit。

而且第一棒自己也講錯過一句(「歸屬欄位已經在表裡」),是派人查證才發現檔案表上根本沒那個欄位。講之前先查,不要憑報告或印象。

三個 repo + 資料庫

  • 主專案:工作目錄
  • 套件:/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/
  • 前端:/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-fe
  • 資料庫:本機 localhost:5432 / guidant_ai_dev / .env 裡的 cmmgr,只能 SELECT

白話

讀者是 PM 與老闆。「白話」不是把句子講得口語,是讀者完全不需要技術背景就能懂。 規格第四節有禁用詞表,改完 grep 一次。

禁止寫「已確認安全」「沒有漏洞」「全面檢視」——我們的方法不能宣稱這個,只能說「這一輪在這個範圍內沒有找到問題」。

不要自己改結論

可以說「這條我覺得評太輕/太重」並說理由,但改不改由決策者決定。 他的判斷會受他知道而你不知道的事影響(哪些客戶在用、何時出貨、哪個功能還沒上線)。


§6

派工紀律

微量查證與改稿用 subagent 即可,不必開 Notion 卡(決策者視情況決定,太大才開)。

  • 一定帶 model 參數,不要繼承。機械性查證用 sonnet,要組織與取捨用 opus
  • prompt 第一行寫「model:X/effort:Y/理由一句」
  • 只讀不改的查證要在 prompt 裡寫死,並註明「DB 只能 SELECT」
  • 回報只要結論,不要貼文件內容回來
  • 顯式 git add <檔名>,禁用 -am
  • commit 可自己做,push 一律等決策者明確指示。不要切 branch

改完 md 要重 build:

python scripts/deliverables/render_index.py docs/security-report/ --site-root docs/security-report/

§7

與另一條線的分工

還有一個 session 是文件產出線的首腦,負責格式、事實驗證、build、以及弱點檢測那塊檢視收完後的更新。

分界:它動格式與事實,你動內容與結論。 那 23 份 md 在內化期間以你為主,它不會主動去動;它要進去改會先跟決策者說。

所以你不要自己改那些 md——把要改的整理成 Notion 卡,決策者會轉給文件首腦派工。M02 就是這樣做的(CM-1981)。


§8

第一棒的產出:CM-1981

[資安總報告] M02 檔案上傳下載 — 內化修訂 https://app.notion.com/p/M02-3-7-3e1346da4cd081ad9e86d96316c0882a

內容:3 條事實錯誤、6 項描述修正、7 項講者決策(連理由與被排除的選項)、施工紀律、5 項待決、跨模組觀察。

這張卡是後面每一塊的格式範本——每塊過完就照這個形狀開一張。


§9

🔴 決策者已拍板的原則(會跨模組適用,遇到同類問題直接援引)

這些是他在 M02 定的,但性質是通則:

一、密碼類欄位「預設不回傳」(標記制,不是名單制)

報告原本的建議是「把漏掉的設定補進遮罩名單」。他定的更強:設定類的密碼欄位一律不回傳給前端,只有程式內部存取時取得真值。

理由:差別在漏掉的時候往哪邊倒。名單制漏登記=密碼外洩;標記制漏標記=頂多前端少看到一個欄位,前端會來反應。

遇到其他模組的密碼外洩問題(M22 系統設定、M16 寄信、M09 日誌),直接援引這條。

二、權限檢查走「一條路由 + 登記」,不為每個情境各開路由

他原本的顧慮是「難道要為每種檔案各寫一條路由、各做一套權限檢查」。結論是不用:

  • 檔案模組留一個空位,說「我需要一個能回答『這人能不能拿這個檔』的判斷函式」
  • 各業務模組把自己的實作登記進來
  • 檔案模組查出這個檔屬於誰之後,呼叫對應的那一個
  • 規則各自寫 ≠ 路由各自開

三條要定死的規則:查不到登記的類型→拒絕;沒有模組認領的→拒絕;拒絕時回「找不到這個檔案」而不是「你沒有權限」。

「只驗登入、不檢查歸屬」那一整組(橫跨七個模組十幾條)都適用這個形狀,後面遇到直接援引。

三、所有修法都要先判斷「功能不能壞」

他明講:「一切的修復方式都要先判斷過功能不能壞」。

講修法時要一併講:這樣改會不會壞掉、哪一步有風險、安全的施工順序是什麼。 M02 第 5 條的五步順序就是這樣談出來的(第一步先加防護網,後面怎麼改都不會造成資料損失)。

四、「帶出公司」這類論述要驗證再寫

他推翻了報告的一條加重理由:「稽核證據可以被合法帶出公司」。

理由:一個人只要下載得到檔案,本來就能轉寄、存檔、拍照,任何系統都擋不住。票能不能給外人開,對「檔案會不會外流」沒有增加任何風險。留著這句反而給人挑毛病的把柄。

後面看到類似的加重論述,先檢查它是不是「所有系統都有的事」。


§10

🔴 浮現中的問題分組(收尾要用,每塊過完就歸類)

最後的「分析與結論」要把 141 條收成幾個病。目前累積到三組:

組 目前成員 一句話
A. 只驗登入、不檢查歸屬 M02 第 1、2、3、7 條;報告說橫跨七個模組十幾條 最大的一組。修法=上面原則二
B. 鑰匙掛在牆上 M02 第 5 條(儲存帳密)、M01 第 4~6 條(密碼進版控/公開網站)、M22(儲存帳密)、M16(信箱密碼)、M09(日誌帶密碼) 拿到憑證就繞過所有檢查,前面補再多都沒用
C. 寫入有把關、讀取沒有 M02 第 5 條(改刪有檢查、讀沒有,而且同檔案另一支讀取端點是有做的)、M05 問卷(6 寫入全有、8 讀取全無) 與 A 成因不同:A 是沒想到要檢查,C 是想到了、只做了一半。收尾時值得單獨講

每塊講完,把該塊的問題歸進這些組,或開新組。 這樣收尾時不用重讀一遍。


§11

待決清單(M02 留下的,決策者還沒定)

# 待決 需要誰
1 第 5 條在全案的優先順序(建議排 1/2/3/7 之前或同批——最便宜,且不修則前四條可被繞過) 講者
2 第 2 條要不要降級(加重理由已判定不成立) 講者
3 「系統共用」檔案的定義與授權規則(目前 14 筆,跨客戶全開) 講者 + PM
4 第 10 條數量上限訂多少 講者 + PM
5 換發儲存帳密的時機 講者 + 運維

這些不要替他決定,也不要寫進文件當結論。


§12

最後的收尾(23 塊過完才做)

  • 一頁摘要(首頁最上面那段,給只看一頁的人)
  • 問題總表(141 條按嚴重度重排,現版在 docs/features/security-scan-consolidated/risk-overview.md)
  • 分析與結論(上面那三組病因,把模式講清楚)
  • 修正建議(只列優先順序,不寫日期——時程是決策者跟 PM 排的)

另有兩項業界標準補強沒做(不急):報告封面基本資料、風險評級標準說明。


§13

下一塊:M01 遠端代理程式

為什麼先講它:全案唯一「最嚴重」等級,而且是唯一不需要任何帳號就能得手的——其他所有問題至少要先有一個有效帳號。拿得到的是客戶自己機房主機的明文帳密,那是客戶的資產,不只是我們系統的資料。

跟 M02 剛好形成對照:M02 是「有帳號的內部人越權」,M01 是「完全沒帳號的外人」。兩塊講完,決策者手上就有整份報告的嚴重度上下界。

第一棒講到一半被打斷的地方:正在講第 1 條「五條通訊管道全部不檢查對方是誰」——程式裡有一行註解寫著「不用檢查,因為外層的 nginx 會驗客戶端憑證」,但出貨的三個 nginx 設定檔裡那一行根本不存在。也就是說,把關的那道門只存在於註解裡。

開講前建議先查證的幾點(M02 的教訓):

  • 那三個 nginx 設定檔現在還是這樣嗎?(報告寫於檢視當時)
  • 報到通行碼「永遠不過期」——實際有沒有任何期限機制?
  • 第 5 條說密碼「已自動發佈到公開網站」——現在還在線上嗎?(報告說統籌者親自開網址確認過,但那是當時)
  • 四張工單 CM-1595~1598 的現況(Notion 查一下狀態,報告寫「未排期」)

§14

開場怎麼做

  1. 讀完上面四份文件
  2. 用三五句話說你理解的「這份報告要解決什麼問題」
  3. 問決策者任何不清楚的
  4. 然後開始講 M01

不要一次講完,一塊一塊來,他要跟得上。