標題：淺析雲原生應用安全組織架構

數字化轉型是一股不可忽視的力量。在每個垂直領域，企業都努力成為技術公司，並越來越多地區分他們如何實現這一描述。

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

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

安全行業並不是DevOps旅程的一部分。安全流程傾向於控制持續流程，而不是合併到流程中。值得注意的是，安全流程無法實現以下功能：

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

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

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

DevOps推動了對開發優先的安全方法論的需求，在數字化轉型時代，我們還看到了雲的演變和雲原生應用程序。雲原生應用程序的範圍比其前身更廣泛，並且越來越多地包含底層堆棧的更多元素。

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

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

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

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

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

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

核心應用安全團隊讓我們從現狀開始，為應用程序安全團隊保持相同的範圍。由於這是默認狀態，因此大多數組織都使用此團隊作用域，至少作為起點。

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

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

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

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

安全工程/安全平台團隊將安全管控流程的步驟實現自動化是現代開發環境中的關鍵。快速CI/CD管道沒有手動審查的空間，而是需要自動化管道測試。此外，開發人員不是安全專家，他們花在安全上的時間更少，因此需要具有嵌入式安全專業知識的工具，並能夠減輕或促進安全性決策。

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

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

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

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

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

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

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

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

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

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

產品安全的演變產品安全是一個新的頭銜和範圍，並且仍在定義中。鑑於其範圍更廣，它通常是上級頭銜或大團隊，其中包括提到的其他團隊。在一些雲原生組織中，產品安全是首席安全官（CSO）的主要範圍，而其他一些組織則開始任命領導者為首席產品安全官（CSO）。

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

DevSecOps團隊呢？

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

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

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