本文定義將安全整合進發展實務的關鍵要求，作為 發展安全學科的一部分。
現代組織依賴快速的軟體開發來推動創新、滿足商業需求、維持競爭優勢，並因應不斷變化的業務需求。 雖然 DevOps 促進了這種敏捷性，但隨著程式碼、基礎設施與部署流程快速演進，也帶來新的安全風險。
為了安全採用 DevOps 實務，組織必須將安全整合進開發策略、工作流程與交付流程，並採用 DevSecOps 實務，確保應用程式在整個生命週期中提供安全。
結果
採納本文中的規劃命令，使組織能夠：
- 減少安全弱點引入生產工作負載。
- 提升生產準備決策的一致性。
- 減少開發、安全與營運之間的摩擦。
- 提升應用程式與交付基礎設施的韌性。
- 在管理安全與營運風險的同時，維持創新速度。
認識發展安全的範圍
開發安全不僅適用於應用程式程式碼。 組織應定義涵蓋設計、建置、部署及操作工作負載的所有元件的安全需求與活動。
組織必須考慮以下安全風險：
- 應用程式邏輯與服務
- 基礎架構自動化/基礎設施即程式碼（IaC）部署
- 建置與發行管道
- 部署配置與操作腳本
- 開發者環境與服務識別
- 第三方相依性與供應鏈元件
認識此全範圍有助於組織定義反映現代工作負載交付方式的安全需求，而非將安全限制於生命週期後期的應用程式程式碼審查。
考慮主要風險
組織在定義需求時應明確納入以下風險：
| 風險區域 | 影響範例 |
|---|---|
| 應用程式設計缺陷 | 未經授權存取、資料外洩、持續存在的邏輯缺陷。 |
| 管線遭入侵 | 惡意程式碼注入建置產物。 |
| 開發者環境遭入侵 | 竊取證件或提升特權。 |
| DevOps 工具的誤用 | 透過自動化或整合進行未經授權的變更。 |
| 供應鏈脆弱性 | 引入惡意或有漏洞的依賴項。 |
這些風險直接影響本文所定義的規劃需求，必須透過設計、流程與治理決策來加以解決。
這些風險影響應用程式工作負載以及用於建置與運作的基礎架構。
將安全整合進策略/生命週期
安全性必須納入開發策略，而非作為發布後的控制措施。
組織必須與功能需求並行定義安全需求，並與以下條件對齊：
- 發展策略
- 建築規劃
- 配送工作流程
- 作戰支援模式
資安成果是由工程與營運角色共同承擔的責任，並由資安專家支援。
安全促進創新，不是交付後才加的門檻。
組織必須採用持續的安全開發生命週期（SDL）方法，包括：
- 設計早期定義安全需求。
- 將安全需求與架構及實作對齊。
- 將資安與基礎設施自動化整合。
- 持續進行安全驗證。
- 追蹤安全發現。
- 優先進行修復。
- 將安全發現應用於發布準備度決策，使安全議題在必要時被視為生產阻擋因素。
隨著應用程式架構、風險與交付模式的演進，安全性必須持續評估與改進。
定義最小生產可行性標準
工作負載在發佈到生產環境之前，必須符合最低可行性標準。 這些標準定義了工作負載在三個維度上是否安全、合規且具備生產使用能力：
- 開發（開發）：開發利害關係人定義滿足業務需求及客戶/使用者價值所需的最低功能需求。
- 安全（SEC）：安全利害關係人定義最低要求，以履行監管義務、維持組織安全態勢，並支援主動威脅的偵測與回應。
- 營運（運維）：營運利害關係人定義工作負載在生產環境中可靠運作所需的最低效能、品質與支援性要求。
生產可行性標準：
- 確保工作負載安全部署與運作於生產環境中。
- 作為發布決策的依據，必須在整個開發工作流程中貫徹執行。
生產可行性標準會根據以下變化而演變：
- 應用程式交付模式。
- 威脅條件。
- 組織風險容忍度。
- 合規要求。
將安全整合進開發工作流程
安全必須直接嵌入開發與交付流程中。 組織應：
- 定義開發工作流程中的安全需求。
- 將安全活動整合至：
- 設計流程
- 建置管線
- 部署工作流程（CI/CD）
- 實作安全驗證機制，例如：
- 程式碼掃描
- 相依性驗證
- 組態檢查
安全發現必須與生產缺陷同等處理，並納入發布決策。
安全驗證應在交付過程中持續進行，而非僅限於釋放檢查點。
平衡與協調要求
組織必須定義開發、安全與營運需求如何在軟體交付決策中取得平衡。 生產工作負載必須符合以下要求：
- 商業功能。
- 安全韌性。
- 創新的速度。
- 操作可靠性與性能。
組織必須定義共享交付目標與績效指標，以：
- 與開發、安全與營運團隊共同的績效與交付目標對齊。
- 避免被單一領域主導。
- 根據以下因素優先排序結果：
- 組織風險容忍度。
- 監管義務。
- 企業問責。
隨著威脅條件演變、交付模式改變及組織優先事項的轉變，平衡必須調整。
建立共同問責
有效的 DevSecOps 需要開發、安全與營運團隊間的共同擁有權，目標是：
- 對齊生產可行性準則的權責歸屬。
- 跨領域協調交付目標。
- 減少孤島現象及不良摩擦，以免造成安全漏洞、交付延遲及營運不穩定。
套用政策導向的安全防護措施
以政策為導向的護欄應在不造成過度摩擦的情況下執行管控。 護欄應包括：
- 身份與存取要求。
- 配置與合規標準。
- 部署與發行控制項
護欄機制應為：
- 整合到平台基礎架構中（例如登陸區）。
- 嵌入開發/部署工作流程中。
- 在可能的情況下自動執行。
此方法確保安全要求在維持交付速度的同時，持續執行。
為了平衡安全性與創新速度，建議檢視採用政策 驅動的防護措施。
持續與改進
安全措施無法維持靜態控制的有效性，必須隨時間演進。
組織必須持續評估並更新開發安全實務，以因應以下變化：
- 威脅條件與攻擊者行為。
- 應用程式架構與交付模式。
- 監管義務。
- 組織風險容忍度。
- 生產可行性標準。
- 開發交付流程。
- 安全治理實務。
安全實務必須隨著所保護系統而演進。
對齊技術
團隊必須保持一致：
- 定義共同目標：開發、安全與營運領導者應協同制定交付目標與工作負載交付的績效指標，以支持一致的發佈規劃。
- 防止單一領域決策主導：交付決策應考量開發、安全及營運需求，以避免可能影響工作負載可靠性、合規性或業務功能的不平衡。
- 優先考量持續改進而非靜態發佈標準：隨著應用程式交付模式、威脅條件及組織優先事項的演變，開發安全實務應持續迭代優化。
-
建立利害關係人角色間的共享交付情境：開發、安全與營運團隊應維持以下共識：
- 業務緊急性與交貨時程
- 相關威脅條件與風險暴露
- 作戰可用性與支援需求
- 監控安全需求所帶來的交付摩擦：安全需求可能會產生交付摩擦。 領導者應評估這種摩擦是否有助於降低風險（例如，透過更早識別弱點）或不必要地延遲工作負載交付，卻無法實質提升生產韌性。
- 將開發安全納入規劃與資源分配：應用工作負載的安全需求應與功能及營運支援需求一併納入開發規劃與資源分配中。
- 定義共享交付績效目標：應用程式工作負載的績效與成功指標應反映開發、安全性及營運交付成果。
將工作流程與安全需求對齊
安全性必須透過開發工作流程來實現。 組織必須定義並協調以下工作流程：
- 建築設計活動。
- 建置與部署流程。
- 問題追蹤與修復工作流程。
安全性發現項目必須符合下列條件：
- 優先排序並追蹤。
- 與生產缺陷一併管理。
- 納入釋放準備決策中。
工作流程對齊確保安全需求在交付過程中持續執行。
下一步
學習 使用零信任原則開發