【51CTO.com快譯】DevSecOps是指先在應用程序開發的生命周期中引入安全性，從而盡可能地減少漏洞并使安全性更接近IT和業務目標。

DevSecOps定義

DevSecOps是軟件行業的一種文化轉變，旨在將安全性納入現代應用程序開發和部署所特有的快速發布周期中，也稱為DevOps運動。接受這種左傾心態需要組織彌合開發團隊和安全團隊之間通常存在的鴻溝，以至于許多安全流程都由開發團隊自己進行自動化和處理。

DevSecOps與傳統軟件開發有何不同?

傳統上，主要的軟件開發人員過去每隔幾個月甚至幾年發布一次新版本的應用程序。這為代碼提供了足夠的時間來保證質量和進行安全測試，這些過程由獨立的內部或外部合同的專門團隊執行。

但是，在過去的十年中，公共云、容器和微服務模型的興起，將整體式應用程序分解為獨立運行的較小部分。這種故障還直接影響了軟件的開發方式，導致了滾動發布和敏捷開發實踐，在這些實踐中，新功能和代碼不斷以快速的步伐投入生產。其中許多流程已通過使用新技術和新工具而實現了自動化，從而使公司能夠更快地進行創新并保持競爭優勢。

云，容器和微服務的進步也導致了業界所謂的DevOps文化的出現，開發人員現在可以在不等待單獨的基礎架構團隊為他們完成的情況下配置和擴展所需的基礎架構。現在，所有主要的云提供商都提供了API和配置工具，這些API和配置工具允許使用部署模板將基礎結構配置視為代碼。

盡管DevOps文化為軟件開發帶來了很多創新，但是安全性往往無法跟上代碼的生產和發布的新速度。DevSecOps旨在糾正這一問題，并將安全性測試完全集成到持續集成(CI)和持續交付(CD)管道中，同時也積累了開發團隊所需的知識和技能，以便可以測試和修復結果也可以在內部完成。

構成真正的DevSecOps環境的三個關鍵因素是：

· 安全測試由開發團隊完成。

· 測試期間發現的問題由開發團隊管理。

· 解決這些問題的責任在于開發團隊。

應用程序安全測試公司Veracode的聯合創始人兼首席技術官Chris Wysopal告訴CSO：“最后一個需要花費一些時間，但是我認為那是應用程序安全真正成為DevSecOps的時候，不需要一個單獨的團隊了。”

實現真正的安全/開發集成

根據Wysopal的說法，實現最后一步之所以很困難，是因為開發人員必須建立無需外部指導即可修復與安全相關的bug所需的技能，而這需要時間。許多團隊通過在開發團隊中嵌入所謂的安全冠軍來達到目標​​。這是一個在應用程序安全方面具有專業知識的人，并且比整個團隊中的大多數人接受了更高級的培訓，即使對整個團隊進行安全編程實踐的培訓也應該是過程的一部分。此人可以查看安全修補程序，以確保它們是正確的。

這并不意味著安全擁護者不能在團隊之外尋求專家意見。例如：向該公司的應用程序安全測試提供商提供服務，后者可能會為客戶提供咨詢服務。在特殊情況下，這不是正常的情況。這與擁有獨立的開發和安全團隊，以及將一個或多個安全團隊成員嵌入開發團隊不同。

根據DevOps自動化和開源治理公司Sonatype的CTO Brian Fox的說法，開發和安全性之間的集成也需要在管理層進行。Fox告訴CSO：“當安全任務與完全集成到開發中而不完全融合時，我認為您沒有得到正確的選擇。有時候，即使人們在同一個團隊中工作，您也會遇到目標不同的管理層沖突。這是許多組織中發生的事情的一個要素。”

Fox表示，這是在質量檢查之前發生的，那里曾經有一個質量檢查經理和工程經理，他們在一起工作，但是總有一些部落主義在進行。“一旦這種情況消失了，質量保證已成為開發團隊人員所做工作的一部分，您就不再看到我們與他們的心態，而我們在安全性方面還沒有到位。我認為這就是很多公司掙扎。”

DevSecOps測試和工具

硅谷科技公司在早期采用DevSecOps方面處于領先地位，但是當時可用的安全測試工具對開發人員并不友好。開發人員需要命令行工具，這些工具可以自動化，以便他們可以輕松地調整各種配置，并且可以輕松地將其輸出導入錯誤跟蹤器。而傳統的安全掃描程序在設計時就考慮了安全團隊和CISO，其目標是治理、安全性、政策合規和風險管理。

慢慢地出現了由開發人員為開發人員創建的新工具，這些新工具已集成到開發環境和CI / CD工作流程中。有些是開源的，有些是圍繞它們構建的啟動業務模型，但是當它們解決了開發人員的需求時，他們并沒有真正滿足CISO的需求。

