如何將 DevSecOps 引入企業？

2022 年 7 月 5 日
筆記

前言

現如今，大部分企業已經在內部實現了 DevOps 實踐。DevOps 為團隊提供了交付可靠軟體和快速更新的方法論。這種方法讓團隊更專註於品質而不是將時間浪費在運維上。然而，結果是，安全實踐往往被留在交付流水線末端的安全專家手中。然後，由於意外往往出現在交付階段的最後，所以使得特定的安全方法在交付過程中產生了不必要的支出。因此，團隊沒有足夠的時間修復程式碼，並反覆開始相同的流程，最終導致交付成本高且效率低。

隨著大多數公司開始進行數字化轉型，DevSecOps 已經變得越來越重要。隨著這些計劃的實施，公司正在向雲端轉移。這使得本地基礎設施逐漸轉移到公有雲上。雲服務提供商提供了具有成本效益、可擴展、高度可用和可靠的解決方案。然而，這些優勢也伴隨著新的安全挑戰。

DevSecOps 將安全納入 DevOps，作為 SDLC 的一個組成部分，而不是在軟體開發幾近完成後才開始考慮安全問題。它還將安全責任分配給團隊成員，在於安全專家的協作中，團隊可以實現一種「安全即程式碼（Security as code）」的文化，鼓勵將安全與 SDLC 流水線中的其他組件放在同一位置對待。

什麼是 DevSecOps ？

DevSecOps 是全棧式的，橫跨整個 IT棧，包括網路、主機、伺服器、雲、移動端和應用安全。這些層都逐漸被各類軟體替代，因此應用安全成為 DevSecOps 的關注點。DevSecOps 橫跨整個軟體開發生命周期，包括開發和運維。在開發中，安全的重點是識別和預防漏洞，而在運維中，監控和防禦攻擊是主要目標。

那麼團隊可以將 DevSecOps 實踐和工具應用於非 DevOps 項目嗎？答案是肯定的。如果您的團隊目標是以最具成本效益的方式生產高度安全的軟體，那麼 DevSecOps 就是前進的方向。

實行 DevSecOps 的企業已經大受裨益。根據 Gartner 的數據，這些早起採用者的安全測試跟上頻繁的應用程式更新的可能性要高出2.6倍，並且修復漏洞的時間減少了2倍。

藉助 DevSecOps，開發、運維、測試和安全團隊進行合作，並整合資源，以便在開發過程中儘早發現安全問題。開發也不會停滯不前，最終的結果是在更快、更有效的工作流程中創建更安全、更高品質的應用程式。

如果你是一名 IT 安全專業人員， DevSecOps 可以讓你在談判桌上擁有一席之地。你的團隊不再被看作是一個沉重的枷鎖，你們的意見將在開發之初就得到重視，你的組織將把你看作是推動安全集成的牽頭人。

如果你是一名開發人員，你也會從 DevSecOps 中受益良多。因為對軟體的安全性要求是不會消失的，如果只在最後一刻處理安全問題，那麼只會拖累你的進度。安全是當今軟體品質的一個重要組成部分，在開發階段就開始注重軟體安全，你的客戶會為此感謝你。

DevSecOps 的5個要素

1、協作

協作的起點是在整個組織內建立一種安全責任共擔的心態，同時得到領導層的支援。圍繞著一個共同的目標，即在滿足所有安全和合規要求的前提下，儘可能快地開發和發布高品質的產品，從而鞏固合作。

安全團隊從熟悉 DevOps 實踐開始做好自己的工作，並將其整合到安全中。例如，頻繁提供安全功能，並儘可能將安全任務自動化。反過來，開發人員也應該學習安全的最佳實踐，對安全性的要求、風險意識和安全工具等。

2、溝通

開發人員和安全專家之間的溝通差距必須被彌合。安全專家需要用開發人員的術語來闡述控制的必要性和合規的好處。例如，在討論安全風險時，以項目延遲和開發人員計劃外的額外工作為例，將使解決這些風險的重要性深入人心。

