↑ 需求首頁 ⌂ 需求中心

FR-128 LOG（append-only）

每棒追加一個 block，寫完永不改。發現舊 block 有誤，在新 block 的「推翻了什麼」更正。

§1

第 1 棒 — 2026-10-05 — 首腦（分析決策＋驗收）

commits: BE ac642cfbd／d951ddd5a／37bad2606／fb0fd4e55／87e5888e9／a8957a466／bb8e3097c／81ba15474／06780d004；FE 582ae6ce；jedi 2518d23a／8f93a49c／f0e6398a；agent ce190e9／d2183c4／ba9c5a6／628ccf7。全部已 push。 Notion: 母卡 CM-2479 與子卡 CM-2480／2481／2482／2483／2484／2500／2501／2502／2505 全建好；.1～.8 首腦驗收通過（仍停在「修正待驗證」，未改 Done）；.9（CM-2505）runner 已回寫但首腦未驗收。 做了什麼:

  • 起點是 PM 問「SBOM 跟弱點比對結果如何」。查出 CI 的 osv-scanner＋pip-audit 本來就在跑（scripts/build/sbom.sh、audit_deps.sh），報告只在 188 .build/sbom/ 與 pipeline artifacts，沒整理成人看的頁。
  • 在 188 裝 Trivy 0.75、Grype 0.120，重掃四顆 v1.24.3 出貨 image，與 osv 結果並排，找出六個 Critical 的根因，開 FR-128 一母九子分棒修完。
  • 結果：be／fe／init 雙工具 0 Critical；classifier 換 Ubuntu 22.04 底後雙工具 0 Critical；白名單從 19 條降到 7 條。 決策:
  • OS 層掃描改 Trivy＋Grype，不再用 osv-scanner。理由：osv 對 Debian／Ubuntu 判定不準（be 的 curl 7.81 一條都掃不出、classifier 的 curl 誤報 8 個 Critical），且完全看不到 CINC Auditor 內嵌的 443 個 gem（apt 不知道它存在）。被排除的：只換掉工具讓數字變漂亮——決策者明確否決，「客戶一定自己也會掃一次，我們要治根」。
  • classifier 換 Ubuntu 22.04，不拆 LibreOffice 成獨立容器。理由：拆出去的容器仍在交付包內、客戶一樣掃得到 Critical，只是換地方；而 be 已證明 Ubuntu 22.04 底能雙 0。被排除的：現成 LibreOffice image（gotenberg 91 Critical、linuxserver 18 Critical，比自建差）、Alpine／Wolfi（LibreOffice 難裝）、拿掉 LibreOffice（會失去分類器看版面截圖的能力）。
  • 「單純換 digest 清不掉可修漏洞」→ 加 apt-get upgrade／apk upgrade。理由：預掃發現基底 image 本身落後自己的套件源；postgres:16-alpine 上游沒出新版，且 17／18／bookworm 一樣有那條 Go stdlib Critical（bookworm 還有 16 條），所以不換 DB 版本，改在 init 的 Dockerfile 刪掉用不到的 gosu。
  • Agent 一起升 CINC 7.2.1（推翻 runner 的建議「agent 留 7.1.7」）。理由：決策者要求兩邊用同一個檔；runner 實測 7.1.7 與 7.2.1 解析結果逐條一致，證明風險低。
  • gate 兩個工具任一報白名單外的 Critical 就擋；Trivy 與 Grype 數字並列不合併（Grype 用 NVD 原始分、Trivy 優先用發行版判定，同一 CVE 嚴重度常不同）。 教訓:
  • osv 的「可修」欄把其他發行版的版號（Ubuntu 24.04、Debian unstable、ESM）也算進去，239 條「可修」是灌水，真實是 79。
  • be-image 的 curl 7.81 被 osv 判 0 條漏洞不是「舊版沒漏洞」，是 osv 對 Ubuntu 22.04 資料有缺口。我當場給了錯誤解釋（「舊的沒被研究所以安全」），被決策者質疑才去驗證推翻——結論要用原始資料驗過再講。
  • omnibus 套件（CINC）自帶的 Ruby／gem 是 apt／dpkg 看不到的盲區，只有 Trivy 直接讀 gemspec 才掃得到。
  • 驗收時 runner 回報的「掃描數字」要自己重掃一次，不信自報；runner 在決策者本機跑、本機沒有 188 的 Nexus 帳密，卡上寫「查 ~/.netrc」會被誤解成本機。
  • 派工 prompt 寫的座標與假設常需要 subagent 開檔核對才準（.9 開卡時抓到三處我寫錯：vuln_gate.py 寫死四顆、關卡放不到簽章前、報告檔名多 -image）。 推翻了什麼:
  • 我先說「be-image 比 classifier 乾淨是因為 Ubuntu 22.04 套件夠舊，新 CVE 打不到」——錯，實查是 osv 對 Ubuntu 22.04 判定有缺口。
  • 我先說 8 個 curl Critical 是真的——Trivy 依 Debian security tracker 判定 trixie 這版不受影響，osv 把上游版號與 Debian 版號混判。
  • 我先預期「LibreOffice 是 Critical 來源」——實查 be 的 2 個 Critical 來自 CINC 內嵌 Ruby gem，與 LibreOffice 無關。
  • subagent（.2）建議「agent 留 7.1.7」——決策者裁示推翻。 留給下一棒: 驗收 CM-2505（.9），然後 B 級清理與進版。DEV 測試資料（CM-2501 那棒留的 agent／派工單／token／工具設定）首腦已清；188 磁碟已從 97% 降到 83%。
