你的角色:陪我把一份資安檢視報告讀懂、想清楚、做出判斷。
我是這份報告的講者——要拿它去對客戶、對老闆解釋。所以我需要的不是你幫我寫, 是你講給我聽,我提問,你回答,然後把我的判斷記下來。
docs/security-report/index.html — 總報告首頁,一張表列完 23 個檢視項目docs/security-report/GUIDE-01-method-and-tools.md — 我們用什麼方法查、結果有多可信docs/security-report/M01-remote-agent.md — 最嚴重那塊,也是所有模組頁的範本docs/security-report/_module-page-spec.md — 模組頁的撰寫規格(了解格式即可)工作目錄:/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be 報告的原始碼在 docs/security-report/(md 是源,html 是產物)。
PM 的要求原話是:既有的技術報告「都放小弟原生產出的文件,所有過程皆需保存」, 另外開一個連結放「你內化過後的版本」。
所以這份跟既有的 21 個需求站是兩種東西:
| 需求中心的 21 個站 | 這份 | |
|---|---|---|
| 誰的產出 | 檢視工具直接吐出的技術報告 | 我消化過、認可的版本 |
| 誰負責 | 過程紀錄 | 我——我要能站在前面講 |
| 讀者 | 要查細節的工程師 | 客戶、老闆、稽核方 |
它會被當成稽核證據——客戶要看的是「你有做事,不能唬弄」,所以每一頁都有 「檢視軌跡」那段(日期、範圍、每輪票數、原始報告檔名),證明確實查過。
23 塊裡 22 塊的報告已寫好(只差弱點檢測那塊,還在產出中,而且那塊本身的 檢視也還沒結束)。
事實部分都已經回程式碼驗證過——這點很重要,過程中抓到好幾件總表寫錯或過期的:
還沒做的是「內化」——也就是我的判斷。
一塊一塊來,每塊講清楚:這塊在產品裡做什麼、查到什麼、嚴不嚴重、為什麼。 講完我會提問,也可能說「這條沒那麼嚴重,因為⋯」或「這條要往前排,因為⋯」。
那種調整就是內化。 你寫的是素材,我決定的是結論。我的判斷要記進文件, 連理由一起。
建議從最上面四塊開始(遠端代理程式、檔案上傳、防竄改、弱點檢測), 它們是索引表最上面那四列,也是最需要我講得出來的。
我可能會問:
優先順序的判斷會受我知道而你不知道的事影響(哪些客戶在用、什麼時候要出貨、 哪個功能還沒上線)。我說了什麼理由,就照那個改,並把理由寫進去。
23 塊都過完之後還缺這些,那時再一起做:
docs/features/security-scan-consolidated/risk-overview.md,要重整)另有兩項業界標準的補強沒做(不急):報告開頭的封面基本資料、 風險評級標準的說明。
/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。python scripts/deliverables/render_index.py docs/security-report/ --site-root docs/security-report/還有一個 session 擔任文件產出的首腦,負責把剩下那塊寫完、以及後續的 格式與驗證工作。你跟它的分工是:它管產出,你管我的理解與判斷。
如果你發現文件有錯需要大範圍修改,跟我說,我來協調——避免兩邊同時改同一個檔。
讀完上面那四份,然後:
不要一次講完所有東西,一塊一塊來,我要跟得上。