采用 CNAS 需要對我們保護應(yīng)用程序和基礎(chǔ)架構(gòu)的方式進行重大改變。轉(zhuǎn)變是一個旅程，每個組織都不相同，甚至同一組織的不同部分也不同。

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

重新思考工具

除了組織架構(gòu)的改變，CNAS 和“開發(fā)優(yōu)先”還需要重新評估你的工具包。鑒于這種新視角，你應(yīng)該重新考慮在技術(shù)解決方案中尋找的最重要特征，以及你希望如何捆綁工具。

有很多方法可以重新評估工具，但我建議關(guān)注三個主要領(lǐng)域：開發(fā)工具采用、平臺范圍和治理方法。

開發(fā)人員工具口徑

如果我們的目標是讓開發(fā)人員在日常工作中能夠構(gòu)建安全性，我們需要確保為他們提供針對該目標進行優(yōu)化的工具。如果你購買專為審計人員設(shè)計的解決方案并要求開發(fā)人員使用它們，那么你不太可能取得成功。

不出所料，開發(fā)人員習慣于使用開發(fā)人員慣用的工具。這些工具代表了整個行業(yè)，圍繞著什么是優(yōu)秀的開發(fā)者工具這一主題，已經(jīng)在行業(yè)內(nèi)發(fā)展了自己的最佳實踐。為了幫助你選擇開發(fā)人員將采用的安全解決方案，你應(yīng)該根據(jù)開發(fā)者工具最佳實踐評估這些工具，并了解它們的表現(xiàn)如何。

以下是優(yōu)秀的開發(fā)者工具的一些常見特征：

成功的自助服務(wù)采用

實際上，所有成功的開發(fā)工具都具有出色的自助服務(wù)用法，包括輕松的上手培訓、直觀的工作流程和出色的文檔。這是開發(fā)人員喜歡使用工具的方式，它迫使供應(yīng)商確保他們的工具與開發(fā)人員相關(guān)，而無需銷售人員推動它。除非你想成為向開發(fā)人員推廣工具的銷售人員，否則請尋找具有開發(fā)人員自助服務(wù)采用的良好記錄的工具。

無縫集成到工作流程中

在大多數(shù)情況下，開發(fā)工具經(jīng)常與開發(fā)人員打交道，而不是要求他們再打開另一個工具。它們優(yōu)雅地集成到其 IDE、Git 和研發(fā)管道中，并在正確的時間點提供價值。集成不僅僅是技術(shù)鉤子;他們需要適應(yīng)工作流程和最佳實踐，否則將被拒絕采用。

豐富的API和自動化友好

雖然需要固執(zhí)己見的集成才能開始，但開發(fā)工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端（CLI/軟件開發(fā)工具包[SDK]）是強制性的，既可以將該工具調(diào)整到每個管道，又允許社區(qū)在其上進行構(gòu)建。如果你不能在工具上構(gòu)建，它就不是一個偉大的開發(fā)工具。

開源和社區(qū)采用

開發(fā)人員希望其他開發(fā)人員來驗證工具的可信度，而開源采用是最好的指標?？吹介_源項目集成了安全工具或基于此構(gòu)建的開源項目，這些都是很好的開發(fā)人員社區(qū)驗證。在檢查安全工具時，檢查它在開源中的采用情況并得出自己的結(jié)論。

這些只是眾多開發(fā)工具最佳實踐中的一小部分。如果你想了解更多關(guān)于開發(fā)優(yōu)先安全性的特定安全建議，請繼續(xù)往下看。此外，在評估任何工具時，請確保讓實際的應(yīng)用程序開發(fā)人員參與進來，以便從現(xiàn)實生活中了解它與周圍環(huán)境的契合程度（如下圖所示）。

開發(fā)人員友好的安全工具示例

平臺范圍

當前主流的 AST 平臺主要關(guān)注自定義代碼，也許還有應(yīng)用使用的開源庫。工具套件主要由 SAST、DAST 和 IAST 組成，最近又添加了 SCA。當你擁抱更廣泛的云原生應(yīng)用程序范圍時，請重新考慮平臺的構(gòu)成。

首先，讓我們考慮一下哪些工具從成為單一平臺的一部分中受益。它們可以分為下面幾個部分：

共享用戶：如果不同的工具是為不同的主要用戶設(shè)計的，那么它們幾乎不需要成為單個平臺的一部分，因為它們無論如何都會單獨使用。

共享工作流：如果以類似的方式使用多個工具并集成到用戶工作流的類似點中，則可以通過組合它們來節(jié)省集成時間以及用戶的時間和精力，而無需使用多個單獨的工具。

