敏捷環境中的DevSecOps

乍一看，DevSecOps和敏捷似乎是不同的東西。實際上，這些方法論通常是相輔相成的。讓我們一起看看為什麼。

敏捷是一種方法論，旨在為團隊在軟體開發過程中提供靈活性。

DevSecOps則是在現有的自動化軟體開發過程中加入自動化安全防範。這兩種方法論都要求不同的利益相關者之間進行高水平的溝通，並將持續改進作為流程的一部分。

但是，DevSecOps究竟是如何在敏捷環境中工作的呢？為什麼敏捷中的DevSecOps很重要？

DevSecOps如何在敏捷環境中工作

要了

解

DevSecOps如何在敏捷環境中工作，我們必須首先理解什麼是敏捷。

敏捷通常是速度概念的同義詞——即快速釋出和頻繁釋出。然而，隨著軟體開發人員的速度越來越快，他們所使用的舊防範工具已經無法跟上。防範性成為了一個減速帶，並且經常被繞過，以便快速釋出程式碼。隨著時間的推移，軟體變得很容易發生漏洞，侵權和駭客攻擊。

DevOps是作為一種方法論被開發出來的，它使應用程式開發人員和軟體釋出團隊能夠更有效地協作，從而以更快

的速度交付應用程式。

DevSecOps是DevOps的演進

，其驅動力是在自動化的

DevOps流程中增加自動化的安全。

儘管存在

差異，但敏捷和

DevSecOps可以被視為是相互補充的，因為它們都試圖實現相同的目標：速度。

將防範作為敏捷工作流程的核心功能進行提升

DevSecOps的主要目的

是避免拖慢交付管道（pipeline）。然而，結構和構造不良的軟體也有能力減緩交付速度。隨著我們進入一個完全數字化的世界，忽視

DevOps流程中的安全問題會大大降低團隊保持敏捷的能力。

當敏捷過程被遵循但沒有正確實施時，就會出現

“假敏捷”。這意味著，團隊採用了 sprints，、standups、 scrums和burndown charts等敏捷開發的形式，但所生產的軟體是以一種草率的方式完成的。在不理解如何正確實施軟體以避免破壞現有應用，而一味追求快速部署的組織中普遍存在假敏捷。

敏捷宣言的一個關鍵

價值是優先考慮

“工作

軟體而不是全面檔案

”。然而，這意味著軟體不僅僅是簡單地執行它所需要的功能。正常工作的軟體涉及軟體有效和安全工作所需的一切。這意味著要考慮到的不僅僅是核心程式碼的特點和功能，還需要包括其他層面，如基礎架構和圍繞它的安全防範性。

對於團隊和軟體來說，要做到真正的敏捷，他們需要將DevSecOps納入其工作流程。

管道（pipeline）中的自動化防範功能：敏捷工作流程的一部分

自動化是DevSecOps的一個寶貴功能，這是因為它能夠對不斷髮展中的運維和安全防範評估實現持續整合、持續部署和擴充套件。

在設計和理念上，DevOps強調透過自動化部署強調了速度。

DevSecOps則

更進一步，將安全防範協議、檢查和測試自動化，以確保軟體是

“世界通用的”，而不僅僅是在一個樣本中。

當DevSecOps的開發週期成為敏捷衝刺的一部分時，他們可以確保所交付的軟體保持穩健，並針對潛在的漏洞進行更新。

敏捷也不僅僅是交付特性和軟體的能力。它包括對來自任何來源的變化作出反應的能力，這涵蓋了市場規律，惡意行為者和網路攻擊等範疇。

根據

IBM的《2021年資料洩露成本報告》，單次資料洩露產生的平均成本從386萬美元上升到424萬美元，增長了近10%。DevSecOps是透過零信任等各種方法防止網路犯罪和惡意資料劫持的措施。IBM的報告稱

，與沒有采用這種方法的組織相比，採用零信任方法的組織的漏洞成本減少了

176萬美元。此外，那些擁有成熟的DevSecOps流程的企業也能夠比沒有的企業平均快77天遏制漏洞。

有

了DevSecOps，安全防範在開發過程中就被內建到應用程式，從而更容易識別和解決漏洞。這確保了當軟體及其功能被交付時，它們能保持功能質量的基線水平。

敏捷設計的目的是，

通

過

使開發人員能夠建立

提供更好產品和服務

的軟體，

幫助組織

實現利潤最大化。

然而，一個

應用

程式

被

破壞

可能會導致收入損失、客戶信任度降低、增長減少和市場份額縮減。

此外，一個漏洞需要轉移資源來解決漏洞，並確保軟體在結構上符合

防範

需求。

總結：DevSecOps和敏捷可以共存

速度和防範

可以共存，尤其是在DevSecOps和敏捷的環境中。敏捷並不意味著你的團隊需要犧牲防範性，DevSecOps也不意味著你必須犧牲速度。

DevSecOps很重要，因為當與敏捷一起正確實施時，速度和防範性都可以大規模地實現。只有當交付的軟體能夠以最小的代價來適應變化時，才能實現敏捷。將開發人員、質量保證測試人員、安全防範專家和運維人員整合到一個DevSecOps 團隊中，可以構建一個有凝聚力的軟體，包含更少的錯誤，更好的模組化和自動化。反過來，這也減少了任何更改自然帶來的軟體結構和架構阻力。

文章來

源：

https：//bit。ly/3GMCFdB