07 · 軟體供應鏈安全與稽核
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 20 · 端到端建置稽核 | ||||||||
| 20.1 | 稽核 ingest 服務上線正式環境，Backstage 已產生事件 | 2026-07-06 | 2026-10-30 | 進行中 | — | SRE | — | — |
| 20.2 | 建置事件封套與關聯鍵定案 | — | 2027-05-21 | 規劃中 | 20.1 | SRE | — | 等待 20.1 |
| 20.3 | 每次建置與部署皆產生事件，來自共用範本 | — | 2028-09-08 | 規劃中 | 15.3, 20.2 | SRE | — | 等待 15.3, 20.2 |
| 20.4 | 從申請到部署，可用單一查詢回答 | — | 2029-01-12 | 規劃中 | 20.3, 22.3 | SRE | — | 等待 20.3, 22.3 |
| 21 · 弱點管理(DefectDojo) | ||||||||
| 21.1 | DefectDojo 納入 IaC/GitOps 管理並接 SSO — Product 與 Engagement 依 repository 建模 | — | 2026-10-23 | 規劃中 | — | SRE | — | — |
| 21.2 | 管線所有掃描器回報至 DefectDojo — 去重並關聯建置 | — | 2026-12-18 | 規劃中 | 21.1 | SRE | — | 等待 21.1 |
| 21.3 | SLA 政策上線，發布閘門讀取 DefectDojo | — | 2027-02-12 | 規劃中 | 21.2 | SRE | — | 等待 21.2 |
細節
20.1稽核 ingest 服務上線正式環境，Backstage 已產生事件2026-10-30進行中 · 2/4
- Backstage 已接為事件來源負責人 · Charles
- 驗證唯寫特性，而非假設:沒有任何 producer 憑證同時具備讀取權負責人 · TBD唯寫才讓這條軌跡成為證據,而不只是一個資料庫。一個同時能讀的 producer 憑證不會弄壞任何東西,在程式碼裡也看不出來,卻會安靜地讓這條軌跡失去價值 — 所以它必須被檢查,而不是被信任。
- 資料表設定保留期與分割過期負責人 · TBD沒有明訂保留期的稽核軌跡,面對合規問題時兩個方向都答不好 — 太短則證據已經不在,太長則是一份沒有人選擇過的責任。
20.2建置事件封套與關聯鍵定案2027-05-21規劃中 · 0/4
- 議定建置與部署事件的 action 名稱、target_id 與 metadata負責人 · TBD
- 單一關聯鍵可串起管線日誌、追蹤與掃描結果負責人 · TBD封套的 correlation_id 定義就是 trace id,而 19.1 會讓結構化日誌帶上它。這把鑰匙在兩份設計裡本來就存在 — 這條 task 是議定共用同一把,而不是再造一把。
- 明確決定:日誌與相依清單不進入事件封套負責人 · TBD封套沒有訊息本體欄位,資料表的分割與分群也是為可過濾的事件而設計。把管線輸出放進 metadata 欄不只是誤用,也是成本問題 — 而且會在項目 19 正要退掉第二個日誌儲存時,再立起第三個。
- 在管線重寫之前定案，讓發射事件隨重寫一併完成負責人 · TBD本里程碑刻意不等 15.3。若在其後才決定封套形狀,就得對 15.3 剛重寫完的每一條管線再掃一遍。
20.3每次建置與部署皆產生事件，來自共用範本2028-09-08規劃中 · 0/4
- 發射事件寫在共用的 GitLab CI 範本，而非逐條管線負責人 · TBD等 15.3 讓項目 20 付出完成時間的代價,換來只做一次。現在建在 Jenkins 管線上,之後會隨它們一起被重寫。
- 每次建置記錄:誰、何時、哪個 revision、哪個產出物負責人 · TBD
- 14.3 把人從部署觸發環節拿掉,而它的稽核 task 是把「誰要負責」的答案移到那次合併上。這裡才是那筆事件真正被寫下的地方。
- 事件指向相依清單，而非內含它負責人 · TBD21.2 的 SCA 掃描器已經把相依關係盤點進 DefectDojo。記錄指標維持單一副本;內含清單則會產生第二份,而兩份是會分歧的。
20.4從申請到部署，可用單一查詢回答2029-01-12規劃中 · 0/3
- 串起整條鏈:誰申請、誰核准、哪個 MR、哪次建置、哪個產出物、部署到哪負責人 · TBDBackstage 記錄申請與核准,其 scaffolder 開出 MR;對應的 producer 已經存在。22.3 是這些事件取得關聯鍵、讓鏈上其餘環節接得回來的地方,故本里程碑相依於它。
- 以重跑一次真實事故作為驗收方式負責人 · TBD審 schema 只能說明欄位齊全。重跑一次調查才能說明人們實際會問的問題答不答得出來 — 那是兩種不同的結論。
- 查詢權限與寫入權限分離負責人 · TBDAPI 已有 reader 角色;這裡是把它給人、而不是給 producer 的地方 — 與 20.1 從另一側驗證的是同一道分離。
21.1DefectDojo 納入 IaC/GitOps 管理並接 SSO — Product 與 Engagement 依 repository 建模2026-10-23規劃中 · 0/3
- 既有實例的 Helm/GitOps manifest，設定匯出為程式碼負責人 · Charles在運行中的實例旁重建後切換 — item 02 的先建後拆模式。
- 以 OIDC 接 SSO，角色由群組對應負責人 · TBD
- 依 repository 建立 Product/Engagement 模型，自 GitLab 群組樹匯入負責人 · TBD
21.2管線所有掃描器回報至 DefectDojo — 去重並關聯建置2026-12-18規劃中 · 0/3
- 上傳掃描結果並附建置 id 的管線 job 範本負責人 · TBD
- SAST、SCA、容器映像與密鑰掃描器接入負責人 · TBD
- 對 staging 定期執行 DAST負責人 · TBD
21.3SLA 政策上線，發布閘門讀取 DefectDojo2027-02-12規劃中 · 0/3
- 與資安及產品負責人議定依嚴重度的 SLA負責人 · TBD
- 發布閘門：阻擋有逾期重大弱點的建置負責人 · TBD
- 跨產品風險儀表板給資安與管理層負責人 · TBD