共享優(yōu)先級：如果來自不同工具的行動項應(yīng)彼此優(yōu)先排序，則共享積壓工作可以提高效率和結(jié)果。

價值倍增：最后，工具共享平臺的最強驅(qū)動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什么像SAST和SCA這樣的技術(shù)非常適合單一平臺。兩者都為相同的開發(fā)人員用戶提供服務(wù)，運行掃描并在相同的位置吸引用戶，并共享同一開發(fā)人員需要優(yōu)先考慮的安全漏洞的積壓。在高級 SCA 解決方案中，SAST 技術(shù)可以指示你的自定義代碼是否調(diào)用庫中易受攻擊的代碼，從而提供更高的準確性，從而增加價值。

當你考慮將容器和 IaC 安全性添加到 SAST 和 SCA 的同一平臺時，相同的邏輯也適用：

共享用戶：容器和 IaC 現(xiàn)在由開發(fā)人員保護，就像 SAST 和 SCA 一樣，他們寧愿沒有多個不同的產(chǎn)品需要花時間學習和參與。

共享工作流：保護容器和 IaC 需要跨生命周期的集成，例如 IDE、Git 和構(gòu)建集成，就像 SAST 和 SCA 一樣。

共享優(yōu)先級：同一個開發(fā)人員需要花費周期來修復(fù)容器或 IaC 漏洞，或者代碼或庫中的漏洞 —— 所有這些都是保護應(yīng)用的積壓工作。

價值倍增：保護這些組件有多種方式。掃描容器需要探索內(nèi)部的應(yīng)用程序，了解基礎(chǔ)設(shè)施配置有助于確定代碼和庫的漏洞優(yōu)先級，了解跨組件的流程有助于緩解問題；這正是你在對漏洞進行分類時所做的。

即使 CNAS 范圍擴大，這種邏輯仍然有效，我鼓勵你將 CNAS 工具視為一個平臺。一個簡單的準則是，Git 存儲庫中的任何內(nèi)容都可能與其周圍的文件相關(guān)，并遵循相同的開發(fā)工作流。因此，CNAS 平臺應(yīng)有助于保護存儲庫中的所有內(nèi)容（整個云原生應(yīng)用）。

DAST 和 IAST 在這樣一個平臺上是有點尷尬的參與者。盡管它們處理保護應(yīng)用程序，但它們通常需要不同的工作流程。由于運行它們所花費的時間，很難將它們放入構(gòu)建管道或 IDE 掃描中。在我看來，這是一個技術(shù)問題，而不是一個合乎邏輯的問題，一旦 IAST 和 DAST 解決方案發(fā)展到對管道更加友好，它有望得到解決。

治理和賦權(quán)方法

采用開發(fā)優(yōu)先的安全方法需要不同類型的協(xié)作。我們需要的工具不是專注于廣播和執(zhí)行自上而下的任務(wù)，而是幫助我們協(xié)作構(gòu)建安全應(yīng)用程序的工具。

這聽起來可能很明顯，但在實踐中，這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子，以了解這意味著什么。

首先，開發(fā)人員需要有能力平衡業(yè)務(wù)需求與安全風險。這意味著，例如，允許他們決定不修復(fù)發(fā)現(xiàn)的漏洞并繼續(xù)將其部署到生產(chǎn)環(huán)境。對某些人來說，這是一個可怕的命題，但這是實現(xiàn)獨立團隊的唯一方法。請注意，忽略漏洞仍應(yīng)要求提供（且可審核）原因，并且某些約束應(yīng)為硬杠杠（通常出于合規(guī)性原因），但作為默認立場，決策應(yīng)留給開發(fā)人員。

其次，開發(fā)人員需要能夠管理他們的安全風險，這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表，還需要包括確定優(yōu)先級所需的所有信息，例如可利用性和資產(chǎn)映射。對此類信息保持透明可能會帶來一些風險，但這是擴展安全性的唯一方法；要賦予開發(fā)人員權(quán)力，你必須信任他們提供這些敏感數(shù)據(jù)。

第三，安全團隊應(yīng)該投資于跟蹤和推動安全控制的采用，甚至超過他們的產(chǎn)出。開發(fā)團隊應(yīng)該管理其漏洞積壓工作，但安全團隊需要幫助他們成功做到這一點。開發(fā)優(yōu)先安全治理意味著跟蹤采用了哪些控件及其輸出的處理情況，并與開發(fā)團隊合作改進這些統(tǒng)計信息，而不是突出顯示他們應(yīng)該修復(fù)的漏洞。

