套用持續安全性開發生命週期 （持續 SDL） 方法
創新是數位時代組織的生命線，必須同時啟用和保護。 創新安全性可保護創新流程和資料不受網路攻擊。 數字時代的創新採用使用DevOps或 DevSecOps 方法來開發應用程式的形式。 這種方法可讓組織快速創新，而不需要等待在發行之間需要數月或數年的傳統瀑布船排程。
成功的功能和應用程式符合三種不同的需求類型：
- 功能 （開發）：您的應用程式必須符合商務和使用者需求，這些需求通常會快速演進。
- 安全（秒）：您的應用程式必須能夠從快速演變的攻擊者中復原攻擊，並利用安全性防禦的創新。
- 可靠 （Ops）：您的應用程式必須可靠且有效率地執行。
將這三個需求合併在一起並建立共用文化非常重要，但通常具有挑戰性。 開發領導者、IT 和安全性小組必須共同努力，推動這項變更。
觀看下列影片，以深入瞭解DevSecOps方法，以取得安全且快速的創新。
在整個開發生命週期中整合安全性
在開發生命週期中整合安全性非常重要，以便儘早找出並更正設計、程式代碼和其他問題，同時人員正在處理該程式的該部分。 此方法可避免稍後更昂貴且難以修正，這可能會導致大量重新作業。
安全性風險（以及降低風險的需求）可以在開發生命週期的任何時間點發生：
- 設計 – 確保設計不會自然允許攻擊者輕鬆存取組織中的工作負載、其數據或其他商務資產。
- 程式代碼 – 確保撰寫（並重複使用）程式代碼不允許攻擊者輕鬆控制應用程式，以執行損害客戶、員工、系統、數據或其他商務資產的未經授權動作。 開發人員也應該在不允許攻擊者在不知情的情況下控制的安全環境中工作。
- 建置和部署 – 確保持續整合和持續部署 （CI/CD） 程式不允許未經授權的使用者改變程式代碼，並允許攻擊者入侵程序代碼。
- 執行 – 確保執行程式代碼的環境（雲端、伺服器、行動裝置、其他人）遵循跨人員、程式和技術的安全性最佳做法，以避免攻擊者危害和濫用工作負載。 此程式包括採用已建立完善的最佳做法、安全性基準設定等等。
- 零信任 架構與治理 – 所有這些階段都應該遵循 零信任 原則來假設入侵（假設遭到入侵）、明確驗證信任，並授與每個使用者帳戶、計算機/服務身分識別和應用程式元件所需的最低許可權。
什麼是 DevSecOps？
技術創新經常在快速、精簡且敏捷的開發方法環境中開發，將開發和作業結合在DevOps 程式中，並將安全性整合到該程式，對於降低創新程式、組織成長和組織中現有資產的風險至關重要。 將安全性整合到程式中會 建立DevSecOps 程式。
依設計保護並向左移
當組織採用 DevOps 和其他快速創新方法時，安全性必須是整個組織及其開發程式所編織的線程。 在程式後期整合安全性是昂貴且難以修正的。
將安全性 移入 時程表中，以將其整合到服務和產品的設想、設計、實作和作業中。 隨著開發小組轉向 DevOps 並採用雲端技術，安全性必須是該轉換的一部分。
在瀑布模型中，安全性傳統上是 開發完成後的品質網關 。
DevOps 擴充了傳統的開發模型（人員、流程和技術），以包含營運小組。 這項變更減少了開發與營運小組分開所產生的摩擦。 同樣地， DevSecOps 會擴充 DevOps ，以減少個別或不同安全性小組的摩擦。
DevSecOps 是將安全性整合到 DevOps 生命週期的每個階段，從概念開始到構想、架構設計、反覆的應用程式開發和作業。 Teams 必須同時符合創新速度、可靠性和安全性復原能力的目標。 團隊在相互瞭解和相互尊重彼此的需求下，先處理最重要的問題，無論來源為何。
雲端採用架構 的組織方法提供組織中 DevSecOps 結構的進一步內容。 如需詳細資訊，請參閱 瞭解應用程式安全性和 DevSecOps 函式。
為什麼 DevSecOps？
DevOps 帶來靈活度，DevSecOps 帶來安全靈活度。
地球上幾乎每個組織都希望軟體開發透過創新獲得競爭優勢。 保護DevOps程式對於組織的成功至關重要。 攻擊者已注意到此移轉至自定義應用程式，並在攻擊期間逐漸攻擊自定義應用程式。 這些新應用程式通常是豐富的寶貴智慧財產權來源，其中包含尚未成為市集中商品的寶貴新想法。
保護這項創新需要組織解決開發程式與裝載應用程式的基礎結構中潛在的安全性弱點和攻擊。 此方法必須同時套用至雲端和內部部署資源。
攻擊者可以藉由利用開發程式、工作負載的基礎結構或兩者中的弱點來達成其目標：
- 使用應用程式設計和開發程式中的弱點進行開發攻擊 。 例如，攻擊者可能會找到未驗證輸入的程式代碼（允許 SQL 插入式攻擊等常見攻擊），或者他們可能會發現應用程式使用弱式加密（或沒有加密）進行通訊。 此外，攻擊者可能會在程式碼中植入後門，以便稍後返回，以存取您環境中或客戶環境中的資產。
- 基礎結構攻擊 會危害開發程式裝載於使用標準攻擊的端點和基礎結構元素。 攻擊者也可能進行多階段攻擊，其會使用遭竊的認證或惡意代碼，從環境的其他部分存取開發基礎結構。
此外，軟體供應鏈攻擊的風險使得將安全性整合到您的程式中非常重要：
- 保護您的組織 免於原始程式碼供應鏈中的惡意代碼和弱點
- 保護您的客戶 免於應用程式與系統中的任何安全性問題，這可能會導致信譽損害、責任或其他對貴組織的負面影響
DevSecOps 旅程圖
大部分的組織發現任何指定工作負載或應用程式的DevOps或DevSecOps實際上是兩個階段的程式。 想法首先孵化在安全的空間，後來被釋放到生產作為最低可行產品（MVP）。 然後，它們會反覆且持續更新。
下圖顯示這種創新工廠方法的生命週期：
安全創新是這兩個階段的整合式方法：
- 建立、驗證和準備初始生產用途之初始想法的構想孵化 。 此階段從新的想法開始，並在第一個生產版本符合最低可行產品 （MVP） 準則時結束：
- 開發： 功能符合最低商務需求
- 安全性： 功能符合生產環境使用的法規合規性、安全性和安全性需求
- 作業： 功能符合生產系統的最低品質、效能和支援性需求
- DevOps： 此階段是應用程式或工作負載的持續反覆開發程式，可持續創新和改進
領導命令性：混合文化
符合這三項需求需要合併這三種文化，以確保所有小組成員都重視所有類型的需求，並共同達成共同目標。
將這些文化特性和目標整合到真正的 DevSecOps 方法可能具有挑戰性，但值得投資。 許多組織在開發、IT 作業和安全性小組中遇到高度狀況不良的摩擦，這些小組會獨立工作，併產生問題：
- 低價值傳遞和低靈活度
- 品質和效能問題
- 安全性問題
雖然有一些問題是正常且預期的新開發，但小組之間的衝突通常會大幅增加這些問題的數量和嚴重性。 衝突經常發生，通常是因為一或兩個團隊具有政治優勢，並反覆覆寫其他團隊的需求。 隨著時間的推移，被忽視的問題在數量和嚴重性上增長。 未解決，隨著決策的速度增加以符合業務需求和客戶喜好設定的快速演進，此動態可能會讓 DevOps 變得更糟。
解決這些問題需要建立共同的文化特性，以重視領導支持的開發、秒和作業需求。 此方法可讓小組更妥善地合作，並協助解決任何特定短期衝刺最緊迫的問題，無論是改善安全性、作業穩定性，還是新增重要的商務功能。
領導技術
這些關鍵技術可協助領導建立共用文化：
- 沒有人贏得所有論點： 領導人必須確保沒有任何一種心態主導所有可能導致對業務造成負面影響的不平衡的決定。
- 預期持續改善，而不是完美： 領導者應設定持續改善和持續學習的期望。 建置成功的DevSecOps計劃不會在一夜之間發生。 這是一個持續的旅程，漸進式進展。
- 同時慶祝共同利益和獨特的個人價值觀： 確保小組可以看到他們正努力取得共同的結果，而每個個人都提供其他人無法提供的東西。 所有需求類型都與建立和保護相同的商業價值有關。 開發正嘗試建立新的價值，而作業和安全性正嘗試針對不同的風險案例保護及保留該值。 整個組織各級領導人應該傳達這種共通性，以及滿足各種需求，以達到立即和長期成功的需求有多重要。
- 開發共用瞭解： 小組中的每個人都應該對下列專案有基本的瞭解：
- 業務緊迫性： 團隊應該清楚了解風險收益。 此檢視應包含目前的營收（如果服務已離線），以及未來可能受到應用程式與功能傳遞延遲影響的收入。 此檢視應直接以領導項目關係人發出訊號為基礎。
- 可能的風險和威脅： 根據威脅情報小組的輸入，如果存在，小組應該建立應用程序組合將面對的可能威脅感。
- 可用性需求： 小組應具備共同的作業需求，例如所需的運行時間、預期的應用程式存留期，以及疑難解答和維護需求，例如，在在線服務時進行修補。
- 示範和建立所需行為的模型： 領導者應該公開建立他們想要從小組的行為模型。 例如，顯示謙遜，專注於學習並重視其他專業領域。 另一個範例是開發經理討論安全性和高品質應用程式的價值，或安全性管理員討論快速創新和應用程式效能的價值。
- 監視安全性摩擦層級： 安全性自然會產生降低程式的摩擦。 領導者必須監視安全性所產生的層級和類型摩擦：
- 健康摩擦： 類似於運動如何使肌肉更強壯，整合DevOps程式中正確的安全性摩擦水準，藉由在正確的時間強制批評思維來強化應用程式。 例如，如果小組正在學習和使用這些學習來改善安全性，例如，考慮攻擊者嘗試入侵應用程式的原因和方式，以及尋找並修正重要的安全性錯誤，則他們正在追蹤中。
- 狀況不良的摩擦： 尋找阻礙比保護更多價值的摩擦。 當工具所產生的安全性錯誤具有高誤判率或誤報時，或修正問題的安全性工作超過攻擊的潛在影響時，通常會發生這種摩擦。
- 將安全性整合到預算規劃中： 確定安全性預算會按比例配置給安全性的其他投資。 這個概念類似於像音樂會的實體事件，其中事件預算包括實體安全性作為常態。 有些組織會將安全性總成本的 10% 配置為一般規則，以確保安全性最佳做法的一致應用。
- 建立共用目標： 確保應用程式工作負載的效能和成功計量反映開發、安全性和作業目標。
注意
在理想情況下，這些小組應該共同建立這些共用目標，以最大化整個組織或特定專案或應用程式的購買。
識別DevSecOps MVP
從概念轉換到生產期間，請務必確保功能符合每個需求類型的最低需求或最低可行產品 （MVP）：
- 開發人員 （dev） 著重於代表快速傳遞功能所需的商務需求，以滿足使用者、客戶和業務領導者的期望。 識別最低需求，以確保此功能有助於讓組織成功。
- 安全性 （sec） 著重於履行合規性義務，並防範不斷從組織資源中尋求非法收益的攻擊者。 識別符合法規合規性需求的最低需求、維持安全性狀態，並確保安全性作業可以快速偵測並回應主動式攻擊。
- 作業 （ops） 著重於效能、品質和效率，確保工作負載能夠長期持續提供價值。 找出最低需求，以確保工作負載可以在可預見的未來執行和支援，而不需要進行大規模的架構或設計變更。
MVP 的定義可能會隨著時間而改變，而且有不同的工作負載類型，因為小組會從自己的經驗和其他組織共同學習。
在程式中以原生方式整合安全性
安全性需求必須著重於原生整合與現有程式和工具。 例如：
- 威脅模型化之類的設計活動應該整合到設計階段
- 安全性掃描工具應整合至持續整合和持續傳遞 （CI/CD） 系統，例如 Azure DevOps、GitHub 和 Jenkins
- 安全性問題應該使用與其他 Bug 相同的 Bug 追蹤系統和進程來回報，例如優先順序配置。
當小組學習和程式成熟時，應持續改善安全性整合到程式中的方式。 安全性檢閱和風險評估應確保風險降低已整合到端對端開發程序、最終生產服務和基礎結構中。
如需DevSecOps的詳細資訊，請參閱 DevSecOps技術控件。
流覽旅程的秘訣
轉換需要在旅程中以累加方式建置至這個理想狀態。 許多組織都必須在此旅程中瀏覽複雜度和挑戰。 本節概述組織面臨的一些常見概念。
- 教育和文化的變化是關鍵性的早期步驟：你去與你擁有的軍隊作戰。 您擁有的團隊通常需要開發新的技能，並採用新的觀點來瞭解DevSecOps模型的其他部分。 這種教育和文化變更需要時間、專注、主管贊助和定期跟進，以協助個人充分瞭解和瞭解變更的價值。 大幅改變文化和技能有時可以挖掘個人的專業身份，創造強大的抵抗潛力。 請務必瞭解和表達每個人及其情況的變化原因、原因、內容和方式。
- 變更需要時間： 您只能像小組能適應以新方式做事的影響一樣快速移動。 Teams 在轉換時一律必須執行現有的工作。 請務必仔細設定最重要的優先順序，並管理這項變更發生速度的預期。 專注於搜耙、步行、執行策略，其中最重要的和基礎元素先行，將為您的組織服務。
- 有限的資源： 組織通常很早面對的挑戰是尋找安全性和應用程式開發方面的人才和技能。 當組織開始更有效率地共同作業時，他們可能會發現隱藏的人才，例如具有安全性思維的開發人員，或具有開發背景的安全性專業人員。
- 應用程式、程式代碼和基礎結構的本質轉移： 隨著無伺服器、雲端服務、雲端 API 和無程式代碼應用程式等技術的引進，應用程式的技術定義和組合從根本上改變。 這種轉變正在改變開發做法、應用程式安全性，甚至讓非開發人員能夠建立應用程式。
注意
某些實作會將作業和安全性責任結合為 月臺可靠性工程師 （SRE） 角色。
雖然將這些責任混為單一角色可能是某些組織的理想端狀態，但這通常是與目前企業做法、文化、工具和技能集的極端變化。
即使您的目標是 SRE 模型，建議您從使用本指南中所述的實際快速勝利和累加式進度，將安全性內嵌至 DevOps 開始，以確保您獲得良好的投資報酬率（ROI），並滿足立即需求。 這會累加地將安全性責任新增至您的作業和開發人員，讓您的人員更接近 SRE 的結束狀態（如果您的組織稍後計劃採用該模型）。
下一步
如需DevSecOps的詳細指引，請檢閱DevSecOps技術控件。
如需 GitHub 進階安全性如何將安全性整合到持續整合和持續傳遞 （CI/CD） 管線的資訊，請參閱 關於 GitHub 進階安全性。
如需Microsoft IT 組織如何實作DevSecOps的詳細資訊和工具，請參閱 安全DevOps工具組。