敏捷與資安的衝突：敏捷開發（Agile）專注於最小化前期規劃並快速產出可運作的程式碼，這通常導致沒有足夠的時間進行傳統且詳細的資安規劃與分析。
Control Gate 的定位：在 CI/CD 流程中設置自動化的 Control Gate，能在不破壞敏捷速度的前提下，有效防止開發團隊無意間引入安全缺陷，是避免系統上線翻車的關鍵防線。
在建置（Build）與持續整合流程中設立明確的「中斷建置標準（Build-Break Criteria）」。例如，規定原始碼必須通過靜態分析（SAST），且確認無的重大缺陷後，才能提交（Commit）至主分支，有效防止開發團隊無意間引入安全缺陷。
(e.g., Agile, waterfall)
瀑布式模型 (Waterfall Model)
| 階段 | 安全活動 |
|---|---|
| 需求 (Requirements) | 定義安全需求、識別法規遵循需求、建立誤用/濫用案例 |
| 設計 (Design) | 威脅建模 (Threat modeling)、安全架構審查、安全設計模式的選擇 |
| 實作 (Implementation) | 安全編碼實務、靜態應用程式安全測試 (SAST)、程式碼審查 (Code reviews) |
| 測試 (Testing) | 安全測試（DAST、滲透測試、模糊測試）、驗證與確認 (V&V) |
| 部署 (Deployment) | 安全組態配置、環境加固 (Hardening)、取得營運安全核准 |
| 維護 (Maintenance) | 修補程式管理 (Patch management)、漏洞管理、事件回應 |
敏捷模型 (Agile Model)
| 階段 | 安全活動 |
|---|---|
| 衝刺規劃 (Sprint Planning) | 納入安全相關的故事 (stories) 與驗收標準 |
| 使用者故事 (User Stories) | 撰寫安全性的故事（例如：「身為一名使用者，我希望我的工作階段在閒置後會自動逾時登出」） |
| 完成的定義 (Definition of Done) | 納入安全標準：已完成程式碼審查、SAST 檢測通過、無嚴重漏洞 |
| 每日站立會議 (Daily Stand-ups) | 提出阻礙安全進度的問題、追蹤安全技術債 (security debt) |
| 衝刺審查 (Sprint Review) | 展示安全功能、審查安全測試結果 |
| 回顧會議 (Retrospective) | 討論安全經驗教訓、流程改善方案 |
(e.g., implementing security frameworks, promoting security awareness)
通用準則 (Common Criteria, ISO/IEC 15408)框架允許廠商對其產品提出安全聲明 (security claims)，並讓這些聲明接受第三方的獨立評估：
| 概念 | 說明 |
|---|---|
| TOE (Target of Evaluation，評估標的) | 正在被評估的產品或系統 |
| ST (Security Target，安全目標) | 與特定 TOE 相關聯的安全屬性 |
| PP (Protection Profile，保護特徵描述) | 針對一類特定產品所制定的安全需求 |
| EAL 1–7 (Evaluation Assurance Levels，評估保證等級) | 1 = 最低，7 = 最高 |
| 層面 | BSIMM | SAMM |
|---|---|---|
| 全名 | Building Security In Maturity Model | Software Assurance Maturity Model |
| 類型 | 描述性的（別人都在做什麼） | 規範性的（你應該做什麼） |
| 基礎 | 來自組織的實證經驗數據 | 由專家定義的最佳實務 |
| 主要用途 | 標竿比較 (Benchmarking) | 建立策略藍圖 (Roadmap creation) |
| 維護單位 | Synopsys (商業機構) | OWASP (開源社群) |
(e.g., control gate, break/build criteria)
| 元素 | 說明 |
|---|---|
| 關卡負責人 (Gate owner) | 負責決定是否放行 (go/no-go) 的負責人或委員會 |
| 進入準則 (Entry criteria) | 在進行閘門審查前必須具備的前提條件 |
| 審查活動 (Review activities) | 在關卡處進行的評估（文件審查、掃描報告、風險評估） |
| 退出準則 (Exit criteria) | 必須滿足才能通過關卡的條件 |
| 決策 (Decision) | 通過 (Go)、不通過 (No-Go)，或條件式通過 (Conditional Go) |
| 升級路徑 (Escalation path) | 用於解決意見分歧或處理例外情況的流程 |
Microsoft Security Development Lifecycle (SDL) Practices
https://www.microsoft.com/en-us/securityengineering/sdl/practices
Claude The AI-Native SDLC playbook
https://claude.com/blog/the-ai-native-sdlc-playbook
| 階段 | 傳統軟體開發生命週期 | AI原生軟體開發生命週期 |
|---|---|---|
| Plan | 委員會收集的需求，經研討會和簽署確認後提煉，並手工記錄下來。 | Claude直接從源頭提煉痛點，並將其捕捉到intent.md既易於人理解又可供機器操作的格式中。 |
| Design | 分析師編寫的規範，由設計師解讀。 | 需求和設計被壓縮到與代理人的一次工作會議中，遵循以技能形式編碼的標準，並在 Git 中進行版本控制。 |
| Build | 測試和程式碼都是手工編寫的，文件是在主要開發完成後才編寫的。 | 測試和程式碼由人工智慧生成，機構知識以版本化的機器可讀CLAUDE.md檔案和技能的形式維護。 |
| Test | 階段邊界處的品質保證關卡 | 實施過程中貫穿持續評估 |
| Deploy | 人工會審查每一行程式碼，程式碼治理也以審查週期的形式進行，但這種週期往往缺乏一致性。 | 多層智能體審查，人工審查保留給受監管的關鍵代碼。治理機制在人工智慧運作過程中逐步實施，並透過鉤子作為審批門。 |
| Maintain | 人類會監控生產過程，以發現缺陷。 | 代理程式會監控即時部署。任何被突破的控制帶都會被診斷出來，並作為新的控制帶重新寫入循環中。intent.md |
iThome鐵人賽
看影片追技術