當你創建或現代化開發 安全領域時，本文說明如何將安全整合進開發實務，使開發者操作（DevOps）能從開發者操作（DevOps）轉向開發者安全操作（DevSecOps），並協助確保應用程式交付的安全。
現代組織依賴快速的軟體開發來推動創新、回應不斷變化的商業需求，並維持競爭優勢。 DevOps 透過持續整合與交付，實現這種敏捷性。 然而，速度提升也帶來新的安全風險。
持續發布週期縮短設計決策與生產部署之間的時間，增加弱點被引入生產環境的可能性，包括：
- 應用程式設計的弱點
- 有漏洞的相依性
- 設定錯誤
- 基礎設施自動化缺陷
- 秘密管理或衛生不佳。
DevOps 風險
現代 DevOps 環境擴大了攻擊面，涵蓋開發、管線與生產系統。 DevOps 工具如原始碼庫、管線與自動化系統，是攻擊者的高價值目標。
若惡意程式碼早期引入，可能會通過現有的安全檢查，進入生產系統。
常見攻擊目標包括：
- 將惡意程式碼注入建置產物中。
- 開發者身份或服務帳號被破壞。
- 存取或外洩生產資料。
攻擊者經常針對自訂應用程式和開發環境來取得以下存取權限：
- 敏感的組織或客戶資料。
- 專有商業邏輯與智慧財產權。
- 透過遭入侵的開發系統存取生產環境基礎架構。
- 透過入侵軟體供應鏈影響下游客戶
潛在的安全風險總結如下圖：
應用與開發風險
應用程式工作負載可能因開發過程中的弱點或用於建置與部署的基礎設施受損而受到入侵。
| Risk | 目標 | 潛在結果 |
|---|---|---|
| 應用程式設計/實作 | 設計或開發過程中引入的安全問題可能使工作負載暴露於以下攻擊技術： - 輸入驗證不當 - 不安全的認證或授權邏輯 - 密碼學薄弱或實作不當 - 透過應用程式邏輯揭露敏感資料 |
這些弱點可能讓攻擊者能夠： - 存取或操作應用程式資料 - 執行未經授權的操作 - 透過植入的邏輯缺陷維持持續存取權限。 |
| 開發基礎架構/自動化 | 攻擊可能針對： - 原始碼儲存庫 - 建置管線 - 部署自動化 - 基礎設施即程式碼（IaC）範本 - 開發端點或服務識別碼 |
妥協可能讓攻擊者： - 將惡意程式碼插入建置產物中 - 修改部署配置 - 透過植入邏輯缺陷維持持續存取 - 取得生產環境中使用的憑證或機密資料。 |
| 開發軟體供應鏈 | 應用通常依賴： - 第三方函式庫 - 開源套件 - 容器影像 - 平台服務 |
透過這些相依性引入的漏洞或惡意程式碼可能影響： - 組織生產工作負載 - 客戶或合作夥伴環境 |
將安全整合進開發流程，可降低這些風險在生產環境發布中傳播的可能性。
向左移動
「Shift left」是一種安全工程方法，在開發生命週期的較早階段就將安全性納入其中。
組織並非在流程後期驗證安全性，而是將其嵌入：
- 設想
- Design
- 發展
- Operations
這降低了整治成本與風險暴露。
為了支持這種做法，組織應該"
- 在流程早期採用如 安全開發生命週期（SDL ）等結構化的最佳實務，而非在問題變得昂貴且難以修復時晚期使用。
- 為維持此策略，應將治理、風險與合規（GRC）整合進開發策略中。
什麼是 DevSecOps？
DevSecOps 透過擴展 DevOps 並將安全性嵌入軟體開發生命週期的每個階段——從構想到設計、開發到營運——實現了向左移（Shift Left）的理念。
在傳統開發方法中，安全驗證通常作為發布前的最終品質閘門執行。 這造成延遲、修復成本增加，且漏洞可能持續存在至生命週期後期。
DevSecOps 更早將安全措施轉移，並持續嵌入開發與營運流程中。
DevSecOps 減少開發、營運與資安團隊間的摩擦，將團隊圍繞創新速度、可靠性與安全韌性的共同目標對齊，並使團隊能及早且持續地解決最重要的問題。
DevSecOps 將安全整合到：
- 建築設計
- 應用程式實作
- 基礎結構自動化
- 部署與作業流程
Benefits
DevSecOps 使開發、安全與營運團隊能夠：
- 在生命週期早期識別並修復問題。
- 減少生產中的曝光。
- 在管理風險的同時，維持交付速度。
安全性成為軟體建置與交付的一部分，而非交付後的控制。
確保創新生命週期
創新通常會經歷兩個生命週期階段：
| 舞台 | 詳細資料 |
|---|---|
| 想法孵化 | 一項能力是設計、實作並驗證以供初期生產使用。 它從一個新的想法開始 |
| 初始版本 |
首次生產版本符合安全使用產品的最低標準。 - 開發：功能符合最低業務需求。 - 安全性：能力符合法規遵循、安全性及生產使用的安全要求。 - 營運： 功能符合作為生產系統的最低品質、效能與可支援性要求。 |
在初始發布後，隨著工作負載演進，開發變得迭代，並包含：
- 風險容忍度的改變
- 應用需求與成熟度
- 監管義務
- 威脅條件
將安全整合進開發中
傳統的開發方法通常在開發生命週期的後期才驗證安全性，也就是在設計與實作完成後，將其作為發布前的最後一道關卡。 在現代開發環境中，延遲驗證會增加：
- 漏洞複雜度
- 修復成本
- 營運延誤與中斷
- 積極剝削風險增加
DevSecOps 在開發與營運過程中持續整合安全，以及早解決問題、降低風險並提升一致性。
主要實務
安全性必須嵌入現有開發流程中，才能有效、可擴展且永續。 它應該直接整合進應用程式的設計、建置、部署與運作中，而非在獨立或平行的工作流程中實作。 我們建議：
- 從構想到開發、部署到持續營運，繪製端到端的工作流程。
- 明確定義生命週期各階段的安全角色、工具與責任。
- 建立針對漏洞、缺陷及設計問題的一致修復路徑。
根據工作負載風險量身訂做安全實務。 業務關鍵應用需要更高的嚴謹度，而低風險的情境則可採用簡化的方法。
至少，請確保你：
- 識別開發生命週期中涉及的階段、人員與技術。
- 定義安全活動如何整合進每個階段，而非將它們視為獨立的檢查點。
- 建立處理重大變更與例行修復的流程，涵蓋整個生命週期。
將安全自動化進入開發與部署
自動化對於在開發與營運中持續且大規模地執行安全至關重要。
- 將安全控制與工具直接整合進 CI/CD 管線中。
- 自動化關鍵活動，如威脅建模、程式碼掃描、驗證及政策執行。
- 使用基礎設施即程式碼（IaC）來實現可重複且安全的部署。
像 Azure 登陸區這類平台基礎可以支援這種做法，如下：
平台基礎如 Azure landing zones 能透過提供標準化的安全、治理與 DevOps 整合模式來支持此方法。
預期結果
從 DevOps 轉向 DevSecOps 的組織可以：
- 降低漏洞被引入生產工作負載的可能性
- 限制攻擊者利用開發基礎設施或自動化的能力
- 提升應用程式對演進攻擊技術的韌性
- 支援法規與組織合規要求
- 維持創新速度，同時不增加營運或安全風險
導航旅程的建議
採用 DevSecOps 需要組織與文化上的變革。
教育與文化變遷
這些都是關鍵的早期步驟。 你的團隊必須發展新技能並採用新的觀點，才能理解 DevSecOps 模型。
教育與文化變革需要時間、專注、高階主管的支持，以及定期的追蹤，幫助個人充分理解並看到變革的價值。
文化與技能的劇烈轉變有時會觸及個人的專業身份，帶來強烈的抵抗。 理解並表達每個人及其情況中變化的原因、內容與方式至關重要。
改變需要時間
你的推進速度，取決於你的團隊能多快適應以新方式做事所帶來的影響。 團隊必須在轉型的同時完成現有的工作。
謹慎優先排序最重要的事項，並管理對變革可能發生速度的期待至關重要。
專注於「爬行、走路、奔跑」策略，優先考量最重要且基礎的元素，對組織非常有利。
變化會帶來（暫時性的）摩擦
所有新技術、方法論及其他變革都會帶來摩擦與混亂。 關鍵在於專注於健康的摩擦，這種摩擦能推動批判性思考以降低風險，同時避免那些減緩流程、效益有限且風險降低有限的不良摩擦。
資源有限
組織在早期通常面臨的挑戰是尋找資安與應用程式開發的人才與技能。
隨著組織開始更有效協作，可能會發現隱藏人才，例如具備資安思維的開發者或具備開發背景的安全專業人士。
持續變動
應用程式變化迅速。 除了新功能外，隨著雲端、無伺服器及人工智慧等技術的引入，應用程式的技術定義與組成也正發生根本性改變。
這種轉變正在改變開發實務、應用程式安全性，甚至讓非開發者也能創建應用程式。
考慮一個SRE模型
部分 DevSecOps 實作結合營運與安全責任，擔任 現場可靠性工程師（SRE） 角色。
雖然這樣的模式可行，但往往是與現有企業文化和作法的極端轉變。
如果您正在考慮採用SRE模式，我們建議您先將安全整合進DevOps，利用本指南中所述的實用快速勝利與漸進式進展，確保您獲得良好的投資報酬率（ROI）並滿足眼前需求。
這逐步增加營運與開發人員的安全責任，使團隊更接近SRE的最終狀態。
下一步
了解 安全開發的最佳實務。