這些只是評估治理工具和技術(shù)時要考慮的幾個示例。關(guān)鍵是要擁抱平臺心態(tài)；它的目標是幫助開發(fā)團隊成功構(gòu)建安全軟件，而不是跟蹤安全漏洞本身。

重新思考優(yōu)先事項

最后但并非最不重要的一點是，CNAS 需要重新考慮應(yīng)用程序安全優(yōu)先級。如果開發(fā)人員需要保護整個云原生應(yīng)用程序，你希望他們最關(guān)注哪些方面？

從歷史上看，IT安全控制主導(dǎo)了更大的預(yù)算，并且比應(yīng)用程序安全控制獲得了更多 CISO 的關(guān)注。這種不平衡可能有歷史原因，但歸根結(jié)底，它代表了 CISO 關(guān)于如何最好地使用他們的資金來降低組織風險的觀點。

換句話說，CISO 認為，由于未修補的服務(wù)器或配置錯誤的基礎(chǔ)架構(gòu)而導(dǎo)致的違規(guī)風險大于代碼中的自定義漏洞的風險。這種看法有相當多的數(shù)據(jù)來支持它，顯示了歷史違規(guī)行為及其原因。此外，它很容易理解;對于攻擊者來說，大規(guī)模運行已知的漏洞并尋找一扇敞開的門要比對應(yīng)用程序進行逆向工程并找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式；事實上，云加強了這個等式。采用云意味著使用更多的基礎(chǔ)設(shè)施和更多的服務(wù)器，它們往往更容易公開訪問，并且它們由不太熟悉管理它們的團隊（開發(fā)人員）定義，并配備了不太成熟的工具。

然而，雖然以前的平衡是在IT安全預(yù)算和應(yīng)用程序安全預(yù)算之間，但現(xiàn)在一切都在應(yīng)用程序安全世界中。在構(gòu)建云原生應(yīng)用程序時，相同的開發(fā)人員需要保護其自定義代碼，管理其開源使用中的漏洞，并使服務(wù)器和基礎(chǔ)架構(gòu)具有彈性。同一個應(yīng)用程序安全團隊需要幫助他們做到這一點，并在他們之間分配相同的預(yù)算。

因此，我們回到開場白：你希望如何分配寶貴的開發(fā)人員的時間和有限的CNAS預(yù)算？

丟掉開發(fā)人員自己的設(shè)備和應(yīng)用程序安全預(yù)算并讓開發(fā)人員的注意力集中在保護自定義代碼上。應(yīng)用程序安全成熟度模型、行業(yè)最佳實踐以及團隊中個人的個人體驗都錨定在云前的世界中，其中自定義代碼是開發(fā)人員必須保護的大部分內(nèi)容。購買 SAST 和 DAST 等工具通常是應(yīng)用程序安全新領(lǐng)導(dǎo)者名單上的第一件事，很少受到挑戰(zhàn)。

但是，考慮到 CNAS 的范圍，這仍然是你時間和金錢的最佳利用嗎？由于已知漏洞或配置錯誤而導(dǎo)致的違規(guī)風險仍然高于自定義代碼缺陷的風險，即使開發(fā)人員是配置它的人。如果你同意，難道不應(yīng)該告訴你的開發(fā)人員和應(yīng)用程序安全團隊首先要專注于保護這些層，然后才能處理他們的自定義代碼嗎？

這不是一個容易回答的問題。我不會假設(shè)知道你的優(yōu)先事項應(yīng)該是什么，因為這些優(yōu)先事項會因組織而異。但是，鑒于CNAS的范圍更廣，我強烈建議你在內(nèi)部進行此對話并重新考慮你的優(yōu)先事項。

結(jié)論

改變你處理應(yīng)用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響，包括人們的職業(yè)生涯，預(yù)算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關(guān)于你過去如何做事的肌肉記憶，而不是在選擇解決方案時回到第一原則，這需要寶貴的時間和精力。

好消息是，你不必一次完成所有操作。我在本文中概述的變化相互關(guān)聯(lián)，但可以按照自己的節(jié)奏應(yīng)用。我建議你選擇與你最相關(guān)的那些內(nèi)容，或者選擇你認為更重要的其他變化，并讓這些變化繼續(xù)下去。你將逐步調(diào)整安全功能以適應(yīng)云原生現(xiàn)實。

本文翻譯自：https://go.snyk.io/rs/677-THP-415/images/CNAS_OReilly.pdf如若轉(zhuǎn)載，請注明原文地址