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