# 「透明、安全與合規：國泰中台微服務供應鏈安全治理的SBOM、CBOM與AIBOM新思維」

{%hackmd @coscup/announcement-2025 %}

> 請從這裡開始

## 1. AGENDA
### 微服務語境下的供應鏈安全量量
- 微服務時代，供應鏈是否已成為新的攻擊主戰場？
- 當量子運算來襲，您現有的加密防線還足以抵擋嗎？
- AI 模型，是否仍是您治理上的透明黑箱？
- 如何達到隱私、安全與合規？

### 解讀微服務供應鏈的新思維
1. **從漏洞「斷鏈」到軟體組件「透明」**
2. **應對後量子衝擊，構築加密「韌性」**
3. **從 AI 模型「黑箱」到 AI 治理「可問責」**

### 整合與超越：打造金級安全新標準
- 開源規範 = 合規 × 競爭力
- Shift Left
- Q & A

---

## 2. 全面因應之道：構建三大信任堡壘
**面對複合式威脅，我們該如何達成透明、安全與合規？**

### 2.1 可見性
- 每一個應用、加密演算法、AI 模型，其修改與查風險都必須是透明可見的。

### 2.2 可控性
- 建立準則與原則，快速發現漏洞。
- 從被動修補轉為主動防禦與標準治理。

### 2.3 可信賴性
- 滿足監管機關及嚴格**合規要求**。
- 建立客戶信任，確保企業長期穩定發展。

---

## 3. 漏洞追蹤斷鏈
### 遇到的痛點
- 例：公司爆發 **Log4Shell** 漏洞，上線系統哪些會受影響？哪些不會？

### 國泰新思維 — 從混亂到標準
- 在 CI/CD 流程中自動化產生 **SBOM**。
- 結合 **VEX**（Vulnerability Exploitability Exchange）應用。
- VEX 如智慧篩檢器，判斷哪些漏洞是真正威脅，哪些只是虛晃。

---

## 4. 前情摘要
- 單純漏洞資訊量龐大，但在不同情境下威脅程度不同，有時不存在真實風險。
- 若漏洞功能未被使用，即使存在漏洞，也不會構成直接威脅。

### VDR：漏洞掃描報告
- 常見的漏洞掃描文件。
- 包含漏洞、CVE、CVSS 評分、影響範疇及修補建議。

### VEX：漏洞利用交換
- 說明漏洞元件在實際使用情境中的可利用性。
- 與供應商及行業共享可利用性狀態。
- 明確哪些漏洞會帶來風險，哪些不會。

## 5. 後量子衝擊
### 遇到的痛點
- 「負責內外交流的密碼套件，在未來 5-10 年內將無法再被信任。」
- 當量子運算能力到達臨界點，現有密碼演算法將面臨破解風險。
- 需要提早規劃與應對，避免未來陷入被動。

### 國泰新思維 — 防患於未然
- 透過 **CBOM (Cryptography Bill of Materials)** 對密碼模組與演算法進行全盤盤點。
- 建立對時間與強度變遷的監測機制。
- 強調團隊在未來量子計算興起前的前瞻性佈局，確保在密碼技術上的「安全」與「合規」。

## 6. 加密物料清單（CBOM）
**Cryptography Bill of Materials**
- SBOM 的衍生版本，更詳細地描述軟體中的加密元件及其特性。
- CBOM 列出軟體產品中使用的加密演算法和函式庫。

### 組成
- 加密演算法
- 加密協議
- 金鑰長度及設定
- 加密函式庫及版本

### 用途
- 提供清單，全面視覺化軟體產品的加密覆蓋度。
- 幫助評估加密演算法對量子運算的耐受性。
- 支援加密覆蓋度的策略性管理。
- **顯示不同加密模組及其使用的函式庫之間的依賴關係。**
- 遵循與量子密碼標準一致。

# Open Source - CBOMkit

## 📖 解說
IBM 開發並釋出了 **CBOMkit**，直接基於 **CycloneDX** 格式的加密物料清單（CBOM），能進行提取、彙整、分析和管理。

