Isaac Sacolick ?沈建苗
專家們介紹了軟件開發團隊如何可以“將安全左移”(即在開發的早期階段就注重安全),并改善使用開源組件、管理代碼、部署服務和處理數據等方面的治理工作。
首席信息官及其IT部門面臨來自業務部門的巨大壓力,需要更新改造應用程序、改善客戶體驗、將應用程序遷移到云端,以及實現工作流程自動化。敏捷開發和開發運維(DevOps)包括相應的文化、實踐、工具和自動化,它們使軟件開發團隊能夠實現這些目標,并交付業務價值,擁有更高的質量和更快的發布周期。
最先進的開發團隊采用完全自動化的持續集成和持續交付(CI/CD)管道,擁有集成的測試自動化功能,并以基礎架構即代碼這種方式進行部署。它們將變更管理和事件管理工作流程與敏捷開發工具聯系在一起,并使用人工智能運維(AIops)平臺更快速地找到生產環境中實際問題的根本原因。

然而,軟件開發中的安全問題依然存在。行業分析公司ESG的《現代應用程序開發安全》報告顯示,只有36%的受訪者將其應用程序安全項目評為9分或10分,而66%的受訪者表示應用程序安全工具保護的代碼庫不到75%,48%的受訪者承認經常將易受攻擊的代碼推送到生產環境。
存在這些安全缺陷,倒不是由于缺乏技術、咨詢或安全服務提供商。《2020年網絡安全年鑒》列有3500多個潛在的安全合作伙伴。最終,要在盡量減少軟件開發中安全風險的同時提供業務價值,關鍵在于明確定義安全原則,并將這些原則告知軟件開發團隊。
以下是首席信息官和IT負責人應關注的六大風險以及應對方法。
企業組織將安全放在首位,許多組織也的確遵循敏捷和開發運維中的最佳安全實踐。但是與開發團隊的人數相比,信息安全團隊常常人手不足,不難看出業務和技術債務方面的其他優先事項占了敏捷團隊待完成工作的大部分,以及為什么整個組織沒有統一采用安全實踐。
ESG的研究報告支持這一結論。雖然78%的受訪者表示他們的安全分析員直接與開發人員互動,但只有31%的受訪者逐個審查功能和代碼。這個差距相當大,大多數企業組織不太可能聘請足夠多的安全專家,并將他們長期分配給敏捷開發團隊。但是許多企業組織可以做下列這些事:
· 要求對整個軟件開發團隊進行持續的安全培訓和教育。
· 要求信息安全團隊在Atlassian Confluence或Microsoft Teams等工具中記載安全驗收標準,并要求敏捷團隊在用戶故事中提到這些標準。
· 規范敏捷規劃和發布管理方面的協作,以便信息安全團隊可以在開發過程的早期標記高風險功能和用戶故事。
· 記錄并發布迭代開發周期(sprint)評審結果,以便信息安全團隊可以看到更多的評審結果,并標記有風險的實施。
· 要求所有新開發的API、微服務、集成機制和應用程序在CI/CD管道中落實所需的安全測試。
定義原則、確保跨團隊協作、改善文化和增進團隊幸福感,這些可能是首席信息官有助于改善軟件安全的幾種最重要的方法。2020年的《開發安全運維(DevSecOps)社區調查》發現,心情舒暢的開發人員關注安全的可能性高出3.6倍。
軟件開發團隊酷愛編寫和開發解決方案,企業組織需要他們的才能、創新和技術本領,以應對緊迫的業務挑戰。但有時候,實際需求也會讓開發團隊陷入不斷解決棘手的技術挑戰和實施方法中,而這些原本是可以從第三方獲得的。
低代碼和無代碼有時可能意味著更安全的解決方案,這至少有兩個原因:首先,敏捷產品的所有者并不總是了解其主要功能的安全隱患。其次,許多人在未規定解決方案要素的情況下試圖明確表達需求,這有時會導致團隊實施的代碼密集型解決方案帶來安全風險。
敏捷開發團隊應從向產品所有者詢問功能優先事項方面的問題入手,并商議范圍和需求。避免受到質疑的一種做法是,嚴格按照規范編寫用戶故事,并進行評估,以便復雜情況能在編程開始之前暴露出來。
一旦團隊就優先事項和功能范圍達成一致,開發團隊應考慮實施時具體在哪些地方利用第三方技術。審核對象應包括低代碼/無代碼平臺、開源代碼庫、商業框架、公共云服務和軟件即服務工具。
當然,天下沒有免費的午餐。使用第三方解決方案也會帶來風險。
你是否聽說過開發運維團隊為何最有能力挑選自己的工具?這是高級開發運維團隊經常提及的一個觀念,我也聽說過好幾本倡導這個原則的著名的開發運維書籍。
然而,許多首席信息官、IT負責人和首席信息安全官警告不要讓開發運維團隊全權決定工具和組件方面的選擇。與此同時,大多數負責人也承認,過多的限制和復雜的審批流程會阻礙創新,并讓才華橫溢的開發人員頗為沮喪。首席信息官、IT負責人和首席信息安全官必須圍繞技術選擇、升級和補丁,確定條理清晰、易于遵守的規則和明智的治理。
最近的調查結果表明了風險。有公司對1500名IT專業人員就開發安全運維和開源代碼管理進行了調查,結果發現,只有72%的企業聲稱擁有開源代碼使用方面的政策,只有64%的企業聲稱設有開源治理委員會。而這只是問題的冰山一角,因為只有16%的受訪者認為,一旦發現某個高危的開源漏洞,自己有能力修復漏洞。
考慮到與開源組件有關的泄密事件數量眾多,上述結果令人擔憂。在2020年的《開發安全運維社區調查》中,21%的受訪者承認遇到過與開源組件有關的泄密事件。這不僅僅是開源問題,因為任何商業系統也可能存在API安全漏洞或其他軟件組件漏洞。
要緩解風險,就需要在開源代碼的使用、工具選擇和技術生命周期等方面制定明確定義的政策、治理和管理實踐。但是企業組織在最佳實踐上有所不同。有些企業依賴更開放的程序,而另一些企業則依賴更低的風險容忍度和更嚴格的程序。為了在安全與創新之間達成兩者兼顧的政策,首席信息官應成立一個跨部門團隊,以確定治理程序、實踐標準、工具和度量指標。
擁有將開發者功能與安全最佳實踐相集成的工具,可以緩解選擇開源組件的一些挑戰。Quick Base公司的首席產品和技術官Jay Jamison介紹了該公司在用開源進行創新這方面的做法:
“我們很早就采用了GitHub Advanced Security,有了該產品,可比較容易地揪出GitHub平臺上管理的開源項目中的漏洞。這是讓安全更早地進入軟件開發生命周期(或用開發人員的術語來說就是左移)的重要一步。”
如何確保內部軟件的安全?之前的方法是:嚴加保護版本控制存儲庫、掃描代碼以查找漏洞、定義最小權限以便于部署、加密連接以及執行滲透測試。嚴加保護網絡和基礎架構是個全然不同的安全領域,牽涉IT運維部門管理的單獨工具和準則。
如今有了更多的風險和更多的工具,但也有了更好的集成機制。我與Cherwell工程副總裁Josh Mason談過Cherwell確保代碼安全的做法。他說:“我們Cherwell添加了自動靜態分析安全測試(SAST)、動態應用程序安全測試以及人工完成的滲透測試,這往往可以共同提高生產力。將SAST作為CI/CD管道的一部分來實施,使漏洞發現過程在軟件開發生命周期中進一步左移,因而可以更快速、更省錢地解決問題。”
Mason還建議嚴加保管版本控制存儲庫。“遵循零信任模型和最小特權原則的指導是一種良好的做法,限制了對源代碼控制存儲庫及其功能的訪問。源代碼控制存儲庫解決方案(比如Azure DevOps、GitHub和Bitbucket等)提供了細粒度的用戶權限,從而將開發人員(或整個開發團隊)限制在與他們的工作有關的一小部分代碼庫。”
戴爾科技旗下Boomi的工程主管Rajesh Raheja建議遵循幾個安全準則,開發團隊應肩負起責任。“如果軟件開發不當,與單個系統遭到攻擊相比,大規模環境下的安全風險會大幅放大。要想緩解風險,就必須確保CI/CD管道安全,以最小特權原則嚴加保護系統,借助多因子身份驗證為自動化實施安全變通方法,提高團隊成員的安全意識,并制定安全編程實踐。”
雖然許多開發運維團隊精通開發、測試和部署應用程序方面的安全實踐,但他們還必須添加數據管理和數據運維方面的安全實踐。
DataKitchen首席執行官Chris Bergh解釋了該問題以及更多的數據運維安全實現自動化的方法。“數據隱私和安全方面的挑戰阻止公司利用其數據獲得競爭優勢。手動流程無法解決這個問題——太多的數據太快速地流入,來不及處理。數據安全運維(Datasecops)是一套使數據隱私和安全實現自動化的方法,它將隱私、安全和治理集成到與數據分析開發、部署和運維一起執行的自動化工作流程中。”
首席信息官和IT負責人在數據運維方面遇到的主要挑戰是,采用主動的數據治理、標記敏感數據,以及對開發人員和數據科學家進行可接受的數據實踐方面的教育。集中身份管理、定義基于角色的授權以及掩藏開發環境中的敏感數據,這些是確保數據安全和數據隱私的重要做法。
管理敏感數據超出了數據安全的范疇。比如說,許多公司(尤其是受監管行業的那些公司)必須記錄數據沿襲(data lineage),表明誰變更了數據、何時更改、在何處更改以及如何更改。這些公司常常使用擁有內置數據沿襲功能的數據集成和數據管理平臺。
我管理風險和安全的方法向來是聽取不同專家的建議。安全威脅的程度和復雜性在與日俱增,大多數企業組織不太可能擁有所有必需的專業知識。此外,真出現安全問題時,可以向一群人討教如何降低風險、解決問題、收集取證分析結果以及堵住漏洞,對于盡量減小影響至關重要。
雖然諸多工具和實踐幫助首席信息官解決當下的問題,但我們仍需要專家來應對下一批安全挑戰。
本文作者Isaac Sacolick著有亞馬遜暢銷書《數字化驅動:通過技術進行業務轉型的領導者指南》,該書介紹了很多實踐,比如敏捷規劃、開發運維和數據科學,這些都是成功實施數字化轉型計劃的關鍵。Sacolick是一位公認的頂級首席信息官和數字化轉型方面的影響力者。他在InfoWorld.com、CIO.com、個人博客Social, Agile, and Transformation以及其他網站上發表的文章超過了650篇。
原文網址
https://www.infoworld.com/article/3607914/6-security-risks-in-software-development-and-how-to-address-them.html