如何避開IT安全運維的那些“坑”
如今，在DevOps當中建立安全體系顯得比以往任何時候都更加重要�！�2021年企業(yè)DevOps技能提升報告》指出，56%的受訪者表示DevSecOps已經(jīng)成為自動化工具中的一大必備要素。然而，DevSecOps方法不只是簡單添加安全工具與實踐，與任何其他DevOps方法一樣，其中也離不開文化、流程與技術(shù)。
如果不能以戰(zhàn)略性方式在企業(yè)當中實施DevSecOps，則很容易出現(xiàn)安全障礙或問題。在本文中，我們邀請多位行業(yè)專家分享自己的真知灼見，下面來看他們總結(jié)出的八個DevSecOps“大坑”，有望幫助我們從起步階段就回避掉這些潛在陷阱。
陷阱一 急功近利，總想要一蹴而就
“實現(xiàn)目標的關(guān)鍵，在于分多個步驟從小處入手。最好是以試點項目為起點，確定一支負責實施DevSecOps管道與流程的項目兼跨職能團隊，涵蓋應(yīng)用開發(fā)、運營、安全等。此外，還應(yīng)確定目標、使用案例并為迭代工作做好準備。如果團隊運作良好，請記錄實施過程與結(jié)果，并據(jù)此確定商業(yè)價值，例如更快的上市時間或者預(yù)先解決安全問題的能力。”——Kirsten Newcomer，紅帽公司云安全戰(zhàn)略總監(jiān)
陷阱二 將掃描工具添加至CI/CD（持續(xù)集成/持續(xù)交付）管道當中，但卻沒能充分運用掃描結(jié)果
“為了掃描而掃描，往往只會帶來一種虛假的安全感。最重要的應(yīng)該是考慮如何將安全掃描中發(fā)現(xiàn)的問題，切實轉(zhuǎn)化為可操作的補救行動。”——Rob Cuddy，HCL Technologies公司全球應(yīng)用程序安全布道師
陷阱三 避免文化包袱
“團隊在十多年前開始實施DevOps時，首先需要確立的就是文化定位。DevOps從本質(zhì)上強調(diào)的是協(xié)作、同理心與創(chuàng)新。未能正確理解文化的團隊，將很難完成應(yīng)用程序的構(gòu)建、測試、持續(xù)部署與運行。DevSecOps的情況也是一樣，團隊只會有更多的文化包袱需要解決。開發(fā)人員與安全人員長期以來總是關(guān)注著不同的目標，導(dǎo)致雙方產(chǎn)生嚴重分歧。開發(fā)者更關(guān)注產(chǎn)品開發(fā)速度，安全部門則重視如何降低風險。“
“事實是，安全性只是代碼質(zhì)量的另一部分，交付高質(zhì)量代碼符合所有團隊的基本利益。誰能圍繞這一點達成團結(jié)并建立起相應(yīng)文化，誰就會獲得茁壯成長的良好態(tài)勢。而那些專注于戰(zhàn)術(shù)實施、但卻忽略掉文化研究及相關(guān)挑戰(zhàn)的團隊，則一定會身陷困境。”——Joni Klippert，StackHawk公司聯(lián)合創(chuàng)始人兼CEO
陷阱四 不理解工具，投入過快，擾亂既有工程流程
“為了確保更高的成功率，最好緩慢地每次引入一種安全控制，并確保結(jié)果對團隊確有價值。持續(xù)監(jiān)控并改進安全流程，最大程度減少業(yè)務(wù)中斷。其中包括評估結(jié)果、調(diào)節(jié)掃描工具并盡可能減少指向工程團隊的誤報。如果無法完成這種文化轉(zhuǎn)變，則DevSecOps大概率會陷入失敗。”
“左移的意義，是在軟件項目開發(fā)或產(chǎn)品啟動之初，就保證將一切角色和職責清晰簡明地委派給每一位參與者。將DevSecOps和安全帶入人們已經(jīng)熟悉的工作體系當中。把工程師們已經(jīng)在使用的工具與安全流程融合得越好，起步階段就會越簡單。”——Dheeraj Nayal，DevOps研究院全球社區(qū)大使兼亞太、中東與非洲區(qū)域負責人
陷阱五 未能得到高層領(lǐng)導(dǎo)認同
“與DevOps類似，DevSecOps的本質(zhì)并不是團隊或者角色，而是一種文化。不解決文化方面的問題，單是在現(xiàn)有團隊/流程中添加一個安全/DevSecOps工程師角色，并不足以達到與預(yù)期相符的回報。而文化通常源自高層，因此要建立正確的文化體系，必須保證高層領(lǐng)導(dǎo)團隊支持DevSecOps。”——David Slater，Tasktop公司云產(chǎn)品價值流負責人
陷阱六 將自動化安全檢查引入交付管道，但未能考慮到反饋循環(huán)
“在處理較為陳舊的代碼庫時，企業(yè)可能已經(jīng)識別出大量缺陷。但「為每個缺陷創(chuàng)建一個Jira工單」的默認響應(yīng)方式無法解決問題。另一種常見的陷阱則是低估了采取新方法所需要的時間。要使DevSecOps取得成功，必須要讓交付團隊親自參與解決方案構(gòu)建。”——Peter Maddison，Xodiac公司創(chuàng)始人
陷阱七 對安全集成不加反思
“也就是在未經(jīng)認真討論的情況下匆忙引入某種工具或者流程。團隊實施了變更，但并沒有對變更本身的含義進行協(xié)同探索。安全不應(yīng)該是一種硬性叫停的機制；相反，更有意義的思考應(yīng)該是「新的集成元素是否會引入新的風險？」”
“在運維方面，這樣的討論也同樣適用：如果發(fā)現(xiàn)安全漏洞，我們該先做點什么來遏止住問題，又該怎樣避免未來發(fā)生類似的問題？與DevOps領(lǐng)域的陷阱一樣，只要發(fā)現(xiàn)有「坑」，人們應(yīng)該通過回溯確定更多未來可以改進的地方。”——Mark Peters，Novetta公司技術(shù)負責人
陷阱八 一旦工件通過DevSecOps的審查，即授予100%的安全信任
“DevSecOps不是終點，而是一段持續(xù)而漫長的旅程。只要能時刻認清這一現(xiàn)實，我們就不會落入DevSecOps的泥潭。”——Sharath Dodda，TD公司IT開發(fā)經(jīng)理