開發人員應該清楚地了解他們身上的安全責任，這樣他們就可以完全接受他們在一個更安全和合規的組織中的角色。這些責任包括意識到潛在的安全風險，並在編寫程式碼時牢記安全的最佳實踐。開發人員還應該準備好在整個開發過程中進行漏洞測試，以便在發現漏洞時及時進行修復。

3、自動化

自動化可能是一個成功的 DevSecOps 計劃中最關鍵的組成部分。它可以讓安全措施嵌入到開發過程中，並確保安全不會成為安全團隊的負擔。自動化的安全測試和分析可以集成到整個 CI/CD 流水線中，在不拖累創新和開發工作流程的情況下提供安全的軟體。現在，開發人員和安全團隊都很滿意。

自動化還可以實現有價值的安全控制，如中斷構建。這種安全故障保護機制是基於一個自動化的風險評分系統，當風險超過預先確定的閾值時就會發出警報。然後，所有的構建過程都會被凍結，直到開發人員補救安全問題。一旦安全問題被修復，開發人員可以繼續完成構建並交付應用程式。

4、工具與架構安全

安全的軟體始於安全的 DevOps 環境。保護工具、訪問和架構在任何 DevOps 系統中都是至關重要的。安全團隊應該帶頭選擇和檢查所有系統安全工具的配置，以確保在這些系統被批准廣泛使用前已經配置好合適的功能。

識別和訪問管理應該被認真對待。安全團隊應該控制對 DevOps 架構和數據的訪問許可權，在整個開發流水線中保護憑證的使用。多因素認證（MFA）、最低訪問許可權以及對高級許可權的臨時訪問都是你可以利用的訪問控制策略。此外，CI/CD 流水線應該被隔離，以限制橫向移動，所有不必要的訪問 DevOps 工具的賬戶應該被消除。

有了 DevSecOps，安全和合規性控制被納入基礎設施，以涵蓋所有環境，包括雲。所有工作站和伺服器都要接受定期的安全監控、漏洞掃描和修補程式。可以使用自動化工具來掃描所有程式碼，以確保在檢查程式碼庫時沒有遺漏。另外，所有新的虛擬機和容器都會自動接受正確配置的控制，以幫助抵禦自動重建。集中的存儲系統存放 DevOps 工具和密鑰，所有這些都受到加密和多因素認證（MFA）的保護。

5、測試

歷史上，安全測試是作為產品發布前的最後一步來運行的。理想情況下，測試應該貫穿整個開發過程。Keatron Evans，Infosec Skills Infosec Institute 的作者和顧問，解釋說：「傳統上，應用程式在完成開發後再進行測試，但如果開發人員在自動、持續的基礎上進行測試，會更有效。開發者應該能夠在整個開發過程中進行基本的 OWASP 十大測試，而不是測試一個完全構建完成的應用程式，因為前者將可以解決一半的網路安全問題。」

為了保持安全與發展同步，自動化測試的注入是至關重要的。自動化可以幫助執行簡單的流程，如在程式碼被檢查到程式碼庫之前掃描程式碼的密鑰，以確保密碼沒有被記錄在事件日誌中，以及搜索應用程式的惡意程式碼。

有效的測試方案包括靜態應用安全測試（SAST）、動態應用安全測試（DAST）和不太頻繁但同樣重要的技術，如滲透測試、Red Teaming 和 Threat Modeling。後者可能很有價值，因為它們從黑客的角度接近程式碼，而不破壞生產環境。現在，許多組織通過「Bug 賞金」計劃來激勵進行徹底的測試，獎勵發現潛在的安全問題。

DevSecOps 通過監測關鍵指標來評估測試機制，以衡量在整個開發過程中為了減少風險而進行的優化和安全實踐的有效性。開發人員會收到自我評估的記分表，通過各種相關問題讓他們保持對安全問題負責。例如，攻擊面是否在減少？憑證濫用是否被發現？我們的滲透測試是否顯示出更少的程式碼漏洞？含有密碼的程式碼提交的百分比是多少？