當(dāng)新冠疫情發(fā)生時(shí)，很多公司不得不迅速改變他們的業(yè)務(wù)模式。事實(shí)上，許多人開始忽略了某些安全方面的問題，而這些問題是為擁有快速開發(fā)周期和為客戶提供新功能所做的權(quán)衡。現(xiàn)在是時(shí)候回過頭來重新審視安全政策和準(zhǔn)則，以及如何最好地將它們整合到敏捷開發(fā)過程中。

[[437651]]

當(dāng)今許多組織面臨的最大挑戰(zhàn)是安全團(tuán)隊(duì)幾乎總是與工程和運(yùn)營組織分開。隨著新興的云和云原生技術(shù)的出現(xiàn)，安全團(tuán)隊(duì)需要集中管理、監(jiān)控和處理工程團(tuán)隊(duì)的工作流。

為了在工程組織內(nèi)建立安全思維，安全團(tuán)隊(duì)必須為工程團(tuán)隊(duì)提供適合其工作流程的工具。如果安全團(tuán)隊(duì)的解決方案只是將包裝代碼放在安全團(tuán)隊(duì)要求的工具之上，那么它將成為一種附加的管理技術(shù)，可能會減慢進(jìn)度。

將安全融入敏捷和 DevOps 的工作方式中

很多人認(rèn)為當(dāng)安全被納入流程時(shí)速度會降低，但這是一種誤解。如果安全策略和閘門未集成或自動化到軟件交付系統(tǒng)中，則上市時(shí)間通常會延遲。即使有一個(gè)集中的安全團(tuán)隊(duì)，讓他們成為敏捷開發(fā)流程和整個(gè) DevOps 轉(zhuǎn)型之旅的一部分，也將幫助所有團(tuán)隊(duì)更快、更有效地解決出現(xiàn)的安全問題。

DevOps在很大程度上被象征為一個(gè)無限的連續(xù)反饋回路的概念。如果我們把安全實(shí)踐放在這個(gè)無限的符號之上，安全策略就會從頭到尾被整合起來--計(jì)劃、構(gòu)建、配置、測試、分析和監(jiān)控。這描述了一組可以分配給不同應(yīng)用程序團(tuán)隊(duì)的共同目標(biāo)，并使他們能夠?qū)δ承┌踩呗該碛兴袡?quán)，而不是一個(gè)擁有安全策略責(zé)任和任務(wù)的集中團(tuán)隊(duì)。

以下是一些需要考慮的步驟和做法：

●首先，工程和運(yùn)營團(tuán)隊(duì)需要預(yù)測威脅，不僅在應(yīng)用程序?qū)用妫以诨A(chǔ)設(shè)施層面。對出現(xiàn)的問題做出反應(yīng)是很麻煩的，團(tuán)隊(duì)需要積極應(yīng)對這種情況。這是人們現(xiàn)在正在創(chuàng)造的一種心態(tài)，而這種心態(tài)在新冠疫情剛剛發(fā)生時(shí)并不一定存在。

●集中式或聯(lián)合式的安全模式是實(shí)用的，但不能在第一天就實(shí)施。在這種組織范圍內(nèi)的模式建立之前，它必須經(jīng)歷逐步的轉(zhuǎn)變，以了解軟件交付管理的整體觀點(diǎn)。就像敏捷一樣，它是一個(gè)框架，需要隨著時(shí)間的推移進(jìn)行審查和改進(jìn)。

●構(gòu)建一種通用方法，包括定義靜態(tài)代碼分析、動態(tài)代碼分析和代碼漏洞監(jiān)控方面所需的關(guān)鍵安全策略。這些政策可以從平臺的角度為應(yīng)用團(tuán)隊(duì)實(shí)現(xiàn)自動化和協(xié)調(diào)化。這使得安全領(lǐng)導(dǎo)更容易從這些不同的團(tuán)隊(duì)中獲得可見性和洞察力。它還創(chuàng)建了關(guān)于存在哪些差距以及如何改進(jìn)的必要反饋循環(huán)。

