數(shù)字化轉(zhuǎn)型是一股不可忽視的力量。在每個垂直領域，企業(yè)都努力成為技術公司，并越來越多地區(qū)分他們?nèi)绾螌崿F(xiàn)這一描述。

云和DevOps在這種轉(zhuǎn)型中發(fā)揮著巨大的作用，并徹底改變了我們開發(fā)和運營軟件的方式。軟件從未像今天這樣容易創(chuàng)建，從未像今天這樣頻繁地更新，也從未創(chuàng)新過如此迅速地適應客戶需求。

面對這樣的變化，安全別無選擇，只能適應。企業(yè)必須并將繼續(xù)努力提高速度，而獨立團隊是實現(xiàn)這一目標的唯一途徑。我們保護應用程序的方式必須轉(zhuǎn)變，使其成為這些獨立開發(fā)團隊日常工作的一部分。安全團隊首先需要專注于幫助這些團隊實現(xiàn)安全性。安全性需要成為開發(fā)優(yōu)先。

安全行業(yè)并不是 DevOps 旅程的一部分。安全流程傾向于控制持續(xù)流程，而不是合并到流程中。值得注意的是，安全流程無法實現(xiàn)以下功能：

增強獨立開發(fā)團隊的能力

安全能力由一個單獨的團隊擁有，開發(fā)團隊無權做出安全決策，并且工具主要是為審計人員而不是構建人員設計的。

持續(xù)運維

安全流程仍然嚴重依賴手動門，例如安全審計或結(jié)果審查，從而減慢了持續(xù)流程的速度。

讓安全工作違背速度和獨立性的業(yè)務動機，不可能有好下場。開發(fā)團隊必須在放慢速度（這會損害業(yè)務成果）和規(guī)避安全控制（這會引入重大風險）之間做出選擇。這些都不是可行的長期選擇，因此企業(yè)必須改變其安全實踐以適應 DevOps 現(xiàn)實。

DevOps 推動了對開發(fā)優(yōu)先的安全方法論的需求，在數(shù)字化轉(zhuǎn)型時代，我們還看到了云的演變和云原生應用程序。云原生應用程序的范圍比其前身更廣泛，并且越來越多地包含底層堆棧的更多元素。

應用程序范圍的這種變化也需要改變應用程序安全的范圍。本文討論應用程序安全性的一個新的和擴展的范圍，稱為云原生應用程序安全 （CNAS）。

采用 CNAS 需要對我們保護應用程序和基礎架構的方式進行重大更改。進行轉(zhuǎn)變的過程是一個旅程，對于每個組織，甚至對于同一組織的不同部分，其經(jīng)歷都是不同的。

雖然選擇正確的道路是由你的決定，但是為了獲得正確的路徑，模式和最佳實踐已經(jīng)開始出現(xiàn)。在本文中，我提出了幾個可以考慮打破現(xiàn)狀的領域，以及如何打破現(xiàn)狀。

重新思考安全組織架構

組織通常根據(jù)責任范圍進行拆分。當你將保護基礎架構的某些部分視為應用程序安全問題時，請重新考慮如何構建安全組織。更具體地說，請考慮是否更改應用程序安全團隊的責任范圍。

此外，隨著你的安全實踐變得更加偏向開發(fā)優(yōu)先的理念，并專注于增強開發(fā)人員的能力，你對此應用程序安全團隊的要求也會發(fā)生變化。你需要更多的同理心和項目管理以及更多的工程能力。你需要更多的建設者和更少的破壞者。

為了幫助你評估安全部門的組織結(jié)構，以下是我在應用程序安全這個領域中看到的三個最常見的團隊作用域：核心應用程序安全、安全工程和較新的產(chǎn)品安全。這些應該作為如何構建組織的參考點，而不是采用完美的模型。

核心應用安全團隊

讓我們從現(xiàn)狀開始，為應用程序安全團隊保持相同的范圍。由于這是默認狀態(tài)，因此大多數(shù)組織都使用此團隊作用域， 至少作為起點。