如果使用了許多不同的開放源代碼工具，則開發團隊可能會覺得他們正在涵蓋他們認為需要涵蓋的內容。Wysopal說，從治理的角度來看，安全團隊很難將所有這些不同的分散工具映射到公司的策略。

在過去的兩年中，傳統的應用程序安全供應商已更改其產品，以解決這兩種用例：提供CISO所需的分析和報告，并具有開發人員期望的靈活性和易用性。一些針對諸如GitHub之類的開發人員的基于云的服務提供商已開始直接在其服務中添加安全性測試。當它不能作為本機功能使用時，通常可以作為第三方供應商的集成在服務市場中使用。

“在過去的兩年中，我們看到了事情的搖擺朝著無所不包的單一套件的方向發展。” Fox警告說，當下一個顛覆性技術問世時，這種整合將在某個時候逆轉，企業需要為此做好準備。套件的問題在于，它們可以在組織需要的一項或多項事情上表現出色，但隨后包含了其他可用的功能，因為它們是隨包免費提供的。隨著時間的流逝，這可能導致組織內部的開發人員群體破裂，他們將開始測試和使用比公司認可的套件更好地滿足其需求的其他工具。

從治理的角度來看，擁有不受管理的團隊是不好的，但是公司需要意識到，從現在起的一兩年內，這種情況將不可避免地發生，盡管嘗試限制工具的使用，但總會有一些開發人員來做自己的事情。“最早采用云技術的人有時是規模更大的組織中的個人團隊，他們在反駁購買計算機所需的時間。” Fox說到。

DevSecOps的采用

根據Wysopal的說法，越來越多的公司正在將自動化安全掃描集成為CI / CD管道的一部分，但是由于他所說的“安全債務”(即導致生產中存在的漏洞數量)，結果可能不會立即顯現。因為開發人員選擇不修復它們。

發生這種情況的原因可能多種多樣，包括無法立即對其進行修復，由于存在其他緩解措施而沒有計劃對其進行修復，或者由于它們的嚴重性較低而沒有對其進行修復。

Veracode 發布的2019年軟件安全狀態報告中，基于一年中，其對85,000個應用程序執行的掃描收集的數據結果顯示，應用程序中發現漏洞的平均修復時間為171天，而平均時間為59天。但是，這會因應計的安全債務而歪曲，并且修復的平均時間實際上保持不變。

將掃描結果與特定應用程序的掃描頻率相關聯時，頻率增加表明CI / CD工作流程中集成了自動掃描。數據顯示，每天掃描的應用程序的中位時間為19天，而68天為對于每月掃描的應用程序。這表明掃描頻率越高，修補漏洞的可能性就越大。

該公司在報告中總結道：“與金融債務一樣，要擺脫擔保債務，必然需要改變習慣以償還余額。過去幾年中，軟件開發和IT運營(DevOps)的集成以及安全性在這些流程中的集成(通常稱為DevSecOps)無疑已經改變了習慣。”

向DevSecOps進行真正的文化更改的另一個好處是，代碼中存在的嚴重漏洞的數量也應該減少。Veracode的數據顯示，與10年前相比，沒有漏洞的應用程序的總體百分比實際上有所下降，這表明情況已經惡化，但是沒有高嚴重漏洞的應用程序的百分比實際上已經從66%增加到80%。

福克斯說：“我看到許多組織仍在為這種模式而苦苦掙扎。” “他們正在朝著這個持續的開發環境邁進，他們擁有基礎架構和CI，并且正在使用容器。然后，他們有一個應用程序安全團隊，他們將在以后運行掃描，生成報告，有時甚至是紙質打印報告-并將它們帶入開發中，而不是利用能夠授權開發的工具來避免這些錯誤。我看到的大多數組織仍然屬于我們，他們，開發人員或安全性方面。”

也就是說，即使使用DevSecOps，安全專家也仍然需要執行某些任務，而手動測試仍然可以發揮作用。例如：使用全自動掃描很難發現邏輯缺陷或設計缺陷。

Wysopal說：“我們開始看到的是，手動測試不是一年一次或每年兩次。“它具有更大的迭代性。它是在DevOps流程中進行更多工作的，其中可能需要進行為期兩周的沖刺，而他們正在執行一項新功能，該功能具有安全性，因為為此進行的少量手動測試如果安全支持者對手動測試有足夠的了解，并且可以滿足開發團隊自己進行的目標，那么有時他們可以做到。

原文地址：https://www.csoonline.com/article/3245748/what-is-devsecops-developing-more-secure-applications.html

作者：Lucian Constantin

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】