§2

第 2 棒 — 2026-10-05 深夜 — 首腦（驗收、出包、收案）

commits: 本棒無程式 commit；1.25.0 進版 60a5f824c、release note SBOM 回填 abac9c4da（另一條線做，FR-128 數字併入）；收案文件 commit 見本 block 所在 commit。 Notion: CM-2505（.9）驗收通過；九張子卡 CM-2480／2481／2482／2483／2484／2500／2501／2502／2505 全部改 Done；母卡 CM-2479「特殊處理登記表」§四改成 8 條、§五標已處理，卡尾 append「收案」段，狀態 Done。 做了什麼:

  • 驗收 .9（Agent 接進弱點關卡，krb5 先白名單）通過，卡改 Done。
  • B 級清理：188 的 *-fr128 temp image 與 BE／Agent 兩個 .build/fr128-verify/ 已清。
  • 1.25.0 由 pipeline #2913839025 出包，Trivy＋Grype 關卡第一次真跑即放行：四顆合計 Trivy Critical 0／High 8／Medium 154／Low 71／可修 7；Grype Critical 0／High 13／Medium 774／Low 113；pip-audit 後端 263、沙箱 35 套件 0 漏洞；白名單 8 條、本輪 0 條被用到。對照 1.24.3 Trivy 修前 Critical 6、CI osv-scanner Critical 12。
  • 190 e2e 已升 1.25.0。Agent 1.4.0 image 尚未 build。
  • 收尾文件：docs/security-reports/2026-10-04/README.md 改成 Trivy＋Grype 最終數字（本機留存，不入版控；桌面那份 HTML 是當初手工轉出，無重產機制，未重產）；analysis docs/analysis/2026-10-05-fr128-osv-to-trivy-grype-and-classifier-rebase.md；memory 兩支。 決策:
  • 收案，High 以下與 Ubuntu 22.04 底層弱點轉 FR-131。決策者看完數字原話「我以為會連帶一起修，折騰一整天只處理最嚴重的」。新目標「四顆 image 弱點總數壓到個位數」，主路線 Ubuntu 24.04、副路線 distroless／Chainguard 評估。
  • 剩餘弱點根源已分清：Ubuntu 22.04 系統套件 53 條（be／classifier 共用，官方無修正版）、deadsnakes python3.11 30 條 CVE（classifier，4 子套件各報一次＝120 條）、pip 自帶 6 條可修、be Ruby json 1 條可修（Low）。這些 FR-128 的手段（換 digest、upgrade、拆編譯工具）都動不到，只能換基底。
  • 手測三項（InSpec profile 上傳／docx 分類／Agent 1.4.0 中文 TWGCB）改列 1.25.0 驗收，不擋收案。 教訓:
  • 開案目標沒對齊決策者原意。開案時寫「零 Critical」是照客戶字面要求；但決策者早上就說了「要治根——客戶一定自己也會掃」，意思是客戶掃出來的東西全部要少，不只最嚴重那級。首腦沒把這句翻成目標改寫，也沒回頭問「目標數字是多少」，結果做完一整天才發現範圍不對。開案時要拿決策者原話逐句對目標，目標數字要問清楚。 推翻了什麼:
  • 第 1 棒 STATE §8 把「be-image 換 Ubuntu 24.04」列為獨立 FR、不在本期——方向沒錯，但它其實是決策者真正要的那半件事，現在成為 FR-131 主路線。