核心應用程序安全團隊的任務是保護自定義應用程序代碼和業(yè)務邏輯以及正在使用的開源庫。他們通常擁有經(jīng)典的應用程序安全測試（AST）套件，包括靜態(tài)，動態(tài)和交互式應用程序安全測試（SAST，DAST和IAST）以查找自定義代碼中的漏洞，以及軟件成分分析（SCA）工具以查找易受攻擊的開源庫。此外，這些團隊通常會開發(fā)安全教育和培訓，并可能開展漏洞管理或漏洞賞金工作。在某些情況下，他們也可能使用 RASP 或 WAF 工具實現(xiàn)運行時應用程序保護的能力。

核心應用程序安全團隊成員通常需要是安全編碼方面的專家，并具有應用程序運行審核和安全代碼審計的一些經(jīng)驗。他們需要良好的開發(fā)人員同理心才能與開發(fā)人員合作，這反過來又需要一些理解或與代碼相關的能力，但不需要完整的軟件開發(fā)證書。

堅持設定核心應用程序安全團隊的主要優(yōu)勢是它在行業(yè)中的長期地位。它使招聘具有整個團隊領域經(jīng)驗的專業(yè)人員變得更容易。對于工具來說，這是一個工具和實踐被很好地記錄的領域。從組織結(jié)構的角度來看，大多數(shù)行業(yè)都會認為應用程序安全團隊與核心應用程序安全團隊類似。

雖然核心應用程序安全團隊的職責范圍是維持現(xiàn)狀，但它的方法論往往變得更加有利于開發(fā)人員。應用程序安全團隊通常會將團隊中的個人職責分配為多個開發(fā)團隊的合作伙伴，從而幫助促進更好的協(xié)作。在應用安全領域有許多同行會開展安全冠軍計劃，幫助他們獲得規(guī)模并在開發(fā)團隊中嵌入更多安全專業(yè)知識。雖然范圍基本保持不變，但核心應用程序安全團隊的內(nèi)部實踐不必是傳統(tǒng)的那些做法。

安全工程/安全平臺團隊

將安全管控流程的步驟實現(xiàn)自動化是現(xiàn)代開發(fā)環(huán)境中的關鍵?？焖?nbsp;CI/CD 管道沒有手動審查的空間，而是需要自動化管道測試。此外，開發(fā)人員不是安全專家，他們花在安全上的時間更少，因此需要具有嵌入式安全專業(yè)知識的工具，并能夠減輕或促進安全性決策。

構建和運營安全工具并非易事，尤其是在大型組織中，不同的開發(fā)團隊有著截然不同的要求。為了幫助提高自動化程度，一些組織創(chuàng)建了專門的安全工程團隊，專注于構建內(nèi)部工具和集成外部工具，所有這些都是為了增強安全性。

安全工程團隊由對安全性略有偏見的軟件工程師組成，其運作方式與完整的 DevOps 工程團隊類似。他們通常構建、部署和運營他們構建的服務，并使用與其他工程團隊相同的方法來運行其敏捷流程和管理產(chǎn)品積壓工作。

如果工作量不夠大，不足以保證單獨建立自己的團隊，那么同樣的活動通常也可以嵌入到核心應用程序安全團隊中。然而，盡管名為“安全工程”的團隊在章程中非常一致，但擁有（越來越普遍的）安全工程師頭銜的個人在職責上差異很大。有些人是上文所描述的軟件工程師，而對于其他人來說，頭銜中的“工程師”部分指的則是安全領域。

安全工程團隊是真正提高自動化程度的好方法，并且是面向運維的平臺或站點可靠性工程師 （SRE） 團隊的絕佳并行團隊。事實上，在相當多的情況下，平臺團隊的范圍已經(jīng)擴大到包括構建和運營此類安全工具。這也是讓軟件工程師加入安全團隊的好方法，幫助解決人才短缺問題，并在安全團隊中建立更多的開發(fā)人員同理心。

產(chǎn)品安全團隊/云原生應用安全團隊

安全團隊模式的最新成員是產(chǎn)品安全團隊。這些團隊的范圍更大，不僅包括應用程序代碼本身，還包括與產(chǎn)品有關的所有內(nèi)容。最值得注意的是，兩個關鍵的新增功能是捕獲完整的 CNAS 范圍，并幫助在產(chǎn)品本身中構建安全功能。

完整的云原生應用安全范圍

