一台 Windows 11 筆電，一個單節點的 CRC 叢集，對外網路斷掉。在這個條件下完整跑完一次 CI：建構、六道安全掃描、SBOM 產出、Cosign 簽章，最後由 Kyverno 在 Kubernetes API 准入層級驗簽，通過才准建立 Pod。

這 30 天要做的就是這件事，而且每一步都在同一台機器上實際跑通、逐項查證過。

為什麼要強調斷網？因為多數 CI/CD 教學預設外網暢通、雲端資源近乎無限，而企業內網最痛的地方恰恰在這裡：連不出去、沒有 root、SCC 卡死。這些限制不是為了增加難度而設的，它們就是現場。

但在談防線之前，得先問一個更基本的問題：

「只要能在 GitHub Actions 或 Jenkins 上成功執行 npm run build 並打包出 Docker Image，就算是完成了持續整合（CI）嗎？」

在現代軟體開發中，軟體供應鏈攻擊（Software Supply Chain Attacks）層出不窮——從 SolarWinds 事件、Codecov 腳本遭篡改，到 npm / PyPI 上日益頻繁的套件投毒（Typosquatting & Dependency Confusion）。單純在遠端伺服器自動執行編譯指令，只能稱作「自動化建構（Automated Build）」；真正具備生產品質（Production-Grade）的 CI，真正要做到的是：在程式碼合入主線與交付部署前，建立一套具備「強制阻擋能力（Fail-Fast）」的軟體供應鏈安全與品質防禦邊界。

要評估一套 CI 流水線是否達到生產級別，可從以下三組關鍵的技術認知差異來檢視：

1. 「自動化建構」vs.「持續整合（CI）」

• 自動化建構：收到 Code Push 即觸發腳本，執行編譯並產出檔案即告結束。
• 生產級 CI：整合單元測試覆蓋率、嚴格型別檢查與靜態程式碼分析。只有當全數關卡通過且達到品質門檻時，才允許合入主線。

2. 「告警式掃描」vs.「阻擋式門檻（Fail-Fast）」

• 告警式掃描：資安工具掃出多個高危 CVE 或潛在機密，但 Pipeline 依然顯示綠燈並完成打包，最終報告留存於系統中無人處置（產生假綠燈現象）。
• 生產級 CI：設置硬性阻擋門檻（Gatekeeper / Quality Gate）。一旦偵測到 Secrets 洩漏或高危漏洞，流水線立即中斷並阻止 PR 合併，將資安風險直接攔截於開發階段。

「假綠燈」——流水線是綠的，但它什麼也沒擋住——會是這 30 天反覆回來的主題。後面你會看到它以各種形式出現：一個測試檔就能繞過的覆蓋率門檻、永遠不會失敗的 sed -i、看起來裝好了其實從沒生效的忽略清單。

3. 「產出映像檔」vs.「可信產物（Artifact Trust）」

• 產出映像檔：僅完成 docker build 與映像檔推送，無法保證映像檔內部第三方元件之安全性，亦無法驗證來源是否遭中途篡改。
• 生產級 CI：在建構過程中同步生成 SBOM（軟體物料清單），並透過 Cosign 完成數位簽章，確保後續部署（如 GitOps / ArgoCD）拿到的都是可追溯、可驗證且不可否認的合法產物。

這條防線最終長什麼樣子？把一個沒有簽章的映像檔推到受保護路徑，然後試著部署它：

Error from server: admission webhook "mutate.kyverno.svc-fail" denied the request:
verify-frontend-demo-image:
  verify-image-signature: 'failed to verify image .../frontend-demo/client:unsigned-test:
    .attestors[0].entries[0].keys: no signatures found'

Pod 從未被建立——不是啟動後被殺掉，是在 API Server 的准入階段就被拒絕。這是 Day 29 的實測輸出，放在第一天是想先讓你看到終點；接下來 28 天要做的，是把通往這個結果的每一塊零件一個一個裝起來。

這三組差異，都建立在前面提到的那個前提之上：一台筆電、一個真正斷網也能跑的環境。具體做法是：所有 Task 使用的容器映像以 digest 釘死並經內部 Registry 代理，弱點資料庫與靜態分析規則集透過排程鏡射至內部儲存，執行期偵測不到對外連線時，快取刷新程序會略過而非中斷整條流水線。此設計貫穿後續多個階段的實作細節，每一項後面都會各自展開。

今日目的：說明這 30 天要解決的核心問題與整體防線佈局，作為後續 29 天的地圖。

