不要讓這5個誤區降低企業採用DevSecOps效率

當前，DevOps尚未成為DevSecOps，因此DevOps不安全，很多人都在討論它，但很少有企業真正掌握它。那麼，是什麼導致的DevSecOps採用率如此之低?

關於DevSecOps，總結來看，人們認知中的這5個誤區，對採用DevSecOps並實施存在一定阻礙。

誤區一：DevSecOps是由文化促成的。

人們通常認為DevSecOps是由文化促成的，但事實上，DevSecOps 是基於技術並由技術支援的，文化隨之而來。那些將文化放在首位的企業往往會失敗，因為在施行過程中需要有一定的AppSec基礎。一些企業組織了DevSecOps團隊，用DevOps採用的方法培訓他們，高呼持續、快速的安全釋出的口號，但最終一無所獲。

如果缺少安全技術支援，就不可能有DevSecOps文化。如果企業還在做手動安全程式碼審查，肯定無法建立DevSecOps的速度文化。如果只有手動滲透測試則無法大規模構建安全文化。如果你沒有諸如 靜態應用程式安全測試、動態應用程式安全測試、軟體組成分析和web應用程式防火牆等技術，你就不會構建一個包含多個日常安全測試的文化。

技術是文化的基礎。DevSecOps 是一種技術現象。所以，確保用正確的技術來領導公司，公司文化也會隨之改變。

誤區2：任何AppSec技術都可以與DevOps一起使用，使其成為DevSecOps。

這個誤區導致DevOps專業人員選擇了錯誤的AppSec技術，建立在前DevSecOps時代的“傳統”AppSec技術，來將DevOps轉變為DevSecOps。正是這種錯誤的操作，往往會導致結果令人失望。

事實上，只有專門設計的AppSec技術才能實現DevSecOps。傳統的AppSec 技術並未涵蓋成功執行DevSecOps所需的整個軟體生命週期 (SLC)。大多數AppSec檢查只在應用程式部署之前執行，偶爾也會在部署之後執行，這並不適合DevSecOps。這些傳統技術需要專門的AppSec人工操作，包括安裝、配置和操作。

另一個問題是，傳統AppSec技術的執行速度比DevOps慢得多，需要數小時甚至數天的時間進行測試，而DevOps釋出程式碼單位只需幾秒或幾分鐘此外，傳統的AppSec技術尚未構建為原生測試 API、單頁應用程式和微服務。

所有這些考慮使得選擇正確的、特別設計的AppSec技術來支援DevSecOps變得非常重要。

誤區3：DevSecOps等於自動化。

人們認為沿著SLC的AppSec呼叫和執行必須是自動化的，因此AppSec技術將自動沿著持續整合/持續交付(CI/CD)過程執行，而沒有AppSec自動化，DevSecOps是不可能的。事實上，自動化是必要的，但並非對所有AppSec技術都是必要的。

在CI/CD過程中自動化傳統AppSec的整合應該是一個低(更)優先順序，因為如前所述，它們很少被使用。自動化的主要主題應該是那些能夠真正實現DevSecOps並在開發人員和操作專家手中有用的專門設計的技術。有了這些技術，應用程式的安全性測試一天可以進行十幾次，在整個SLC中可以進行數百次。

誤解4：DevSecOps等於向左轉移。

向左轉移已經成為大眾認知，但這並不絕對。AppSec技術確實應該向左轉移，開發人員應更多關注編碼規範和安全，如靜態程式碼分析。但它們也應該向右和中間移動，構建工程師需要CI/CD管道中間的安全性，而操作專業人員需要右側的安全性。

誤解 5：DevOps專業人員歡迎應用程式安全。

DevOps的首要任務是在預算內按時交付應用程式功能。下一個優先事項：確保質量和效能。安全是DevOps遙不可及的目標。由於AppSec技術很複雜，DevOps專業人員沒有時間、技能或意願來採用和操作AppSec技術，而這些努力使他們偏離了他們最初的目標。

DevOps的新AppSec應該是與應用程式架構無關的:它應該自動測試任何應用程式架構，無論是單頁應用程式還是多頁應用程式，微服務還是API。它應該被有意地構建為原生雲和原生社群。AppSec不應該需要進行大量的入門和配置工作，也不應該需要定製登入/憑據處理程式或任何其他繁重的人工操作。它應該覆蓋整個SLC。它應該能夠測試任何業務增量，而不僅僅是特定的URL或IP地址。

隨著對DevSecOps各部分測試工具的逐漸完善和更新，新的技術正在進入市場，留意這些新的技術和工具，可以幫助企業將DevOps轉變為DevSecOps。

參讀連結：

https://www.whitehatsec.com/blog/dont-let-these-five-myths-hinder-your-devsecops-adoption/