擴展到包括 CNAS 范圍是將某些基礎架構風險重新思考為應用程序安全性的自然結(jié)果。如今，像容器和IaC這樣的技術都是由編寫自定義代碼、使用相同實踐和工具的相同開發(fā)人員驅(qū)動的。為了支持這一變化，AppSec團隊需要支持這些工程師成功地做到這一點。擁抱這個更廣泛范圍的團隊通常將自己稱為產(chǎn)品安全團隊。

這種擴展的CNAS范圍意味著產(chǎn)品安全團隊在軟件開發(fā)生命周期中的更大一部分內(nèi)開展工作。包括更多的參與到生產(chǎn)部署甚至運維工作中，從而導致與更注重運營的云安全團隊重疊。在實踐中，云原生開發(fā)意味著云安全同時受到開發(fā)和運維團隊的影響，產(chǎn)品安全團隊覆蓋前者。

請注意，許多核心應用程序安全團隊正在擴展以涵蓋完整的 CNAS 范圍，而無需正式更改其團隊名稱和任務。選擇和實施解決方案來掃描容器鏡像以查找漏洞并審核 IaC 文件越來越成為應用程序安全團隊的領域。雖然可以安全地假設產(chǎn)品安全團隊捕獲了這個完整的范圍，但這樣的重命名并不是絕對必要的，而且許多應用安全團隊在沒有這種聲明的情況下已經(jīng)發(fā)展起來了。

產(chǎn)品安全功能

與CNAS無關但仍然值得注意的一點是，產(chǎn)品安全團隊的參與具有更面向用戶的安全性部分：安全功能。隨著用戶對安全的重要性的認識不斷提高，許多產(chǎn)品都希望構建專用的安全功能，并通過它們實現(xiàn)差異化。確定哪些安全功能有價值需要一定程度的安全理解，開發(fā)團隊可能沒有，但安全團隊有。產(chǎn)品安全團隊通常在這里扮演一個明確的角色，與產(chǎn)品經(jīng)理（PM）合作，他們擁有完整的產(chǎn)品功能和價值主張，比以往任何時候都要多。

此職責在應用程序和安全團隊之間的關系中起著重要作用。安全控制是降低風險的一種手段，但能夠?qū)⒋孙L險緩解作為安全功能提供意味著它可以幫助增加收入。增加收入是兩個團隊的另一個共同目標，而且比降低風險更明顯，這使得慶祝成功變得更加容易。

產(chǎn)品安全的演變

產(chǎn)品安全是一個新的頭銜和范圍，并且仍在定義中。鑒于其范圍更廣，它通常是上級頭銜或大團隊，其中包括提到的其他團隊。在一些云原生組織中，產(chǎn)品安全是首席安全官（CSO）的主要范圍，而其他一些組織則開始任命領導者為首席產(chǎn)品安全官（CSO）。

Atlassian 首席信息安全官 （CISO） Adrian Ludwig 說得最好，他說：“產(chǎn)品安全的目標是改善產(chǎn)品的安全狀況，并在內(nèi)部向開發(fā)團隊代表客戶的安全期望”。Twilio，Deliveroo和Snyk等其他公司也使用這個頭銜，我相信這是解決 CNAS 的正確方法。

DevSecOps 團隊呢？

你可能已經(jīng)注意到我沒有說出 DevSecOps 團隊的名字，這不是偶然的。與DevOps一樣，DevSecOps不是一個團隊;這是一項運動，旨在將安全性嵌入到核心開發(fā)和運營工作中。在我看來，它不應該是一個團隊的頭銜。

但是，就像 DevOps 團隊一樣，DevSecOps 團隊也存在，他們的任務也大不相同。有時，他們實際上是一個云安全團隊，專注于運營和運行時的安全性。其他時候，它們更像平臺，其職責范圍類似于安全工程團隊。由于頭銜并不意味著一組特定的職責，因此DevSecOps團隊的職責范圍并不是可以真正定義的。

然而，所有這些團隊的共同點是他們具有前瞻性思維。DevSecOps旨在改變我們做安全的方式，而DevSecOps團隊，無論其范圍如何，都始終將自己視為變革推動者。他們擁抱自動化和云，更喜歡工程化的安全解決方案而不是開展審計工作，并致力于授權開發(fā)和運維團隊能夠自己保護自己的工作。