先備知識：本系列預設讀者已具備基礎 Kubernetes 概念（Pod／Service／Namespace）、基本 Docker 操作經驗、Git 版本控制使用習慣，以及在終端機下執行指令的基本熟悉度。Tekton、Kyverno、Cosign、SLSA 等本系列核心工具與標準不要求預先熟悉，會在各自登場的章節從零介紹、逐步建立。

一、 流水線的核心任務：六大風險阻擋線

供應鏈的每個環節都可能被下手，因此這條流水線上設了六道關卡：

這六道關卡將於後續單元以 DAG（有向無環圖） 順序串接，讓每一步的先後順序都有資安上的理由。

二、 30 天實作藍圖：階段規劃與架構拓撲

為了留下排雷和調整的餘地，本系列將 30 天的演進過程劃分為五個階段。各階段內部單元可依除錯需求與架構調優靈活調整，同時維持整體防禦體系的依賴順序：

階段性實作規劃

1. 階段一：單機基礎設施與金鑰管理（Day 1 - Day 12）
   配置 Windows 11 CRC（OpenShift Local）環境，釐清 OpenShift SCC 權限邊界，部署私有資產庫（Nexus 3、Gitea），並透過 Sealed Secrets 建立內部機密管控機制與災難復原流程。
2. 階段二：雲原生 CI 引擎與自動化排雷（Day 13 - Day 17）
   安裝 Tekton Pipelines Operator，實作跨 Namespace 引用規範與 PVC 工作區共享機制，配置 Gitea Webhook 自動觸發並建立 OVN-Kubernetes CNI 異常診斷 SOP。
3. 階段三：DevSecOps 品質與安全防線（Day 18 - Day 23）
   設計具備 Fail-Fast 安全語意的 DAG 流程，依序導入 Gitleaks 機密掃描、Semgrep SAST、Trivy fs 相依套件掃描、Jest 測試覆蓋率門檻、TypeScript 型別檢查與 SBOM 產出。
4. 階段四：無特權 Image 建構與數位簽章（Day 24 - Day 27）
   使用 Rootless Buildah 完成最小化映像檔封裝，執行 Trivy 映像檔漏洞掃描，並建立 Cosign 數位簽章與私鑰不落地管理機制。
5. 階段五：GitOps 自動化與准入控制器封鎖（Day 28 - Day 30）
   透過 yq 進行結構化 GitOps 設定更新，部署 Kyverno 准入政策實體封鎖未簽章映像檔，並驗證 SLSA Level 3 之 Tekton Chains 來源證明機制。

逐日依賴地圖

30 天雖然依五個階段循序推進，但部分早期單元建立的機制會被後段多個天次重複依賴，形成跨階段的「骨幹」與「輻射」關係。下圖標出其中 7 組關鍵的跨天依賴（以依賴來源日為起點、彙整指向後續依賴日），協助之後跳讀或排錯時快速定位「這個機制最早在哪一天建立」。

全鏈路自動化與安全防禦拓撲

下圖展示本系列於單機 CRC 環境落地的全鏈路 DevSecOps 自動化與防禦架構拓撲：

整體架構涵蓋三大階段與 API 層級的准入攔截機制：

• 階段一：原始碼異動：開發者提交變更至內部 Gitea 倉庫，觸發 Webhook 通知。
• 階段二：安全 CI 簽署流水線：Tekton 接收事件並啟動 Pipeline，平行執行原始碼層級的安全掃描與品質檢查（gitleaks、semgrep、sca-scan、單元測試、型別檢查），全數通過後才進行無特權建構；建構產出的映像檔還要再通過 trivy-scan 的映像檔層漏洞掃描，通過後才產出 SBOM、以 Cosign 完成數位簽章，並更新 GitOps 參考。
• 階段三：GitOps 部署交付：自動更新 GitOps 倉庫後，由 ArgoCD 同步變更並向 OpenShift 請求建立 Pod。
• 准入控制與硬性阻斷（Kyverno Webhook）：在 Kubernetes API Server 准入層級驗證映像檔之 Cosign 簽章與 SLSA 來源證明。驗證通過則寫入 etcd 並由 Kubelet 啟動 Pod；未簽章或驗證失敗者於 API 層級被直接拒絕，Pod 從未建立。

三、 實驗環境與實務邊界條件

本系列實作建置於 Windows 11 單機運行的 Red Hat OpenShift Local (CRC)。

