【51CTO.com快譯】安全過去是最后開發階段某個專門團隊的責任，但隨著開發周期的數量和速度同提升，安全實踐需要與時俱進。

這導致DevSecOps(開發安全運維)大行其道，DevSecOps強調為DevOps融入安全。公司需要DevSecOps來確保項目安全可靠地運作。如果沒有DevSecOps，DevOps團隊需要在發現漏洞后重建和更新所有系統，這費時費力。

[[268973]]

以下是項目負責人開始實施DevSecOps時要考慮的四個關鍵因素：

1. 了解貴公司的安全策略和標準，以便開發時可以明智地選擇安全組件。

適當的安全和審計策略很重要，以便能夠證明生產環境中預期的樣子就是實際運行時的樣子。能夠驗證你在生產環境中運行的軟件不需要將特殊代碼添加到原始代碼，那樣就無需重新測試和維護新代碼。實際上，如果可以在運行時進行這番驗證，并立即報告所有應用程序上運行的組件，那么你的團隊就能獲得一直缺乏的證據和監管：安全、治理和合規證明。

2. 實施靜態、可重現、不可變的構建環境。

如果在整個組織中利用系統化、可重復的構建流程建立構建環境，團隊就能夠減少漏洞，并確保應用程序的質量。實施面向整個組織的流程，以便針對依賴項、許可證和安全來解決開源語言的構建。這將消除浪費在改建上的時間、集成安全機制以及提高靈活性。

受信任、精挑細選的語言發行版可以在整個團隊中帶來這些好處，并構建開源語言的三個生命周期階段：構建、認證和解決。

3. 積極主動。

開發過程中確定許可證合規和漏洞方面要注意的事項，而不是事后再做。了解應用程序中的組件，讓你的所有應用程序組合了解這些組件，并密切跟蹤那些更新，這是繁重的工作。這實際上可以實現自動化，以了解團隊依賴某個組件的情況和與組件有關的風險。

這種方法使團隊能夠將安全目標放在首要的位置，并在自動通知開源組件的更新時保持持續交付。

應掃描所有第三方開源組件以查找許可證合規和漏洞。應用程序的風險在逐漸變化，因此有必要在整個軟件開發生命周期(包括CI/CD流程和進入到生產環境)中密切關注開源軟件包，關注漏洞、有效期和許可。

以前，跨SDLC和生產環境跟蹤安全需要安裝某個持續運行的代理，或者在系統層面使用應用程序掃描工具(AST)，或者在應用程序的代碼里面使用運行時應用程序自保護(RASP)解決方案。

如今，借助解釋器插件進行的無代理監控可以將安全機制直接部署到源代碼中，以便安全團隊能夠跟上開發步伐，并使產品更快地進入市場。這種方法可以更深入地了解合規團隊、InfoSec團隊和風險管理團隊當中的安全。

4. 使用最新版本的組件，組件應盡量來自積極維護的項目。

過時或維護不力的開源軟件會為不法分子提供可趁之機，并破壞關鍵任務型應用程序的穩定性。許多開源軟件包由多個貢獻者創建，可能沒有走嚴格的安全審核流程。此外，即使軟件包過去經過了安全評估，也可能含有未知的新漏洞。而現有的工具和流程檢測不出這些新漏洞。

為了解決這些問題，企業應實施策略以防止使用易受攻擊的軟件包、模塊和庫;為應用程序使用的軟件包維護一份最新的清單;根據可靠的信息來源，定期檢查漏洞。若發現任何軟件包含有漏洞，必須打補丁，并部署新版本。

新的安全機會

在組織內部實施DevSecOps標準并不完全是開發人員的責任。然而，開發期間制定安全標準卻是開發人員的職責。為什么不超越最基本的許可證合規、漏洞檢查和組件檢查，使用可用的工具和流程制定更強大的安全標準?DevSecOps為節省時間、避免沮喪和返工，同時提高安全、縮短投放市場的時間提供了機會。

原文標題：DevSecOps: 4 key considerations for beginners，作者：Bart Copeland

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