為何DevSecOps落地如此艱難？
責編：gltian ｜2020-08-05 14:22:02什么是DevSecOps
DevSecOps是為了讓安全能夠融入現代應用開發和部署的快節奏周期，而進行的一種文化的改變。DevSecOps意味著開發中的安全左移，從而需要縮減開發團隊和安全團隊之間的距離，使得開發團隊自身可以通過自動化的方式處理大量的安全工作。
傳統的軟件開發流程中，大部分開發者都需要數月，甚至數年才會發布新版本的應用。這就有了大量的時間，讓不同的內部和外部團隊，對代碼進行質量檢測和安全測試，但是，隨著過去十年中，公有云、容器和微服務模型的發展，單一的應用被分解成不同的小組件，獨立運作。這對軟件開發的方式帶來了直接的沖擊，形成了滾動發布和敏捷化的開發模式。在這一模式下，新的功能和代碼會持續地快速被投入使用。許多此類流程通過新的技術和工具自動化實現，讓企業能更高速地進行創新，從而在競爭中獲得領先。
云、容器和微服務同樣產生了DevOps文化。開發者可以自己解決對于架構的需求，而不需要另一個分離的架構團隊來幫他們實現。現在所有的主流云供應商都提供相關的API和配置工具，幫助客戶能夠通過預設的模板，用代碼對架構進行配置。
盡管說DevOps文化給軟件開發帶來了很多創新因素，但是安全卻無法跟上代碼的迭代速度。DevSecOps則應運而生，試圖解決這個問題，并將安全測試完全結合進持續集成（continuous integration, CI）與持續交付（continuous delivery, CD）流水線中，同時將相關的知識和技能嵌入開發團隊，從而開發團隊可以內部解決安全隱患。
DevSecOps的三個關鍵要點在于：
- 開發團隊自己完成安全測試
- 測試中發現的問題由開發團隊進行管理
- 開發團隊完成修復工作
應用安全測試公司Veracode的聯合創始人兼CTO，Chris Wysopal表示：“第三個要點會需要一些時間才能實現，但是我認為那才是應用安全真正成為DevSecOps的時候。那樣就不需要另一個不同的團隊去處理安全相關的問題。”
實現真正的安全+開發
在Wysopal看來，第三點的實現難點在于開發者必須在不需要外部幫助的情況下，有修復安全漏洞的能力，而做到這一點需要不少時間。許多團隊通過在開發組中加入一名安全領袖來實現這一點。這個人員往往在應用安全方面有相當多的經驗，并且相比團隊其他成員受到更多的相關訓練。這個人能夠檢查相關的安全修復，并確保他們被正確應用。
不過，這不意味著這位安全領袖不能從團隊外部獲取專家意見。他們依然可以從公司的應用安全測試服務的供應商處獲得咨詢服務。但這應該是特殊情況，而不能成為常態。安全領袖模式不同于安全團隊成員分散在不同開發小組的模式。
DevOps自動化與開源管理公司Sonatype的CTO，Brian Fox則認為，開發和安全的集成也需要從管理層面著手。在他看來，如果安全無法自上而下地完全集成進開發流程中，就無法達到預期的效；即使同一團隊的人也會產生管理層面的目標分歧——有時候盡管兩個人并未有沖突產生，但是他們也相互無視對方，并沒有進行合作。
同樣的問題也曾發生質量檢測（Quality Assurance, QA）中。之前會有一名QA經理和一名工程師經理，理論上他們應該一同合作，但事實上兩者之間總會會有派系斗爭。Fox提到，一當QA成為開發團隊工作的一環的時候，就會發現精神上的敵對關系消失了；而同樣的問題依然出現在安全上，而這需要很多的努力才能去改變。
DevSecOps測試與相關工具
硅谷的科技公司屬于早期就開始采用DevSecOps方法的，但是當時的安全測試工具并不適合開發者使用。開發者希望用一些能夠自動化使用的命令行工具，這樣他們能夠輕松地修改不同的設置，并且能將獲得的結果輸入到漏洞追蹤器中。而在傳統的安全團隊和CISO的理念中，安全的目標是治理、合規和風險管理。
之后逐漸有新的工具開始出現。這些工具都是由開發者自己編寫給其他開發者的，并且集成到了開發環境以及CI/CD工作流中。一些工具是開源的，其他則是由一些初創公司基于這些開源工具進一步改造的。盡管這些工具確實解決了開發者的需求，但是它們卻不再真正意義上解決CISO的需求了。
但是Wysopal又提到，雖然對于開發團隊而言，使用大量不同的開源工具會讓他們覺得他們覆蓋了所有自己的需要面；但從企業治理的角度來看，過多零碎的工具反而會讓安全團隊難以根據公司的策略進行管理。
在過去的數年中，傳統的應用安全廠商開始改造他們的產品以解決以下兩個場景需求：提供CISO需要的分析和報告，同時也提供開發者所需要的靈活些和易用性。一些如GitHub的針對開發者的云服務供應商已經開始將安全測試直接加入他們的服務之中；如果這些安全測試服務不時原生的功能，它們也會以第三方集成的形式在可購買的服務項目中出現。
Fox表示，在他的整個職業生涯中，總是能看到一些反復的規律：用戶總有兩個傾向——一種是需要一個供應商提供完整的工具組，另一種則更愿意自己將不同的工具集成到一起。而在過去兩年中，他認為用戶更傾向于用統一完整的工具組。
Fox同時也提醒，這種需求可能會在某個時間點逆轉——比如在下一個開創性的技術出現的時候，而企業也需要為此做好準備。一個完整的工具組的問題在于，工具組可能有一些組織需求之外的功能；這些功能往往不是因為對企業更有效而存在的，僅僅是因為它們是免費的。在一定時間后，隨著開發者對工具的使用，他們自己會采用更適合自己工作需求的工具，而非企業認可的工具組。
從治理的角度來看，不受管理的團隊必然有負面影響；但是企業必須意識到在未來的一兩年中，這些事情將會無法避免地發生，即使試圖限制工具的使用，還是會有一些開發者會我行我素。
Fox補充認為，早期的云使用者很多是很不情愿使用云服務的大組織中，存在的一些小團隊。因此，如果組織能夠意識到這是不可避免會發生的事情，并不對相關團隊限制過多，可能反而有機會發現一些開創性的前沿技術，甚至能真的替換現有的技術。
DevSecOps實踐
根據Wysopal的說法，越來越多的企業將自動安全掃描集成為CI/CD流水線的一部分，但是效果并不能立竿見影。Wysopal認為這是所謂的“安全債務”，因為之前開發者選擇不修復的漏洞數目角度造成的。“安全債務”產生的原因很多，包括沒有立即修復發現的漏洞；也可能決定不修復，而使用其他方式緩解；還可能因為威脅級別較低而不選擇修復。在Veracode自己的2019年軟件安全報告趨勢當中提到，在基于過去一年對85,000個應用進行掃描獲得的數據中發現，平均修復應用中發現的漏洞時間為171天，而在十年前第一份報告出現的時候才59天。但是，產生這個區別的原因是因為之前囤積了大量沒有修復的漏洞，而修復時間的中位數依然很相近。
當將某個應用的掃描結果和掃描頻率相關聯以后可以發現，增加在CI/CD流水線上集成的自動化掃描頻率，能夠更快修復漏洞：每天被掃描的應用修復漏洞的時間中位數為19天，而每月掃描則為68天。
而從經濟的角度來說，如果需要從安全債務中減少損失，就需要改變一些開發習慣；而DevOps和DevSecOps的實踐過程，也確實地使原有的文化發生了變化。
DevSecOps文化的另一個利好，是在代碼中存在的嚴重漏洞數量也會大幅度減少。Veracode的數據顯示，沒有漏洞的應用比例相比十年前降低了，這似乎看上去比之前更糟糕了；但從另一組數據中則能發現，沒有高危漏洞的應用比例則從66%上升到了80%。
不過，即使DevSecOps的模式存在，依然有很多工作需要安全人員來處理，而且仍然很依賴人工測試——尤其是對于邏輯漏洞以及設計缺陷等無法通過純自動掃描解決的問題。Wysopal表示，人工測試已經逐漸不再是一年，甚至兩年一次的行為。人工測試需要反復進行，最好能作為DevOps流程的一部分，在為期兩周的項目階段中，針對新出的功能進行人工測試。如果開發團隊對人工測試有了足夠的了解，那就可以由安全領袖進行，并且真正滿足開發團隊自己的需求。
來源：數世咨詢