在人人都能開發、服務百花齊放的環境下，基於口述生成的系統往往容易顧此失彼：防範了 SQL Injection，卻可能漏掉資料加密；而一口氣加入過多控制需求，又會導致程式執行緩慢，產生各種不良後果。透過 CSSLP 建立扎實的生命週期觀念，能幫助我們不再瞎子摸象，而是針對不同需求與情境，量身打造出兼顧效能且恰到好處的資安防護。
Day 01 ｜ 如期交付的抉擇：一場沒有贏家的爭執
Mapping: Domain 1.1 & Domain 2.1 (Core Concepts, SDLC Methodologies) / SSDLC 成本左移、3Rs (Reliability, Resiliency, Recoverability)。
Day 02 ｜ 安全控制的選擇：將擔心的後果映射到 CIA 防禦邊界
Mapping: Domain 1.1 (Core concepts) / CIA, 治理與合規 (GRC)。
Day 03 ｜ 簡單勝過繁複：從最小權限到機制簡化 (Economy of Mechanism) 的架構哲學
Mapping: Domain 1.2 (Security design principles) / Least privilege, Economy of mechanism。
Day 04 ｜ 敏捷開發 (Agile) 不翻車的秘密：設定 Control Gate的投資效益
Mapping: Domain 2.1, 2.2 & 2.3 (Methodology, Security Standards, Milestones and Checkpoints) / CIS Benchmarks, Break/build criteria, DevSecOps。
Day 05 ｜ 別把新技術當成萬靈丹：技術風險 vs. 商業風險的決策心法
Mapping: Domain 2.8 (Integrated risk management methods) / Technical risk vs. business risk, ISO/NIST。
Day 06 ｜ 你無法管理無法量化的事物：用 MTTR 與資安指標 (Metrics) 證明你的價值
Mapping: Domain 2.5 & 2.7 (Security metrics & reporting) / Criticality level, KPI, Dashboards。
Day 07 ｜ 下線 (EOL) 也是隱形成本：應用程式退役與資料銷毀 (Data Disposition) 的經濟學
Mapping: Domain 2.6 (Decommission applications) / End of Life policies, 資料保留與銷毀。
Day 08 ｜ 需求訪談的防坑指南：將 Policy、合規與 Abuse Cases 轉換為具體需求
Mapping: Domain 3.1, 3.2 & 3.6 (Security Requirements, Compliance, Misuse/Abuse Cases) / SQUARE 框架、法規與內部政策轉換、CAPEC 攻擊模式需求化。
Day 09 ｜ 資料分類 (Data Classification)：把有限的預算，精準砸在最核心的資產上
Mapping: Domain 3.3 & 3.4 (Data Classification, Privacy Requirements) / 資料擁有權、分級保護、GDPR/PII、資料匿名化與跨境傳輸。
Day 10 ｜ 身分與存取管理 (IAM)：統一化驗證機制，省下重複造輪子的開發成本
Mapping: Domain 3.5 & Domain 4.3 (Data Access Provisioning, Authentication and Authorization) / 最小權限、Subject/Object 生命週期、AuthN vs. AuthZ、SSO。
Day 11 ｜ 密碼學的維運痛點：加解密與金鑰管理 (Key Management) 怎麼設計才不會整死未來的自己？
Mapping: Domain 4.1 & 4.3 (Cryptography Architectures & Credential Management) / 密碼敏捷性 (Cryptographic Agility)、金鑰生命週期、憑證管理 (X.509, CRL/OCSP)。
Day 12 ｜ 降低系統耦合度的利器：微服務、零信任 (Zero Trust) 與雲端共擔模型
Mapping: Domain 4.1 & 4.3 (Security Architecture Patterns & Reusable Technologies) / 零信任 (Zero Trust) 原則、微服務、雲端共擔責任模型 (Shared Responsibility)。
Day 13 ｜ 別等寫完 Code 才補漏洞：用威脅建模 (STRIDE) 劃出系統的信任邊界
Mapping: Domain 4.4 (Threat Modeling) / STRIDE 模型、DREAD 評估與信任邊界劃分。
Day 14 ｜ 攻擊面 (Attack Surface) 的斷捨離：功能越少越安全，維護成本也越低
Mapping: Domain 4.4 (Attack Surface Evaluation & Management) / 減少進入點與曝露面、Attack Surface Analyzer。
Day 15 ｜ 預防勝於重構：從 OWASP Top 10 看框架 (Framework) 如何選擇防禦方向
Mapping: Domain 5.1 & 5.2 (Common Software Flaws, Common Web App Vulnerabilities) / CWE Top 25, OWASP Proactive Controls, 安全框架選型。
Day 16 ｜ 原始碼風險透視 (Code Risk Analysis)：SAST 與同儕審查如何揪出定時炸彈？
Mapping: Domain 5.2 從靜態分析、CWE Top 25 到排查隱藏在 Code 裡的維護後門 (Backdoors) 與邏輯炸彈 (Logic Bombs)。
Day 17 ｜ 程式碼防線與風險處置：從主動控制到安全風險因應策略
Mapping: Domain 5.3 & Domain 5.4 從檔案完整性監控到防禦編程，如何在系統實作階段築起縱深防線？
Day 18 ｜ 軟體開發中的供應環境安全到獨家配方保護
Mapping: Domain 5.5 & 5.6 從依賴套件清查、編譯器防護到程式碼簽章，打造不被竄改的 CI Build Pipeline。
Day 19 ｜ 擬定資安測試藍圖：測試策略 (Testing Strategy) 與動態測試用例設計
Mapping: Domain 6.1 & 6.2 黑箱、白箱到灰箱；從業務正向邏輯走向 Misuse/Abuse Cases 的逆向攻擊思維。
Day 20 ｜ 主動引爆未知缺陷：模糊測試 (Fuzzing) 與非原始碼軟體資產驗證
Mapping: Domain 6.2 & 6.3 以變異輸入擊潰記憶體極限，並稽核安裝手冊、錯誤訊息與 Release Notes 的隱性風險。
Day 21 ｜ 揪出陰影下的未公開功能：攻擊面清查與未記錄功能 (Undocumented Functionality)
Mapping: **Domain 6.4, 6.7 ** 排查隱蔽 API 與除錯後門，並解決測試資料使用生產環境機敏個資的合規災難。
Day 22 ｜ 測試結果的商業決策：中斷建置標準 (Break-build Criteria) 與缺陷生命週期治理
Mapping: **Domain 6.5, 6.6 ** 在 CI/CD 門禁設立停機底線，結合 CVSS 評分系統科學化排定漏洞修復 SLA。。
Day 23 ｜ 最終驗收防線：獨立確認與驗證 (IV&V) 與標準合規測試
Mapping: **Domain 6.8 ** 從滲透測試 (PT)、弱點掃描到 OWASP ASVS，打造受利害關係人信任的交付保證。
Day 22 ｜ 環境一致性的魔法：組態管理 (Configuration Management) 如何消除維護惡夢
Mapping: Domain 7.2 (Security Configuration Management - SecCM) / NIST SP 800-128, CIS Benchmarks, IaC 防止環境漂移。
Day 23 ｜ 變更管理 (Change Management) 流程：為什麼 CCB 的把關是保護系統穩定性的最後防線？
Mapping: Domain 2.9 & Domain 7.2 (Secure Operation Processes, Change Control Board) / CCB 審查與基準線回滾。
Day 24 ｜ 安全部署與環境隔離：Dev/Test/Prod 權限分離，避免測試污染帶來的復原成本
Mapping: Domain 7.1 & 7.6 (Secure Installation, Authorization to Operate - ATO) / 環境權限隔離、營運授權決策與風險承擔。
Day 25 ｜ 補丁管理 (Patch Management) 的藝術：如何在不搞砸現有系統的前提下更新套件？
Mapping: Domain 7.9 & 7.10 (Patch Management, Vulnerability Management) / 修補策略、回歸測試、SCAP 規範。
Day 26 ｜ 事故回應 (Incident Response) 經濟學：平時的維運設計，如何決定災難止血的速度與代價？
Mapping: Domain 7.7, 7.8 & 7.11 (ISCM, Incident Response, BCDR) / 連續監控 (ISCM)、事件應變生命週期、RTO/RPO 與 BIA。
Day 27 ｜ 軟體供應鏈的隱形成本：開源套件與第三方相依性帶來的維運技術債
Mapping: Domain 8.1 & 8.2 (Software Supply Chain Risk Management, Third-Party Software Risks) / C-SCRM、開源授權（Copyleft 風險）。
Day 28 ｜ 核彈級漏洞爆發時的救命符：軟體物料清單 (SBOM) 如何將盤點時間從數天縮短到數秒？
Mapping: Domain 8.2 & Domain 8.3 (SBOM, Software Composition Analysis) / OWASP Dependency-Track, 套件來源追溯 (Provenance)。
Day 29 ｜ 守住最後一哩路：保護 CI/CD 管道與軟體工件 (Artifact) 完整性的關鍵防線
Mapping: Domain 8.3 & 8.4 (Code Repository Security, Digitally Signed Components & Code Signing) / 數位簽章防竄改、管線防護。
Day 30 ｜ 【完賽回顧】工具會變，思維永存：CSSLP 帶給現代架構師的「恰到好處」防禦哲學
Mapping: Series Wrap-up / 8 大知識域核心串聯、實務心法復盤與考試重點整合。
Domain 1: 概念 (Concepts)
將傳統 CIA 延伸至 AI：保護訓練資料 (機密性)、防範資料下毒 (完整性)、確保 AI 運算資源不被耗盡 (可用性)。
Domain 2: 生命週期管理 (Lifecycle Management)
將 AI 專屬風險評估、MLOps 安全指標與新興 AI 倫理法規，直接納入現有 SDLC 治理框架中。
Domain 3: 需求 (Requirements)
明確定義 AI 的「非功能性安全需求」，包含訓練資料的去識別化 (隱私合規) 以及抵禦對抗性攻擊的模型穩健性。
Domain 4: 架構與設計 (Architecture & Design)
為 AI 元件建立專屬威脅模型。實施嚴格信任邊界與最小權限，確保 AI (如 LLM) 即使產生幻覺或被操縱，也無法越權執行關鍵操作。
Domain 5: 實作 (Implementation)
落實嚴格的輸入/輸出驗證與清理 (防禦提示詞注入 Prompt Injection 最重要的防線)，並確保外部 AI API 的連線與憑證安全。
Domain 6: 測試 (Testing)
超越傳統靜態/動態掃描，必須引入對抗性測試 (Adversarial Testing) 與紅隊演練，驗證 AI 面對惡意輸入時的防禦力。
Domain 7: 營運與維護 (Operations)
上線後持續監控模型漂移 (Model Drift) 與異常輸出，並針對 AI 特有威脅制定專屬的資安事件應變計畫。
Domain 8: 供應鏈 (Supply Chain)
將審查範圍擴大至預訓練模型與訓練資料集，確保第三方來源的完整性與可信度，防範帶有後門的木馬化模型。
CSSLP Certification Exam Outline
https://www.isc2.org/certifications/csslp/csslp-certification-exam-outline
有人分享的的CSSLP各章節重點
https://joeyhage.github.io/csslp-notes/
中興大學SSDLC
https://sites.google.com/email.nchu.edu.tw/ssdlc/
https://sites.google.com/email.nchu.edu.tw/iscb-corporate-training-2/
飛飛的SSDLC
https://ssdlc.feifei.tw/category/ssdlc-series/a00-ssdlc-%e7%b0%a1%e4%bb%8b/
iThome鐵人賽
看影片追技術