●提供 API 集成作為平臺方法的一部分——將代碼從開發(fā)環(huán)境推送到生產(chǎn)環(huán)境，將有助于簡化工程團(tuán)隊(duì)的工作流程，無需擔(dān)心每個(gè)階段添加的安全技術(shù)，因?yàn)樗呀?jīng)融入系統(tǒng)。無代碼或低代碼平臺可以更輕松地插入安全工具并運(yùn)行它。

●無論您是否授權(quán)工程和運(yùn)營團(tuán)隊(duì)選擇工具，一種新興的做法是利用可擴(kuò)展的、無代碼的集成編排平臺來補(bǔ)充工程和運(yùn)營流程。這將使安全實(shí)踐得以遵循，并且可以按照他們交付軟件的速度進(jìn)行管理和維護(hù)。

●研究每個(gè)應(yīng)用程序的情況，包括使用的技術(shù)，以及消費(fèi)者如何使用該解決方案。這為所有的應(yīng)用程序創(chuàng)建了一個(gè)基線，而不考慮技術(shù)、云基礎(chǔ)設(shè)施、平臺等。這將有助于從安全威脅的角度根除誤報(bào)，并為后續(xù)步驟提供更清晰的畫面。如果誤報(bào)始終是強(qiáng)制性的安全補(bǔ)救措施(即使它可能不是實(shí)際威脅)，軟件交付的速度就會受到影響。

例如，使用 Spring Boot 微服務(wù)和 Node.js。在 Spring Boot 微服務(wù)中，你可能會有很多誤報(bào)，作為一個(gè)高度警惕的關(guān)鍵漏洞。實(shí)際上，這些并不是阻止代碼部署到生產(chǎn)的關(guān)鍵漏洞。這種考慮必須循環(huán)到安全策略中，以了解它的需求、授予異常并管理未來的安全異常。這提供了管理異常的基線，以允許代碼首先投入生產(chǎn)。如果安全團(tuán)隊(duì)因?yàn)榇祟愓`報(bào)而繼續(xù)停止流程，并且不了解應(yīng)用程序環(huán)境和業(yè)務(wù)需求，那么安全性可能會成為執(zhí)行團(tuán)隊(duì)和整個(gè)企業(yè)的麻煩事。

預(yù)料到陷阱，并避免它

最常見的陷阱是安全團(tuán)隊(duì)對應(yīng)用環(huán)境沒有足夠的了解，以及在公司的產(chǎn)品組合和平臺環(huán)境方面如何對業(yè)務(wù)下游產(chǎn)生影響。安全團(tuán)隊(duì)需要在所有這四種情況下接受培訓(xùn)，以了解需要實(shí)施哪些政策和準(zhǔn)則。

從軟件工程的角度來看，人們總是在推動更高的速度。但是，對安全框架的戰(zhàn)略思考并不總是這種思維方式的一部分。

集中式的安全團(tuán)隊(duì)經(jīng)常推動為每一段被推送到生產(chǎn)中的代碼制定政策。但安全團(tuán)隊(duì)可能不提供API集成，例如，使這個(gè)過程更容易。僅僅實(shí)施安全策略是沒有任何好處的。

最終，目標(biāo)是在集中式安全團(tuán)隊(duì)和軟件工程團(tuán)隊(duì)之間建立伙伴關(guān)系，以實(shí)現(xiàn)DevOps轉(zhuǎn)型之旅的承諾。為了確保開發(fā)和部署的獨(dú)特代碼是安全的，需要一個(gè)漸進(jìn)的學(xué)習(xí)過程，以及對應(yīng)用團(tuán)隊(duì)和軟件交付系統(tǒng)的需求有更多的了解。只有這樣才能在此基礎(chǔ)上建立一個(gè)安全框架。這種方法和思維的演變將使我們在未來更容易適應(yīng)新出現(xiàn)的威脅，并在這個(gè)不確定的時(shí)代提供企業(yè)所需的可見性和控制力。