不要讓這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。

。