主要目的：
- 在開發流程中找出所使用或依賴的加密演算法
- 向使用者提供標準化且可重用的 CBOM

**支援語言**：Java、Python
**參考連結**：[https://research.ibm.com/blog/quantum-safe-cbomkit](https://research.ibm.com/blog/quantum-safe-cbomkit)

---

## 🔄 流程說明
1. **Source code** ➜ 經由 **CBOM Generator** 生成 CBOM
2. CBOM 可：
- 透過 **CBOM Viewer** 進行可視化檢視
- 儲存至 **CBOM repository**
3. CBOM repository 與 **Crypto dependencies** 關聯
4. CBOM Viewer 可與 **Compliance Engine** 進行規範檢查
5. **SonarQube plugin** 也可輸出 CBOM

---

## 📊 Mermaid 流程圖

flowchart LR
    A[Source code] --> B[CBOM Generator]
    B --> C[CBOM]
    C --> D[CBOM Viewer]
    C --> E[CBOM repository]
    D --> F[Compliance Engine]
    E --> G[Crypto dependencies]
    B -.-> H[SonarQube plugin]

    style A fill:#d0e6f9,stroke:#036
    style B fill:#f9f1d0,stroke:#630
    style C fill:#fff,stroke:#333
    style D fill:#d0f9e6,stroke:#063
    style E fill:#f9d0d0,stroke:#600
    style F fill:#e0d0f9,stroke:#306
    style G fill:#f0e0c0,stroke:#640
    style H fill:#f0f0f0,stroke:#333

## 📌 AI 模型治理宣言區

### 🚨 遇到的痛點
- 「雖然 AI 在生命週期成果層面，AI 模型表現出一致（看起來一樣），它也會出事。」
- 尤其是遇到**演算法透明度不足**、**演算法不可驗證**，甚至**違反規範與倫理**時，風險會更高。

---

### 💡 國泰新思維
#### 打開黑箱
- 團隊可透過 **AI-BOM** 實現 AI 模型的全生命週期可見性，從訓練數據到模型部署，揭露清楚的資源與風險。
- **能見度與透明度**：確保模型透明、可理解、可追溯，並落實負責任的 **AI 治理** 與 **合規**。

---

## 🤖 人工智慧物料清單（AI-BOM）

### 定義
AI Bill of Materials 用於描述人工智慧生命週期中所有資產的完整清單，涵蓋**模型**、**資料集**、**訓練流程**與**授權資訊**。

---

### 🧩 組成
- **模型**：架構、超參數、演算法類型、來源等
- **資料集**：來源、標註方式、質量與偏差
- **訓練環境**：硬體環境、軟體版本、訓練時間
- **測試與驗證**：測試數據來源與測試結果
- **授權資訊**：涵蓋取得資源的使用條款與可回溯性

---

### 🎯 用途
- 提供模型大小、訓練資料來源、訓練時間、授權票據等
- 治理推進的透明度與責任歸屬
- 評估 AI 系統的可重複性、品質與法規的適性
- 增進 AI 資產與資源的主治理
- 與 **EU AI Act** / **NIST AI** 等未來法規標準對齊

## 🛡 治理框架

> 「面對微服務供應鏈問題，策略定方向、流程落實審查、執行層自動驗證 — 三層合力，才能真正做到透明、安全、合規。」

### 三大面向
- **策略（OSPO）**
- 制定策略 / 合規政策
- 法規對應 & 風險原則
- 回應社群規範
- **流程（OSRB）**
- 元件審查與例外流程
- 建立 VEX 清單
- 風險分類與應對處置
- **執行（DevSecOps）**
- 自動化生成 SBOM / CBOM / AIBOM
- Policy-as-Code
- 監控與維運

---

## 🖥 微服務供應鏈 - 小規模試行

### CI/CD Pipeline 流程
1. 開發人員提交 **Source Code**
2. 進行 **Build & Test**
3. 寫入 **SBOM 生成**
4. 推送至 Registry
5. 進行 **Security Scan**
6. 驗證 **Hash** 與 **Chain Update**
7. 發佈部署

**使用開源工具：**
- syft
- VEX
- dependency-track
- GUAC
- PQCA/cbomkit
- Aetheris AI

---

flowchart LR
    A[Developer Commit] --> B[Build & Test]
    B --> C[SBOM Gen]
    C --> D[Push to Registry]
    D --> E[Security Scan]
    E --> F[Chain Update & Hash Verify]
    F --> G[Deploy]

    subgraph Open Source Tools
    H[syft]
    I[VEX]
    J[dependency-track]
    K[GUAC]
    L[PQCA/cbomkit]
    M[Aetheris AI]
    end

    C --> H
    C --> I
    C --> J
    C --> K
    C --> L
    C --> M

⚖ 開源規範 = 合規 × 競爭力

監管要求

行政命令 (EO 14028)

ISO 27001

NIST SP 800-218

資訊服務管理規範 (CNSA 2.0)

歐盟人工智慧法案 (EU AI Act)

金管會

公共內容規範

---

導入 Open Source

整合 CI/CD 自動生成各類物料清單 (BOM)

導入 OWASP 與 CycloneDX 規範

支援 SBOM / CBOM / AIBOM

---

競爭力

軟體成分完整透明

格式統一

---

## ⚖ 開源規範 = 合規 × 競爭力

### 📜 監管要求
- 行政命令 (EO 14028)
- ISO 27001
- NIST SP 800-218
- 資訊服務規範 (CNSA 2.0)
- 歐盟人工智慧法案 (EU AI Act)
- 金管會
- 公共內容規範

---

### 🛠 導入 Open Source
- 整合 CI/CD 自動生成各類物料清單（BOM）
- 導入 OWASP 與 CycloneDX 規範
- 支援 SBOM / CBOM / AIBOM

---

### 🚀 競爭力
- 軟體成分完整透明
- 格式統一
- 加速漏洞清查與修補
- 支援 AI 相關法令追蹤

---

### 🔍 驗證 & 維運（Future）
**為什麼要做？**
- BOM 需隨版本更新並立即修改
- 資產來源可追溯，確保完整性
- 部署前自動驗證，避免帶有漏洞的版本上線

**採用工具：**
- sigstore cosign（簽署與驗證）
- 特性：
- ✅ 可追溯
- ✅ 可驗證
- ✅ 不被異動

---

## 🏗 建立 BOM 流程不只是一開始

### 1. Shift-Left
- 將 BOM 植入開發流程
- 可及早檢測與監控供應鏈的開源組件與潛在漏洞

### 2. Runtime
- 已上線部署的 BOM 管理
- 是持續保護線上服務的關鍵，需納入運行期評估

### 3. 資料安全
- BOM 文件包含有關軟體組件的詳細信息
- 資料必須保持機密性與安全性

--------------

## SBOM

- log4j / xz
- Solution: CICD 產 SBOM + [VEX](https://cyclonedx.org/capabilities/vex/)
- vdr (漏洞揭露報告) + vex (漏洞利用交換)
- https://owasp.org/blog/2023/02/07/vdr-vex-comparison
- https://blog.adolus.com/what-is-vex-and-what-does-it-have-to-do-with-sboms
- syft (產sbom) + vex

## CBOM

- PQC / CNSA 2.0
- 2030 後都要使用 PQC https://www.taiwannews.com.tw/zh/news/6111209
- SBOM 的擴充, 1.6+ 之後
- CBOMKit 使用 cyclonedx 格式
- https://github.com/PQCA/cbomkit

## AIBOM

- OpenSource AI Model
- 對其 EU AI Act / NIST AI
- Aetheris AI - AI SBOM Generator
- CycloneDX 格式 可抓 Hugging Face
- SaaS 服務

## DevSecOps

- survey cosign 中

## OSSIE

###### tags: `COSCUP2025`, `zhtw`, `intermediate`