為什麼是 CRC，而不是資源需求更輕量的 minikube 或 kind？答案在於 OpenShift 原生提供的四大核心機制，這些機制是全系列實戰的地基：

1. SCC (Security Context Constraints)：控制容器運行身份與權限（如限制任意 UID 執行與特權磁碟掛載）；這與 Day 29 會介紹的 Kyverno 簽章驗證是兩層不同的准入控制機制，前者管執行權限，後者管簽章真偽。
2. ImageStream：OpenShift 內建私有 Registry 的整合與映像檔生命週期管理機制，自動追蹤映像檔變更。
3. Route：OpenShift 內建的 Ingress 機制，提供開箱即用的外部路由與服務暴露。
4. Operator：ArgoCD 與 Tekton 在平台上的官方安裝與維運方式。

minikube、kind 這類輕量方案要重現這四項，得自己額外拼湊 Ingress Controller、私有 Registry、Operator 生態；選擇原生具備這些機制的 OpenShift，是用資源需求換取更貼近正式環境的平台能力。

不同於一般預設外網暢通且具備 Root 權限的雲端 CI 環境，這 30 天處理的是企業環境真正會卡住你的地方，特別針對以下情境進行實作與排雷：

1. 「離線閉環 / 網路受管制」環境：處理無法任意連外下載模組或 Docker Hub Image 的情境，建置內部 Nexus 依賴庫與私有 Registry。
2. OpenShift SCC（Security Context Constraints）極限權限管制：在非 Root 且無特權（Unprivileged）容器約束下，順利跑通 Buildah 建構與各類安全掃描。

這些限制正是企業在推動 DevSecOps 落地時最常面臨的硬核痛點。本系列將拆解從初始設定到生產環境調優的完整細節（包括假綠燈排查、語意重構與離線 API 轉折）。

四、 國際資安標準之 PoC 技術對映

單靠 CI 流水線無法替代企業整體的資安合規認證，本系列實作也不是要完整滿足國際資安標準的全部條款，而是一套概念驗證（PoC）環境。以下對映呈現的是「具體做到哪些技術行為」，不是等級認證——這個態度在全系列中維持一致，後續章節提到 SLSA 等標準時也會延續同樣的立場。

1. OWASP DSOMM（DevSecOps 成熟度模型）

• Level 1：自動化建構與測試，並引入 sca-scan（Trivy fs）相依套件掃描與 semgrep 靜態分析。
• Level 2：引入 gitleaks 機密偵測、trivy Container 掃描與測試覆蓋率追蹤，任一安全掃描未通過即中斷建構。
• Level 3：實作 SBOM 產出、Cosign 數位簽章 與 Kyverno 准入驗證，讓產物被動過手腳時驗得出來。

2. NIST SSDF（安全軟體開發框架，SP 800-218）

聚焦 PW（生產安全軟體）與 RV（漏洞回應）兩個類別：

• PW.1：ESLint @nx/enforce-module-boundaries 規則，編譯期強制執行軟體模組邊界約束。
• PW.4：semgrep SAST 與 ESLint 靜態分析工具，自動化執行靜態程式碼檢測。
• PW.5：Jest 自動化執行單元測試，作為功能回歸測試的自動化關卡。
• PW.7：sca-scan 與 trivy-scan 設置高危以上漏洞即時中斷（Fail-Fast）之處置門檻。
• RV.1：建構期自動生成 SBOM，供日後漏洞盤點使用。

3. SLSA（軟體供應鏈安全等級）

• Level 1：Pipeline 流程定義以 Tekton YAML 進行版本控制，並於建構過程中留存自動化日誌。
• Level 2：建構流程限定於 OpenShift 內部 ci Namespace 容器環境中執行，經由 Gitea Webhook 觸發，並將 Image tag 與 Git Commit SHA 進行綁定。
• Level 3：運用 Cosign 簽章與 Kyverno 強制驗證，並探討 Tekton Chains 產生 Provenance Attestation（建構來源證明）之實驗性技術方向。

五、 總結與下一步

DevSecOps 的核心在於將資安控制項融入開發流程，轉化為客觀、可量化且可自動執行的阻擋門檻。這是一份真的踩過一遍的紀錄，展示如何從零建立基礎環境，逐步擊破偽綠燈與資安漏洞，並透過 PoC 實作滿足國際資安規範要求的技術控制點。

下一天（Day 2），我們將進入單機實驗室搭建——於 Windows 11 環境建立 CRC（OpenShift Local）單機叢集並掌握資源配置心法。