CSA報告《DevSecOps的六大支柱 務實的實現(xiàn)》

3?2024云安全聯(lián)盟大中華區(qū)版權所有34?2024云安全聯(lián)盟大中華區(qū)版權所有4《DevSecOps的六大支柱：務實的實現(xiàn)（TheSixPillarsofDevSec中文版翻譯專家組5?2024云安全聯(lián)盟大中華區(qū)版權所有5英文版本編寫專家r6?2024云安全聯(lián)盟大中華區(qū)版權所有6序言DevSecOps專題也是CSA頂級云安全專家課程(CSAACSE)中級課程，7?2024云安全聯(lián)盟大中華區(qū)版權所有7 6 9 10 11 11 12 14 15 19 23 23 23 23 24 24 25 33 33 35 36 39 43 45 45 47 48 50 51 55 58 646集成與測試 656.1動態(tài)應用程序安全測試 658?2024云安全聯(lián)盟大中華區(qū)版權所有8 676.3API測試 69 71 726.5.1滲透測試范圍 74 75 77 78 79 80 81 83 84 89 93 96 97 98 98 1008運行時 102 102 104 107 1128.2.3事后刨析 115 116 118 122 125 1289?2024云安全聯(lián)盟大中華區(qū)版權所有9前言云安全聯(lián)盟（CSA）和SAFECode致力于提高軟件安全成果。2019年8月發(fā)布的論文《DevSecOps的六大支柱》提供了一套高級方法并成功實施了解決方案，其作者使用這些方法快速構建軟件并最大限度地減少與安全相關的錯誤。這六大支柱是：支柱1：集體責任（發(fā)布于2020年2月20日）支柱2：協(xié)作與整合（發(fā)布于2024年2月21日）支柱3：務實的實現(xiàn)（發(fā)布于2022年12月14日）支柱4：橋接合規(guī)與發(fā)展（發(fā)布于2022年8月2日）支柱5：自動化（發(fā)布于2020年6月7日）支柱6：測量、監(jiān)控、報告和行動（預計2024年4月）支持每個支柱的成功解決方案是云安全聯(lián)盟和SAFECode聯(lián)合出版物的更詳細的集合的主題。本文是后續(xù)出版物中的第四篇。?2024云安全聯(lián)盟大中華區(qū)版權所有在將安全性納入到軟件開發(fā)生命周期(SDLC)中時，組織有多種工具和解決方案可供選擇。然而，這些通常存在一些問題：要么難以部署、實施和擴展，要么無法提供有助于減輕實際安全風險的可行見解。由于每個SDLC在結構、流程、工具和整體成熟度方面都不同，因此沒有通用的二元藍圖來實施DevSecOps。通過采用與框架無關的DevSecOps模型（專注于應用程序開發(fā)和平臺安全，以確保數(shù)字社會的安全、隱私和信任組織將能夠切實地處理DevOps中的安全問題。該模型通過將安全嵌入到軟件開發(fā)生命周期中，以滿足所有在利益相關人（包括開發(fā)人員、運維人員和安全人員）連接過程中未被滿足的需求。1本文中的DevSecOps實施指南被組織成一系列實際職責和活動，旨在幫助數(shù)字安全領導者在開始進行DevSecOps時做出務實決策。采用通常由軟件開發(fā)和平臺工程團隊有機地建立，或者由領導層統(tǒng)一建立。無論驅動因素和利益相關者如何，組織都應將其DevSecOps實施視為一項迭代的持續(xù)改進工作，而不是一次性的瀑布項目。本文的范圍確定并擴展了成功的DevSecOps倡議的4個關鍵要素：文化、人員、流程和技術。本文涉及隱私，但沒有提供該領域的完整視圖（即隱私融入安全設計）。?2024云安全聯(lián)盟大中華區(qū)版權所有云安全聯(lián)盟DevSecOps工作組(WG)在“通過反思性安全（ReflexiveSecurity)）進行信息安全管理：安全、開發(fā)和運維集成的六大支柱”中發(fā)布了高級指南。2這六大支柱被認為是實施DevSecOps的關鍵重點領域，建議的支柱之一是務實實施安全計劃。務實的定義是基于實際而非理論考慮，明智而現(xiàn)實地做出深思熟慮的決策。3對于閱讀本文的數(shù)字和安全領導者來說，DevSecOps的實用主義將通過實施產(chǎn)生最高投資回報的方法來推動。本指南將幫助組織成功實施DevSecOps，將安全性嵌入到SDLC和DevOps的現(xiàn)有工作流程中。本文檔的目標受眾包括參與風險、信息安全和信息技術管理和運維職能的人員。該受眾包括CISO、CIO、CTO以及那些領導數(shù)字化轉型計劃的人。此外，應用系統(tǒng)、平臺、安全工程師和架構師也可以使用本指南作為改進組織DevSecOps計劃的參考。?2024云安全聯(lián)盟大中華區(qū)版權所有本文中的實施指南側重于涵蓋內部開發(fā)和第三方打包軟件的安全性，無論其在何處運行（本地或云上）。關于組織如何實施DevSecOps計劃，通常有兩種不同的觀點:1.從DevOps的角度來看，組織應該構建安全性并將其集成到SDLC中。2.從安全團隊的角度來看，安全控制通常是在考慮流程和技術的基礎上實施的。我們在本文中融合了這兩個常見觀點，并提供了全面覆蓋的安全活動指導。組織應將DevSecOps作為一項迭代和持續(xù)改進工作，而不是一次性項目。目的是讓讀者思考組織內希望重點改進的領域，然后參考本文及其指南，確定每個軟件生命周期階段的優(yōu)先活動。使用DevOps導入安全性從DevOps的角度來看，團隊可以在設計和編碼階段的早期解決安全問題，也稱為“左移”。其目的是盡早將安全與組織中的非安全利益相關者集成。建立默認的安全流程，以便以不安全的方式做事需要額外的努力，并且包括異常工作流程。圖1展示了DevOps觀點的安全性。通過DevOps觀點導入安全的組織通常包括以下步驟:1.評審開發(fā)和IT組織當前的軟件生命周期。這就是評估、構建、測試、部署和操作新技術的方式。SDLC通?？梢圆捎枚喾N方式來處理安全團隊可以利用的變更（即主要是功能請求）。2.評審DevOps和IT組織的現(xiàn)有工具，特別是自動化部署和開發(fā)任務的工具。理解開發(fā)工作流程和現(xiàn)有工具集有助于在軟件生命周期的每個階段制?2024云安全聯(lián)盟大中華區(qū)版權所有定安全控制決策。本文詳細探討了如何實現(xiàn)上述兩點，并結合支柱5自動化中詳細介紹的自動化方法。圖1:安全開發(fā)生命周期?2024云安全聯(lián)盟大中華區(qū)版權所有2軟件生命周期的安全轉型從安全的角度看，尋求安全改進的組織傾向穩(wěn)健的安全計劃，且這些計劃賴于將安全最佳實踐有效集成到組織的軟件開發(fā)范式中。這通常由文化和流程、安全基礎設施和技術的運營以及員工意識所主導。每個軟件生命周期階段的安全都需要結合人員、文化、流程和技術:人:組織中的個人及其角色，以及安全和成功的應用程序、平臺和基礎設施的交付。重點關注領導人、技術利益相關者、實施者和決策者。文化:組織如何處理和管理工作和風險。文化通常是軟件開發(fā)工作和安全的軟性和難以衡量的領域，它直接參與了績效和成功。過程:常見的工作流程、手工操作和有據(jù)可查的活動。人們在自動化或兩者組合的支持下執(zhí)行流程。技術:技術側重于使用工具和自動化安全地創(chuàng)建和操作基礎設施和應用程序，以幫助保護資產(chǎn)、檢測漏洞、事件和事故。這些組合之間將根據(jù)組織安全計劃的規(guī)模和復雜程度而有所不同。小型組織通常主要依賴于擔任多個角色的人員并管理應用程序的安全，而大型組織可能會利用技術和自動化。一個組織的文化可能會受到合規(guī)要求的影響，這會導致重大的監(jiān)督和審計，而其他組織則將制衡嵌入到標準工作流程中。?2024云安全聯(lián)盟大中華區(qū)版權所有2.1人是成功實現(xiàn)DevSecOps轉型的關鍵推動者DevSecOps最重要的方面是人。通常是組織在DevSecOps中的最大推動因素。跨職能團隊是具有互補能力的混合人的依賴關系，我們在表1中確定了在DevOps中要考慮的不同角色配置文件以及安全性的實際應用。我們將每個角色映射到其在DevSecOps階段中通常適合的位置。?2024云安全聯(lián)盟大中華區(qū)版權所有與業(yè)務部門合作，討論如何設計應用程序和使用基礎設施服務（包括云），以安全的方式達成于業(yè)務目標。制定方法、框架和模式，并幫助開發(fā)人員遵循安全開發(fā)最佳實踐。識別未來安全方法以演進現(xiàn)有的實踐，應對行業(yè)、監(jiān)管和技術變革，并確定DevSecOps的戰(zhàn)略和運營適應性（例如，控制措施的左移或右移）。與開發(fā)人員一起和高級業(yè)務利益相關者合作，為部署流水線和倉庫的安全方式、方法和使用自動化工具提供建議和評估。領導策略來溝通關鍵的計劃和成功案例，并評估安全工具和方法在整個組織、各個團隊和業(yè)務領域中的采用影響。將安全計劃與業(yè)務價值和戰(zhàn)略目標保持一致。將實現(xiàn)安全和業(yè)務目標的高級數(shù)字戰(zhàn)略與低級開發(fā)人員目標連接起來。協(xié)助管理和修復對應用程序造成的安全風險、漏洞和威脅。幫助產(chǎn)品團隊和開發(fā)人員采用與組織一致的安全計劃，通常是已經(jīng)從事軟件或基礎設施的開發(fā)人員或管理人員。持續(xù)評審其產(chǎn)品團隊內針對威脅、漏洞和風險的安全狀況。它可以作為混合角色共享。應用程序安識別應用程序代碼中的潛在缺陷，并通過修復安全問題來緩解漏洞。應用安全編碼和測試標準，并記錄安全編碼指南。將安全測試工具（如靜態(tài)和動態(tài)應用程序測試工具）集成進源代碼倉庫和持續(xù)集成和交付的流水線中。對應用程序代碼應用安全控制（如加密、標識和身份驗證），以減少攻擊面并最大程度地降低被利用風險。安全測試人員解決軟件測試階段的安全問題，包括風險接受、安全驗收標準和安全測試方法。定期執(zhí)行手動滲透測試，以暴露應用程序和基礎設施的弱點，并確認安全強制執(zhí)行功能的正確實施。根據(jù)測試輸出提出修復建議。安全運營工提供有關云、基礎設施和平臺服務的安全狀況的建議。在基礎設施和平臺上應用系統(tǒng)加固實踐，并確保強大的安全機制。執(zhí)行漏洞掃描和修復，以減少基礎設施上的攻擊面。?2024云安全聯(lián)盟大中華區(qū)版權所有云開發(fā)者運營工程師配置和運營云基礎設施，包括服務器、存儲和網(wǎng)絡。使用持續(xù)集成和部署方法自動配置云基礎設施和應用程序解決方案架構師開發(fā)解決方案架構和相關系統(tǒng)組件以滿足用戶需求。設計系統(tǒng)和系統(tǒng)間的接口，并確定目標環(huán)境的影響，包括但不限于安全狀況。軟件開發(fā)人員與架構師一起識別、設計和編寫代碼實現(xiàn)軟件特性。他們將幫助測試、維護和更新產(chǎn)品，以確保所有安全、性能和功能問題得到解決。安全角色和成果使開發(fā)人員能夠根據(jù)軟件工程方法論、工具、實踐以及安全代碼指南安全地編寫代碼。性能測試人員負責編寫和執(zhí)行負載和壓力測試基礎設施、平臺和應用程序的測試計劃。集成工程師有助于確保安全活動應用于集成的軟件包和集成的應用程序特性。引入影響整個應用程序的整體應用程序安全控制和過程-利用工具在運行時進行完整性校驗并掃描應用程序?，F(xiàn)代云原生架構更加分散-規(guī)模較小、具有安全性的分布式團隊可以更好地將端到端安全設計作為一個價值流來處理。盡管沒有一種適用于每個組織的DevSecOps團隊拓撲結構和架構的萬能解決方案，但某些特征會影響效率。一個具有強大技術領導力和技術管理能力的組織將能夠理解開發(fā)、運維和安全之間的差異和平衡，并認識到DevSecOps活動已集成到DevOps的每個階段。在設計團隊結構時，識別并避免一些常見錯誤（反模式）非常重要，例如:組織孤島:利益相關者屬于他們的團隊，并且不了解彼此的工作，團隊間不存在共同責任。安全在孤島中運營，僅在部署之前作為一個單一的安全大門參與其中，這助長了一種低生產(chǎn)力和低效的軟件開發(fā)實踐。這可以從領導層決定要實施DevSecOps，并開始組建團隊。這種方法成本效率低，只有在大量投資后才會開始獲得投資回報，這在開發(fā)和運維團隊分開并在孤島中運營時很常見。?2024云安全聯(lián)盟大中華區(qū)版權所有由開發(fā)人員執(zhí)行DevSecOps:盡管通常有好的積極性，并且可以帶來初步的收益。但在規(guī)模大的情況下很難保持一致，并且安全活動缺乏完整性。開發(fā)人員可能遇到的一個常見的陷阱是假設安全團隊僅執(zhí)行合規(guī)性和治理活動很容易低估安全構建系統(tǒng)所需的復雜性和知識，因為所需的技能不一定與功能開發(fā)重疊。重新定義安全團隊:從簡單地招聘DevSecOps員工加入您的安全團隊開始，以改進實踐并降低成本，但他們看不到DevSecOps對業(yè)務的核心驅動因素。隨著DevSecOps在行業(yè)中的發(fā)展日益明顯，團隊可能會在沒有了解安全如何提高運營效率的情況下采納DevSecOps，甚至在某些情況下增加發(fā)布頻率并降低安全投入。根據(jù)現(xiàn)有的DevOps和軟件開發(fā)范式了解DevSecOps（設計、編碼、集成和測試、部署和監(jiān)控）的不同階段，將有助于避免團隊拓撲反模式。?2024云安全聯(lián)盟大中華區(qū)版權所有2.2文化將加快速度并提高績效改變產(chǎn)品開發(fā)的思維方式是文化的基礎，需要流程來確保容易采用正確的文化特征。當我們分解DevSecOps成功的特征時，必須在每個領域之間建立責任共擔模型。開發(fā)、安全和運維角色應該協(xié)調工作，以實現(xiàn)快速、安全和穩(wěn)定的軟件目標。商業(yè)諺語“文化在戰(zhàn)略早餐上吃掉”5在將DevSecOps引入軟件開發(fā)范式和數(shù)字化轉型時具有相關性。最具創(chuàng)新性和普及性的軟件產(chǎn)品通?？梢圆粏渭円蕾囉诖罅客顿Y和明確的戰(zhàn)略的速度開發(fā)新功能。DevOps研究和評估(DORA)團隊的研究表明6，重視學習的組織文化有助于通過以下方式提高軟件交付績效:增加部署頻率縮短變更準備時間、恢復服務的時間以及變更失敗率強大的團隊文化高度信任并強調信息流的組織文化可以預測軟件交付績效和組織技術績效。DORA研究表明，改變人們的工作方式會改變文化。團隊可以通過檢查Westrum組織文化模型7的六個方面，重點關注生成性文化中出現(xiàn)的行為，來識別有助于創(chuàng)建促進信息流和信任的生成性文化的有益實踐:高度合作信使經(jīng)過培訓風險共擔鼓勵跨接（協(xié)作）失敗導致的調查實施新穎性（創(chuàng)新）?2024云安全聯(lián)盟大中華區(qū)版權所有文化指的是支持DevSecOps活動的原則和基礎能力。這些關鍵實踐推動了一種持續(xù)改進和作為跨職能團隊的嵌入成員盡早參與安全的文化。文化可能是一個任意的概念，導致團隊難以量化和衡量；我們已經(jīng)認識到成功的DevSecOps團隊的文化特征，他們可以快速將安全措施迅速。應于滿足業(yè)務需求的過程中。圖3概述了這些文化特征，并用圖1中CSADevSecOps軟件生命周期應用相應特征的程度進行著色。圖3:DevSecOps文化適用性矩陣當我們思考DevSecOps中可衡量的文化特征時，我們還需要剖析每個特征在每個階段通常應用的位置。只有三個文化特征適用于每個DevSecOps階段。這些特征是在表2和圖3中引用的安全基線和持續(xù)改進；它強調了以下方面的重要性和優(yōu)先順序:a.安全基線-了解每個階段的最小可行安全產(chǎn)品（安全基線）;?2024云安全聯(lián)盟大中華區(qū)版權所有b.持續(xù)改進-始終在每個階段尋求改進，無論是運營階段還是戰(zhàn)略階段;c.激勵——建立對目標和目標的獎勵，以激勵高績效。將特征映射到DevSecOps階段的相關性有助于確定安全控制的適用性以及它們是否會對軟件開發(fā)產(chǎn)生反作用。例如，“創(chuàng)新”特征僅在編碼階段具有較高的適用性。因此，編碼階段過度限制的安全控制可能會扼殺創(chuàng)新工作。然而，這應該與編碼中與安全相關的文化特征相平衡：安全基線、持續(xù)安全學習和集體安全責任。表2確定了優(yōu)化且富有成效的文化的特征，以實現(xiàn)DevSecOps的高投資回報。每個特征都通過適用性映射到DevSecOps階段；設計、編碼、集成和測試、部署和監(jiān)控。?2024云安全聯(lián)盟大中華區(qū)版權所有表2:DevSecOps文化特征定義定義加速變革鼓勵和加速持續(xù)的變革和改進。變革活動得到溝通和理解，而安全性也希望促進變革的加速創(chuàng)建指南安全設計流程和技術的使用都有詳細記錄，以便產(chǎn)品利益相關者了解安全設計工作并減少對員工個人知識的依賴。指南需要不斷審視以提高效率。保持溝通/透明度傳達關鍵舉措和成功經(jīng)驗。將安全計劃與業(yè)務價值和戰(zhàn)略目標保持一致。將安全和業(yè)務目標的高級數(shù)字策略與低級開發(fā)人員目標聯(lián)系起來。建設性的代碼評審是常態(tài)。安全性受到重視并包含在這些評審中安全故障準備安全措施需要假定為會失敗或被攻破的。失敗是預料之中的，響應計劃也已廣泛制定、討論、執(zhí)行和理解。如果確實發(fā)生故障，則會對其進行評審以確定進一步的改進。安全基線安全需求的基線和最小可行的安全產(chǎn)品是被充分理解的的。不可接受的結果是眾所周知的。鼓勵安全且可重用的組件并將其打包為模板。持續(xù)安全學習有關安全的信息共享在整個組織中是持續(xù)且普遍的。共享良好的安全實踐。集體安全責任每個人都對開發(fā)安全的產(chǎn)品和功能負有集體責任。安全不是別人的問題。創(chuàng)新日常運營和未來產(chǎn)品改進之間的工作得到了很好的平衡。時間被分配給項目目標之外的創(chuàng)新工作。環(huán)境旨在促進創(chuàng)新。衡量工作成本將安全左移不會讓開發(fā)人員負擔過重，從而對速度和創(chuàng)新產(chǎn)生負面影響。安全工作和努力是經(jīng)過衡量的。連續(xù)提高通過增量或突破性改進對產(chǎn)品、服務或流程進行持續(xù)改進。從小處開始思考從小處開始，同時仍能實現(xiàn)其他特性。短期勝利/沖刺與長期構建和活動之間的區(qū)別是可以理解的。最低限度可行、安全的產(chǎn)品很好了解安全性是如何隨著產(chǎn)品功能逐步發(fā)展的。激勵是系統(tǒng)地建立獎勵以激勵參與者實現(xiàn)目標。當減少漏洞并獲得獎勵時，安全性就會得到激勵。?2024云安全聯(lián)盟大中華區(qū)版權所有2.3技術和流程是DevSecOps實務的基礎在DevSecOps中產(chǎn)生最高投資回報的活動是通過有效使用工具/技術和流程來支持的。當我們分解DevOps范式時，我們可以確定安全活動（技術和流程）適合的位置。圖1中引用的SDLC的五個階段（設計、編碼、構建、部署和監(jiān)控）每個階段都有安全風險和活動，這些風險和活動在圖4-8矩陣中進行了擴展。本節(jié)中的安全活動并不反映解決方案設計中包含的安全資源。就像Web應用程序防火墻(WAF)、防病毒(AV)或入侵檢測系統(tǒng)(IDS)如何更好地保護應用程序/基礎設施一樣，它是產(chǎn)品設計所獨有的，這就是為什么我們將其視為一種安全控制而不是工具或流程支持的安全活動。3DevSecOps階段3.1設計與架構安全設計和架構階段先于編寫任何代碼，但在實施安全性時可能是SDLC中最關鍵的步驟。從長遠來看，現(xiàn)階段不安全的實施細節(jié)可能會放大未來的安全風險。相反，在此階段識別設計缺陷和產(chǎn)品風險可以節(jié)省大量工作時間，并在代碼編寫之前完全防止漏洞引入代碼庫。在設計階段可以解決的風險包括:無法識別和保護數(shù)據(jù)流框架和編程語言選擇固有的漏洞安全控制框架解決的常見風險從威脅建模中發(fā)現(xiàn)的不良設計決策與不完整或有缺陷的業(yè)務邏輯相關的漏洞3.2開發(fā)（編碼）安全編碼是基于設計階段的詳細要求進行應用開發(fā)的階段。在這里，開發(fā)人員選擇框架和庫，編寫代碼，并創(chuàng)建單元測試。隨著設計的決策和代碼?2024云安全聯(lián)盟大中華區(qū)版權所有的重寫，應用程序將處于重大變化之中。這一階段聚焦于設計和業(yè)務邏輯的安全實現(xiàn)，并基于安全編碼實踐開發(fā)應用程序后再提交到源代碼存儲庫（SCR）。這一階段可能導入安全脆弱性的風險包括:使用不安全的協(xié)議、框架或庫存在漏洞的源代碼和依賴關系關鍵代碼變更缺乏透明性3.3集成和測試集成和測試聚焦于將應用程序的組件組裝成可發(fā)布的工件，并測試新的發(fā)布以確保其滿足設計要求。應該對運行中的應用程序，以及程序的組裝和發(fā)布過程進行明確的安全項測試。這個階段應重點測試產(chǎn)品的應用程序在運行時的安全。本階段的風險包括:構建流程缺乏完整性運行時環(huán)境或源代碼安全配置錯誤運行時應用程序或基礎設施的漏洞利用不恰當?shù)臏y試或缺乏安全測試標準3.4交付和部署交付和部署聚焦于形成預構建的發(fā)布制品，并將其在產(chǎn)品中發(fā)布。這需要確保安全檢查已經(jīng)完成，并使用正確的新制品和環(huán)境配置進行部署。本階段應重點控制產(chǎn)品變更、變更行為記錄以及產(chǎn)品發(fā)布的整體完整性。本階段的風險包括:?2024云安全聯(lián)盟大中華區(qū)版權所有發(fā)布不正確或損壞的制品產(chǎn)品中引入不安全的環(huán)境配置劫持發(fā)布流程，引入未經(jīng)授權的變更3.5運行時防御和監(jiān)測運行時防御和監(jiān)測聚焦于在應用程序部署到生產(chǎn)環(huán)境后進行應用程序的安全管理。管理包括監(jiān)測違規(guī)或其他惡意和濫用行為指標，開展持續(xù)的安全測試，并檢測傳統(tǒng)或新發(fā)掘的漏洞。本階段的風險包括:業(yè)務邏輯攻擊拒絕服務或其他業(yè)務連續(xù)性攻擊新發(fā)掘的漏洞利用合規(guī)性監(jiān)控?2024云安全聯(lián)盟大中華區(qū)版權所有概述:設計部分參考了產(chǎn)品設計過程中可以應用的技術和流程。我們認為設計是連續(xù)的，所以可以通過設計激活新產(chǎn)品的特性和變化途徑。在設計階段未考慮安全設計的情況下，在部署或運行時導入安全措施將導致更高的操作影響和成本。導致檢測難以度量，形成影響開發(fā)速度和發(fā)布時間線的安全瓶頸。流程威脅模型一個結構化的過程，用于識別安全需求，在抽象層面上精確定位安全威脅和潛在漏洞，量化威脅并確定補救設計方式的優(yōu)先級。安全用戶故事安全功能需求陳述，確保軟件的許多不同安全屬性之一得到滿足。與功能作為故事相同的方式提出安全要求。安全故事可以劃分為開發(fā)人員任務，并在開發(fā)工作列表中進行優(yōu)先級排序。動態(tài)價值安全映射流程圖中的活動從需求到發(fā)布進行映射，以識別流程低效性和自動化機會。架構規(guī)范和工件使用和開發(fā)所有組織技術資源（包括IT、IoT和OT）的基本原則和目標。它們反映了企業(yè)各部門之間的共識水平，并構成了未來在技術、流程和人員方面決策和變更的基礎。風險管理（左移）產(chǎn)品團隊識別和有效描述產(chǎn)品風險（包括應用程序、組件、平臺和依賴資源）并實施改進以緩解或預防可能的負面事件的過程。優(yōu)點輸出?提高評審速度?更易于保持規(guī)模一致性?需要安全體系架構專業(yè)知識?以威脅為導向的體系架構設計?減少運營影響和對人員的評審依賴?安全要求和需求列表的優(yōu)?計劃和衡量安全工作/需求列先級表?按工作量/時間衡量安全工作?盡早了解風險和威脅?形成文件的原則、模式和方法?記錄設計風險和不可接受的風險場景圖4:設計和建筑師矩陣編程編程概述:可以在開發(fā)應用程序時應用的功能。編碼安全控制依賴于自動化，因為與人工評審相比，工具可以更好、更一致地識別代碼中的弱點和漏洞。如果在編碼階段不考慮安全性，就有可能出現(xiàn)源代碼中的漏洞并將其部署到生產(chǎn)環(huán)境中。在SDLC的后期階段，修復安全漏洞和弱點的成本將更高ActivityTechnoProce開發(fā)者測試由于需要高質量、安全的代碼，基于角色的安全培訓可以幫助開發(fā)人員在用各自語言編寫代碼時識別漏洞，而不會出現(xiàn)常見漏洞。容器加固通過更新包和查找不安全的默認配置和已知漏洞，解決了基礎鏡像和容器編排的弱點。它使新的黃金基礎鏡像能夠在流水線中安全使用。安全單元測試采用源代碼中可測試的小部分來確定安全控制的有效性。安全鉤子不論是代碼提交前或提交后，代碼提交到git存儲庫（git提交操作）將觸發(fā)腳本，自動識別代碼中的問題，比如識別源代碼中的敏感信息。代碼檢查集成開發(fā)環(huán)境的一種分析方法，用于標記編程錯誤、BUG以及風格和構造錯誤。軟件組成分析幫助識別和修復軟件產(chǎn)品的開源和第三方組件中的漏洞。SCA工具掃描應用程序代碼庫和工件存儲庫，以識別安全漏洞。靜態(tài)應用程序安全測試分析源代碼、字節(jié)碼和二進制文件，找出靜態(tài)代碼中的安全漏洞。它也被稱為靜態(tài)代碼分析或白盒測試?；A設施即代碼（IaC）分析使工程師能夠在執(zhí)行安全驗證檢查的同時對云基礎設施進行版本控制、部署和改進。這為主動改進云基礎設施的架構并盡早解決安全問題提供了機會。同行評審團隊成員的源代碼在被實現(xiàn)到代碼庫中之前由一個或多個人員進行評審。優(yōu)點輸出?2024云安全聯(lián)盟大中華區(qū)版權所有?盡早并經(jīng)常發(fā)現(xiàn)安全問題?增加了對代碼質量的反饋?縮短了修復漏洞的時間?預防危險代碼行為的安全檢查?代碼掃描僅涵蓋一小部分漏洞，不包括運行時問題或設計缺陷問題?可能會導致誤報。?通過SAST和SCA工具形成代碼報告?git存儲庫中的集成功能?具有安全意識的開發(fā)人員?開發(fā)工作流中嵌入的安全活動圖5：編碼矩陣?2024云安全聯(lián)盟大中華區(qū)版權所有集成和測試集成和測試概述:用于應用程序/產(chǎn)品功能安全測試的工具和流程。如果沒有這些工具和方法，安全漏洞和弱點將成為被利用的根源，并導致數(shù)據(jù)泄露和業(yè)務連續(xù)性問題。流程動態(tài)應用程序安全測試一種黑盒安全測試形式，通過模擬針對應用程序外部接口的外部攻擊來分析正在運行的應用程序以識別安全漏洞。交互式應用程序安全測試一種將SAST和DAST技術相結合的方法，用于掃描運行時的應用程序，同時也掃描單獨的代碼行。API測試一種將應用程序編程接口（API）作為通用消息傳遞流水線進行測試的方法，以確保功能不存在可被利用的弱點或漏洞。模糊測試一種自動化和動態(tài)的軟件測試技術，使用無效、意外或隨機數(shù)據(jù)作為應用程序或過程的輸入，以評估其響應和揭示安全缺陷。滲透測試一種針對網(wǎng)絡、系統(tǒng)或應用程序組件中發(fā)現(xiàn)的脆弱性的手動安全測試方法，以確定是否可以利用漏洞來危害環(huán)境中的資源、整個應用程序或其數(shù)據(jù)。容器測試利用攻擊方法針對容器基本鏡像和容器編排方法進行測試。完整性檢查在連續(xù)部署階段之前，對代碼制品和容器鏡像進行加密簽名并驗證其完整性的自動化過程。優(yōu)點輸出?在運行時發(fā)現(xiàn)安全問題?識別并解決集成過程中的安全問題?自動化流程，為開發(fā)人員提供更快的反饋?建立流程，使用安全測試工具編寫集成成本高?可證明的安全態(tài)勢保障?真實狀況的可報告內容圖6:集成和測試矩陣?2024云安全聯(lián)盟大中華區(qū)版權所有概述:部署前的安全檢查，以確保應用程序/產(chǎn)品部署到安全的基礎設施上。如果部署中未考慮安全性，可能導致應用程序/產(chǎn)品存在漏洞和缺乏安全實踐，發(fā)生在生產(chǎn)環(huán)境中被利用進行攻擊的風險。流程GitOps使用git存儲庫來管理基礎設施和應用程序代碼部署。在GitOps中，git存儲庫是部署狀態(tài)的事實來源，而不是服務器配置文件。護欄為構建云環(huán)境提供持續(xù)治理的高級規(guī)則。護欄是實施的預防性或檢測性控制措施，有助于管理資源并監(jiān)控跨資源的合規(guī)性環(huán)境隔離開發(fā)、測試、預生產(chǎn)和生產(chǎn)環(huán)境的邏輯分離和管理。秘密與密鑰管理用于管理數(shù)字身份驗證憑證（秘密）和加密密鑰信息的工具和方法。這包括用于應用程序、服務、特權帳戶的密碼、加密密鑰、API和令牌，以及用于身份驗證和加密使用的其他敏感憑據(jù)。CI/CD流水線防護通過記錄和監(jiān)測變更，并根據(jù)流水線狀態(tài)驗證CI/CD流水線的完整性。系統(tǒng)加固涉及保護服務器數(shù)據(jù)、端口、組件、功能和權限的過程。優(yōu)點輸出?快速安全的部署?托管服務的一致配置?建立安全控制的基線?建成后自給自足?需要對基礎架構和代碼的托管服務重新架構?部署代碼的安全配置流水線?安全配置的主機環(huán)境圖7：交付和部署矩陣?2024云安全聯(lián)盟大中華區(qū)版權所有運行時防御和監(jiān)測運行時防御和監(jiān)測概述:應用程序/產(chǎn)品發(fā)布到生產(chǎn)中后可以應用的功能和實踐。運行時安全性通過更好地識別效率低下、漏洞和弱點并啟用事件響應來實現(xiàn)持續(xù)改進。流程混沌工程測試分布式計算系統(tǒng)，以確保其能夠承受意外中斷。使用故障模式、影響分析或其他策略深入了解組織系統(tǒng)中的潛在故障云安全態(tài)勢管理識別云中的錯誤配置問題和合規(guī)風險。其重要目的之一是持續(xù)監(jiān)測云基礎設施的安全策略實施差距。性能管理收集、分析和標記日志數(shù)據(jù)的過程，以識別和響應應用程序和基礎設施上的事件和事故，同時識別指標、根本原因、趨勢和性能。攻擊面管理E外部攻擊面管理（EASM）識別并管理面向互聯(lián)網(wǎng)的資產(chǎn)和系統(tǒng)面臨的風險。這里指的是識別面向外部資產(chǎn)的工具。事后刨析用于確定項目失敗（或嚴重業(yè)務影響中斷）的原因以及未來的預防措施。旨在構建可降低未來風險的流程改進。紫隊網(wǎng)絡安全模擬是模擬網(wǎng)絡攻擊響應的一種測試技術和流程，通常需要一個仿制的環(huán)境來有效地“對抗”現(xiàn)實場景中的潛在攻擊。漏洞修復評估、處理和報告系統(tǒng)及其上運行的軟件中發(fā)現(xiàn)的安全脆弱性和錯誤配置的過程。事件響應準備、分析和響應事件的過程。優(yōu)點輸出?2024云安全聯(lián)盟大中華區(qū)版權所有?關注事件響應改進?持續(xù)監(jiān)測生產(chǎn)環(huán)境中的安全態(tài)勢?生成合規(guī)性指標的機會?將數(shù)據(jù)反饋至設計階段?建設流程代價高?基礎設施托管環(huán)境情況的持續(xù)報告?優(yōu)化事件響應準備?用于提升安全性和性能管理的有意義的數(shù)據(jù)和指標圖8：運行時防御與監(jiān)控矩陣?2024云安全聯(lián)盟大中華區(qū)版權所有4設計和架構設計部分可以涉及在產(chǎn)品設計過程中應用的技術和工具。由于設計是持續(xù)進行的，因此通過設計可以對新的產(chǎn)品功能和變進行處理。如果在設計階段不考慮安全性，那么在部署或運行時產(chǎn)生的安全措施將帶來更高的運營和成本影響。因此，這些安全措施將難以擴展，從而導致安全瓶頸，降低開發(fā)速度并影響發(fā)布時間。4.1威脅建模威脅建模是一種技術，是用來識別和概述，計劃的或現(xiàn)有的系統(tǒng)或應用程序的關鍵威脅、攻擊向量以及預防措施的技術。威脅建模的目的是:識別、分析和評估安全威脅制定緩解措施的優(yōu)先級協(xié)助并報告攻擊面的分析以及降低風險以下是《CSA云威脅建?！分刑岬降暮诵耐{建?；顒?1.為威脅建?；顒哟_定威脅建模安全目標，重點關注保密性、完整性、可用性和隱私等關鍵方面，例如：a.保護公司數(shù)據(jù)庫中客戶或受監(jiān)管的信息不受外部攻擊者的影響;?2024云安全聯(lián)盟大中華區(qū)版權所有b.確保電子商務網(wǎng)絡應用程序的高可用性c.選擇具有最小攻擊面或客戶安全責任最小的云應用模式。2.根據(jù)提供的系統(tǒng)或云應用的綜述，設定有關考慮中的系統(tǒng)和/或云基礎設施的評估范圍。通常涵蓋各種組織資產(chǎn)等領域，包括所使用的技術棧、現(xiàn)有的安全控制、部署方案、用戶類型，以及任何在威脅建模中需要解決的特定安全要求或監(jiān)管要求。3.系統(tǒng)或應用程序可分解為各子系統(tǒng)，并檢查各個組件之間的交互。這一階段的關鍵活動包括:a.理解信任邊界（面向外部和內部的、特權的、未經(jīng)認證的，等等）。b.確認系統(tǒng)的輸入和輸出以及數(shù)據(jù)格式。c.繪制系統(tǒng)中的數(shù)據(jù)流4.識別和評估潛在的威脅、攻擊類型以及惡意用戶如何濫用給定的系統(tǒng)或其功能。根據(jù)OWASPTop10的調查結果，可用于確保威脅建?；顒又锌紤]到最關鍵的安全風險。一些常見的威脅是未授權訪問、拒絕服務、信息泄露等。STRIDE可對威脅進行分類，DREAD框架可對威脅的嚴重性進行評估。MITRE的ATT&CK?框架可以幫助了解檢測和緩解行動的準備情況和有效5.識別系統(tǒng)設計和組件中的弱點和漏洞，以幫助安全決策并定義安全測試的范圍和性質。6.設計并優(yōu)先考慮適用于預先確定的威脅的緩解措施和控制措施，并思考這些控制措施如何降低威脅或風險水平。7.溝通已確定的威脅、潛在影響和嚴重性，以及適用和建議的控制措施。提供建模數(shù)據(jù)和洞察力，并呼吁通過設計或影響來緩解威脅的行動。?2024云安全聯(lián)盟大中華區(qū)版權所有組織通過威脅建模獲得對設計實施早期和經(jīng)常評審的好處，解決方案設計階段初期，就可以設計富有成效的決策（包括技術采購和包括產(chǎn)品功能的決策）。對解決方案進行專題評審并確定控制攻擊技術的機制的能力有助于優(yōu)化安全解決方案，同樣也使產(chǎn)品團隊的相關利益者能在編碼期間完成改善工作。可以通過工具來實現(xiàn)威脅建模，該工具將威脅通過數(shù)字化的方式記錄在架構圖中。在某些情況下，可以自動識別威脅方法。然而，威脅建模最常見的方式，是通過對分析目標關鍵系統(tǒng)的意圖，以人工評審的方式進行建模；基于對目標系統(tǒng)的了解，必須對數(shù)據(jù)流和數(shù)據(jù)流中組件之間的信任邊界進行建模。雖然隱私設計超出了本文的范圍，但威脅建模活動是將隱私設計評審納入產(chǎn)品的有效方法。根據(jù)產(chǎn)品類型，組織的地理位置和司法管轄范圍不同，法規(guī)要求（如GDPR）將需要組織證明其對個人數(shù)據(jù)和醫(yī)療數(shù)據(jù)的處置、使用和存儲的合規(guī)性（如：數(shù)據(jù)處理協(xié)議、數(shù)據(jù)隱私影響評估）。組織通?？梢赃x擇商業(yè)版的供應商來實現(xiàn)威脅模型自動化。這方面的例子有IRIUSRisk和ThreatModeler，而OWASPThreatDragon和Cairis是開源方案的例子。4.2安全用戶故事安全用戶故事（SecurityUserStories）是對安全功能的陳述，確保軟件的許多不同的安全屬性得到滿足?？梢允褂霉ぞ呋蛴行У牧鞒虂泶_定安全需求，定義新功能或對現(xiàn)有功能的補充，解決特定的安全問題或修復漏洞。為軟件開發(fā)人員/工程師建立安全用戶故事是將安全融入軟件開發(fā)的有效方法?？梢詤⒖棘F(xiàn)有的安全合規(guī)要求、組織政策、行業(yè)準則和標準，實現(xiàn)則需要項目利益相關方之間的協(xié)作。像INVEST8這樣的方法可以幫助支持?2024云安全聯(lián)盟大中華區(qū)版權所有創(chuàng)建安全用戶故事和任務，每個故事和任務應該具備以下特點:在安全和開發(fā)之間建立的橋梁不應該是單向的。安全政策應該被嚴格映射到開發(fā)人員和運維人員可以完成的技術故事范圍內。軟件開發(fā)人員、DevOps工程師和架構師應該提供完成狀態(tài)的反饋，以便編寫信息安全政策的安全合規(guī)團隊有能力了解當前軟件生命周期階段/迭代的安全狀況。創(chuàng)建安全模型和加固指南將支持安全合規(guī)活動。雖然安全用戶故事可以更好地向業(yè)務利益相關方證明：代碼的設計和配置都有組織批準的安全控制，但也可以通過工作量和時間來衡量活動，使安全工作在代辦事項中得到優(yōu)先安排。安全故事通常是根據(jù)組織的政策手動編制。在不考慮政策與產(chǎn)品開發(fā)的情況下，OWASP應用安全驗證標準可用于應用安全的要求，CSACCM可有效建立云安全需求。然而，自動化安全故事流程的機會（例如，SDElements）可能無法解決組織政策調整和工作優(yōu)先級的問題。4.3價值流安全映射價值流安全圖（valuestreamsecuritymap）將描述從產(chǎn)品開發(fā)的想法是如何傳遞給到客戶的。對工作的可見性代表了團隊對業(yè)務到客戶的工作流程的理解程度，以及他們是否對這一流程有可見，包括產(chǎn)品和功能的特性。?2024云安全聯(lián)盟大中華區(qū)版權所有在考慮安全控制之前，了解應用程序開發(fā)生命周期中的工作流程是很重要的。VSSM作為一個有用的工具，包括以下內容:利益相關方：負有責任的團隊和個人活動：在階段中執(zhí)行的能用活動前置時間：從上游流程接受工作到將該工作完成移交給下游流程的時間流程時間：如果執(zhí)行人員擁有完成工作所需的必要信息和資源，并能連續(xù)完成工作；那么完成單項工作所需的時間完整和準確度（%C/A從上游過程收到，可以直接使用而無需返工的比例圖9：VSSM示例可以按照以下方式創(chuàng)建VSSM9:1.識別問題：從客戶的角度來定義問題。記錄問題。2.呈現(xiàn)問題：確保所有團隊成員理解問題。將相關內容的理解和一致性記錄文檔。?2024云安全聯(lián)盟大中華區(qū)版權所有4.賦予團隊權力：為團隊提供解決問題所需的權限和資源。5.進行走查：對復雜的過程進行走查，確保對步驟和環(huán)境的理解，并建立共同的目標。7.設定流程限制：建立流程的限制措施/指標，以確保和維護適當?shù)姆秶?.收集數(shù)據(jù)-收集/分析數(shù)據(jù)-數(shù)據(jù)包括資產(chǎn)、資源、循環(huán)時間、提前置時間和正常運行時間9.繪制當前流程圖：前幾個步驟代表了當前的狀態(tài)，并作為一個基線。10.繪制未來流程圖：接下來，明確需要完成的目標，并將其映射到當前的流程中。11.實施未來地圖：未來流程圖可用于指導改進過程，為團隊成員提供有針對性的目標，需要采取分階段的方法來實施改進。價值流圖提供了一系列業(yè)界廣泛接受的優(yōu)點。同時，安全工作的整合提供了額外的好處,1011:端到端的安全性和可見性影響產(chǎn)品開發(fā)更好地將DevSecOps與業(yè)務和時間目標聯(lián)系起來，提供更好的決策信息在決定加入或移除安全工具和流程時，不同的利益相關者之間可以進行更好的合作，以獲得更快的反饋識別安全瓶頸和限制性過強的耗時任務，可在不同的價值流階段進行更好的優(yōu)化雖然價值流安全圖活動通常是手動和本地執(zhí)行（如使用Atlassian軟件對單個項目而言，也可以選擇商業(yè)供應商（如LeanIX,Plandek,HCLtech）?2024云安全聯(lián)盟大中華區(qū)版權所有提供技術平臺來創(chuàng)建和管理價值流圖。4.4架構原則和制品架構原則和制品是所有組織技術資源的基礎性通用原則、目標和實踐。架構原則反映了某種程度的共識，并形成了對技術、流程和人員進行未來決策和變更的基礎。DevSecOps的架構原則有助于規(guī)劃創(chuàng)建工作模式，用于構建安全和批準的解決方案的指導方針，以及對團隊拓撲的有效理解。遵循這些方法和模式，可以重新設計人們構建產(chǎn)品的方式，以避免漏洞的引入，并檢測和防止可能危及產(chǎn)品安全的錯誤。DevSecOps的原則因組織而異，但應該與業(yè)務目標保持一致，同時補充來自軟件開發(fā)的目標價值。DevSecOps是DevOps的進化，應該重視速度和自動化的價值。它通過體現(xiàn)注重速度、創(chuàng)新和協(xié)作的價值觀，消除安全門和耗時的活動。以下是建立一個有效的DevSecOps基礎的一些共同原則:最小可行的安全產(chǎn)品：實施安全控制和流程的基線——組織開發(fā)的每個產(chǎn)品都應該達到的最低門檻。最小可行安全產(chǎn)品提供了一個如何實現(xiàn)這一目標的檢查清單的例子。但是，最小可行安全產(chǎn)品應該比檢查表更多，并告知組織建立有效的基線，進一步完善和構建產(chǎn)品的安全功能。安全是產(chǎn)品功能：一種將安全功能作為產(chǎn)品特性引入以提高安全性的方法。產(chǎn)品團隊和解決方案可以解決風險和威脅，而不是在開發(fā)末期的預部署階段添加安全解決方案。安全用戶故事提供了一個幫助實現(xiàn)這一目標的示例方法。實現(xiàn)依賴于關鍵利益相關方的支持。安全是集體的責任：在DevOps的文化中，開發(fā)人員和運維人員對于他們構建和管理的軟件有共同的理解和共同的責任。這意味著在開發(fā)、IT/運維和"業(yè)務"12之間增加透明度、溝通和協(xié)作。安全不應該認為僅僅是安全團隊的責任。所有利益相關者都應該承擔起構建和管理服務的安全責任。有關實施的信息，請參見CSAPillar1:CollectiveResponsibility.?2024云安全聯(lián)盟大中華區(qū)版權所有上述三項原則被視為基礎性原則。除此以外的原則需要與組織的目標、團隊結構、預算、IT環(huán)境和架構相關。為了解一整套DevSecOps原則的例子，美國國防部發(fā)布了一個DevSecOps參考架構指南13，其中概述了以下內容:消除瓶頸（包括人為因素）和手動操作。開發(fā)和部署活動盡可能自動化。從規(guī)劃和需求到部署和運維，采用通用工具。倡導敏捷的軟件原則，支持小型的、漸進的、頻繁的更新，而不是大型的、間歇性的發(fā)布。在整個SDLC過程中將應用跨職能的技能組合應用于開發(fā)、網(wǎng)絡安全和運維等，采用并行的持續(xù)監(jiān)控方法，而不是按順序應用每種技能組合。必須對底層基礎設施的安全風險進行測量和量化，以了解總體風險和對軟件應用的影響。部署不可變基礎設施，如容器。不可變基礎設施的概念是一種IT戰(zhàn)略，其中部署的組件被整體替換，而不是原地更新。部署不可變基礎設施需要通用基礎設施組件的標準化和仿真，以實現(xiàn)一致和可預測的結果。除了基本的DevSecOps原則外，還應該認識到DevSecOps原則應該囊括業(yè)界在DevOps和云計算中所宣揚的內容。AWS認可5個關鍵原則14，這些原則構成了其良好的云架構框架的一部分:以代碼方式進行運維：在云中，應用程序代碼的工程紀律也可以應用于基礎設施。整個工作負載（應用程序、基礎設施）可以作為代碼部署，并通過代碼更新。操作流程可以作為代碼實現(xiàn)，并通過響應事件的觸發(fā)來實現(xiàn)自?2024云安全聯(lián)盟大中華區(qū)版權所有動化，這減少了人為錯誤，通過以代碼方式進行運維，可以實現(xiàn)對事件的一致性響應。進行頻繁的、小型的、可回退的變更：設計工作負載，允許組件定期更新，以小幅增量進行變更，如果變更失敗，則可以回退（盡量不影響客戶）。經(jīng)常完善操作程序：在使用過程中改進操作程序，隨著工作負載的變化，適當?shù)馗倪M程序。定期評審和檢驗程序是否有效，以及團隊對這些程序的熟悉程度。故障預測：執(zhí)行“預檢”演習，以確定潛在的故障源，從而消除或減輕它們的影響。測試故障場景并驗證對影響的理解。測試響應流程，以確保它們有效，并確保團隊熟悉它們的執(zhí)行操作。設置定期的演練，測試工作負載和團隊對模擬事件的響應。從所有操作失敗中吸取教訓：通過從所有操作事故和故障中吸取的教訓推動改進。在團隊和整個組織中分享所學的知識。谷歌云15還推薦了一套云原生架構的原則:自動化設計：自動化一直是軟件系統(tǒng)的最佳實踐。盡管如此，云比以往任何時候都更容易自動化其上的基礎設施和組件。盡管前期投資較高，但在工作量、彈性和性能方面，支持自動化解決方案幾乎總是會在中期得到回報。自動化流程可以比人更快的修復、擴展和部署系統(tǒng)。智能處理狀態(tài)：存儲“狀態(tài)”，無論是用戶數(shù)據(jù)（例如，用戶購物車中的項目，或員工編號）還是系統(tǒng)狀態(tài)（例如，正在運行的作業(yè)實例數(shù)量，在生產(chǎn)中運行的代碼版本都是構建分布式云原生架構的最困難方面。因此，設計系統(tǒng)時要故意考慮存儲和設計組件的無狀態(tài)性。選擇托管服務：云不僅僅是基礎設施，大多數(shù)云提供商都提供豐富的托?2024云安全聯(lián)盟大中華區(qū)版權所有管服務集合，提供各種功能，以解決管理后端軟件或基礎設施的困擾。然而，需要組織對利用這些服務持謹慎態(tài)度，因為他們擔心被“鎖定”在指定供應商。這個擔憂是有道理的，但托管服務商通?？梢詾榻M織節(jié)省大量的時間和運營開銷。是否采用托管服務歸結于可移植性與資金和技能方面的操作開銷。踐行深度防御：傳統(tǒng)架構對周邊安全充滿信心，簡單地說是一個加固的網(wǎng)絡邊界，內部有“可信的東西”，外部有“不可信的東西”。不幸的是，這一方法一直很容易受到內部攻擊和外部威脅的影響，如魚叉式網(wǎng)絡釣魚。此外，提供靈活和移動辦公的壓力越來越大，進一步破壞了網(wǎng)絡邊界。架構是根本：云原生系統(tǒng)的核心特征之一是他總是在不斷發(fā)展，架構也是如此。隨著組織的需求、IT環(huán)境和云提供商的變化，始終尋求完善、簡化和改進系統(tǒng)的體系結構。雖然原則可以讓人感覺像高級抽象的語句，但通過原則對業(yè)務目標進行技術和安全目標的識別和映射是有價值的。在DevSecOps活動中盡早定義原則，以產(chǎn)生以下好處:難以掌握的復雜技術環(huán)境中，建立原則有助于揭開衡量成功所需完成的工作的神秘面紗它們構成了一個與業(yè)務目標相關聯(lián)的連接目標，并可由高級業(yè)務利益相關者評審它們可被用作指導未來決策和技術、人員和流程變革的指南它們可以鏈接到敏捷儀式和實踐它們可以鏈接到花費時間的日常運營工作團隊除了美國國防部（DoD）、亞馬遜網(wǎng)絡服務（AWS）和谷歌云引用的DevSecOps和云安全原則之外，還可以從NCSC的云安全原則和Grafana的云原生安全宣言中找到更多示例。?2024云安全聯(lián)盟大中華區(qū)版權所有4.5風險管理（左移）產(chǎn)品團隊識別和有效描述產(chǎn)品風險（包括應用程序、組件、平臺和依賴資源并實施改進以緩解或防止可能出現(xiàn)的負面事件。雖然風險識別和評估應該盡早的在開發(fā)過程的設計階段進行，但在某些情況下，隨著時間的推移，可能會出現(xiàn)新的風險。形成風險聲明的能力在描述安全問題和確定工作優(yōu)先級方面非常重要。在DevSecOps和現(xiàn)代軟件開發(fā)范式中，風險表達將在操作上有效，參考威脅（在威脅建模中識別）以及可利用的漏洞類型，請參見圖11。務實的決定是通過確定工作的優(yōu)先級和形成風險聲明的能力做出的，其中包括以下領域:資產(chǎn):受保護的資產(chǎn)類型，范圍從客戶數(shù)據(jù)到知識產(chǎn)權（IP以及客戶是否受到影響。威脅:：威脅類型被視為內部威脅，如惡意內部人員或外部威脅，如高級可持續(xù)威脅(APT)。漏洞:應考慮評估哪些漏洞可被利用執(zhí)行威脅攻擊（例如，遠程代碼執(zhí)行、代碼注入、逆向工程）。補償控制（即誘發(fā)條件）:評估和枚舉現(xiàn)有的緩解措施，例如分割網(wǎng)?2024云安全聯(lián)盟大中華區(qū)版權所有絡的防火墻、Web框架或產(chǎn)品界面的輸入過濾功能、二進制混淆。描述風險:影響是通過考慮受保護的資產(chǎn)類型和威脅（例如，知識產(chǎn)權和數(shù)據(jù)泄露）獲得的。而可能性則考慮影響被利用的可能性（例如，通過一個漏洞）和潛在的緩解措施（例如，在內部防火墻網(wǎng)絡的服務器端請求偽造（SSRF。然舉例的風險框架受組織、行業(yè)部門和地理位置的影響，但這些材料A?2024云安全聯(lián)盟大中華區(qū)版權所有可以作為應用程序應用的功能正在開發(fā)中。與手動人工評審相比，對依賴自動化作為工具的安全控制進行編碼，可以更好、更一致地識別代碼中的弱點和漏洞。如果不在編碼階段考慮安全性，在源代碼中的漏洞將無法識別并部署到生產(chǎn)環(huán)境中。安全漏洞和弱點在SDLC延后的修復成本將會更高。5.1對開發(fā)人員培訓對開發(fā)人員進行培訓可以為開發(fā)團隊提供責任、充分的培訓、工具和資源，以驗證軟件設計和實施是安全的。由于要求將代碼安全作為安全系統(tǒng)生命周期的一部分，充分的安全編碼培訓有助于開發(fā)人員在用各自語言編寫安全代碼時識別錯誤。這將引入漏洞和設計缺陷的風險降至最低研究表明，161718開發(fā)人員通常是自學成才的，這導致超過50%的軟件開發(fā)人員缺乏安全編碼意識和技能。即使開發(fā)人員受過一些軟件工程方面的教育，該課程通常也不包括安全編碼實踐。這種培訓缺失導致SDLC中常出現(xiàn)不安全的編碼實踐和常見的應用程序漏洞。開發(fā)人員培訓的有效先決條件是評估安全SDLC的成熟度和相應的安全編碼實踐。為了成功實現(xiàn)和實施開發(fā)人員培訓，其側重于與每個開發(fā)團隊成員相關聯(lián)的角色和責任。對于開發(fā)人員培訓的任何情況，成功的實施是通過游戲化培訓體驗來為完成的培訓提供獎勵，從而激勵實際進行培訓。此外，此類培訓包括與開發(fā)人員正在使用的技術和平臺相匹配的指導和實例培訓。培訓有多種形式，主要的問題將在下文中進行討論。講師主導的培訓：講師主導的培訓是在實踐中采用在線或面對面的為一群開發(fā)人員提供教育的方式。該培訓的優(yōu)勢是可以實時與講師進行反饋和討論。這種培訓在使用引人入勝的演示時尤其有效，特別是講解如何利用特定的漏洞。這有助于開發(fā)人員了解攻擊者是什么，并使他們了解為什么需要輸入驗證和過濾，以及如果代碼未按預期運行，可能產(chǎn)生的影響。SAFECode通過按需網(wǎng)絡廣播?2024云安全聯(lián)盟大中華區(qū)版權所有提供在線社區(qū)資源，通過按需提供軟件安全方面的講師主導的開發(fā)人員培訓。OWASP安全知識框架（SKF）提供了一些實用的安全編碼示例，用于講師主導的培訓。在線培訓：開發(fā)人員有時間參加的一種在線培訓形式。這種方法適用于更高級的形式，允許參加課程的人在需要時反復復習材料。OWASP果汁商店（OWASPJuiceShop）是一個不安全的web應用程序，可用于安全培訓和CTF意識演示。OWASP果汁商店還包含安全編碼挑戰(zhàn)，特別是針對安全編碼開發(fā)人員的培訓。此外，開放安全基金會（OpenSSF）通過Linux培訓和認證平臺為軟件開發(fā)人員提供了關于安全編碼的免費課程19。安全編碼培訓的一個商業(yè)解決方案是安全代碼戰(zhàn)士，它提供了一個電子學習平臺，包括培訓、錦標賽和基于技能的途徑評估。安全意識培訓：安全意識培訓旨在向最終用戶提供有關當前威脅、安全最佳實踐和政策預期的信息。然而，事實證明，僅僅依靠安全意識的年度培訓是無效的，尤其是在建安全編碼實踐方面20。相反，有效的安全意識培訓針對的角色是開發(fā)人員。像SANSWeb應用程序安全意識培訓這樣的組織提供基于角色和循序漸進的專業(yè)培訓。指導：指導是開發(fā)人員培訓的一種有效形式，因為它通常鼓勵團隊中的開發(fā)人員掌握安全實踐。一種形式的指導是通過安全倡導者計劃正式形成的，安全團隊與提名的安全捍衛(wèi)者切合作，就安全漏洞和安全編碼實踐教育其他開發(fā)人員。OWASP安全文化項目和OWASP安全捍衛(wèi)者行動手冊提供了一個逐步建立安全捍衛(wèi)者計劃的過程，該計劃側重于安全團隊，為開發(fā)團隊中選定的安全捍衛(wèi)者提供指導。利用上文提到的對開發(fā)人員的培訓組合提供了幾個好處。研究21表明，開發(fā)人員所受到的安全培訓水平與整個軟件開發(fā)團隊的安全意識呈正相關。有效的開發(fā)人員培訓還使開發(fā)人員能夠更快地生成安全代碼，并防止在安全系統(tǒng)開發(fā)生命周期的設計和實施階段引入常見的安全漏洞。?2024云安全聯(lián)盟大中華區(qū)版權所有5.2安全鉤子（Hook）Git鉤子腳本對于在代碼評審之前識別代碼中的常見問題非常有用。開發(fā)人員經(jīng)常使用這些鉤子來防止在代碼庫中引入輕微的錯誤，例如缺少分號、明文密碼或尾隨空格。當使用敏感信息掃描工具檢測到安全憑據(jù)時，甚至在與通用軟件應用程序安全測試規(guī)則匹配之后，安全鉤子腳本也可以阻止提交。Git安全鉤子可以在Git工作流的任何階段設置。然而，它們通常在提交前和提交后階段被觀察到，見圖12。Git工作流中可以應用鉤子的其他階段包括:預提交預推合并前提交準備消息提交提交消息提交后檢出后合并后后期重寫?2024云安全聯(lián)盟大中華區(qū)版權所有圖12:GitHooks鉤子需要注意的是，git安全鉤子不能替代其他持續(xù)集成安全測試方法，原因有如下兩個:1.開發(fā)人員的時間很寶貴，他們可能一天會多次提交或推送，雖然安全鉤子可以防止引入明顯的安全問題，例如代碼庫中的憑據(jù)泄露，但它們不應該占用幾秒鐘到最多一分鐘的時間來阻礙開發(fā)工作流程。2.對于非容器標準化的開發(fā)環(huán)境，不能保證鉤子會像在這樣的場景中那樣正確配置；這種控制的設置將基于信任和開發(fā)人員的選擇。雖然安全鉤子可以有效地捕捉開發(fā)人員的錯誤，但工具還沒有成熟到可以進行完整的代碼掃描?？梢栽贕it-scm和預提交上找到一些安全鉤子的示例。5.3代碼檢查（linting）代碼檢查被定義為自動檢查源代碼的“壞代碼氣味（不良代碼）”，以標記代碼錯誤、bug、風格和構造錯誤22.鏈接工具是靜態(tài)代碼分析的一種基本?2024云安全聯(lián)盟大中華區(qū)版權所有方式。鏈接工具通常作為可配置的插件提供，用于識別和報告錯誤代碼的誤用或不良代碼的模式。鏈接工具和高級靜態(tài)分析工具之間的界限是模糊的。鏈接工具是多種多樣的，并且是限定于特定的編程語言，特別是開發(fā)團隊在集成開發(fā)環(huán)境（IDE）中作為插件或在代碼提交鉤子期間使用。一種實用的方法是為編碼語言仔細選擇一個鏈接工具23。在選擇代碼鏈接工具時，必須找到并僅選擇一個鏈接工具以減少冗長。此外，還必須確保鏈接工具充分支持使用該鏈接工具的編程語言。鏈接工具還可以獨立運行，并構建允許自定義擴展和API支持的集成工具。代碼鏈接是一種特別有效的應用領域，是強制執(zhí)行安全編碼標準、機密（隱私）檢測、失效代碼構造檢測。另一個被證明有用的領域是檢測循環(huán)復雜性，這驗證了程序的復雜性，因此也查驗了程序的可讀性和可維護性。當前有各種鏈接工具可以使用，其中大多數(shù)限定于一個特定編程語言，概要介紹如下:Java:CheckStyle24是JAVA的一個鏈接器，可以用于鏈接分析和靜態(tài)代碼分析。它是一個專注于為Java開發(fā)人員遵循編碼標準的工具。Checkstyle同時也是一種開發(fā)工具，可以幫助程序員編寫符合編碼標準的Java代碼，包括安全代碼。Python:Bandit29并不是一個嚴格意義上的鏈接器，它是?2024云安全聯(lián)盟大中華區(qū)版權所有分析工具，旨在檢測Python代碼中的常見安全問題.外，它還支持其他語言，如Scala、Ap總體而言，代碼鏈接器有很多好處并提高安全效率。使用代碼鏈接器的一個主要優(yōu)點是所見即所得，能在編寫代碼時立刻向開發(fā)人員提供反饋。鏈接器可以檢測代碼中可能會導致安全缺陷的錯誤，特別是它可以告知開發(fā)人員，哪些是不推薦、易受攻擊的類和方法，并減少使用有漏洞軟件組件的風險。鏈接器對于減少錯誤和提高整體質量很重要，它有助于加快開發(fā)速度，并通過在開發(fā)人員編寫源代碼時發(fā)現(xiàn)錯誤以降低成本。鏈接器可以掃描代碼的安全缺陷、格式化或樣式化問題等最佳實踐，使代碼更容易維護和閱讀。鏈接器提高了代碼的質量，從而減少了開發(fā)人員導入安全缺陷的可能性。由于開發(fā)人員更容易理解代碼，可讀的代碼也能使代碼更安全。當配置正確時，鏈接器允許強制執(zhí)行安全編碼標準，特別是應用于錯誤和異常處理的代碼編然而，需要指出的是，并不是每種語言都有“高質量”的標準鏈接器工具，因為每個框架通常都有一個或幾個鏈接器。此外，鏈接器的情況不同，鏈接工具、版本或配置可能會導致不同的結果。代碼鏈接還會因其冗長而導致誤報和信息過載。5.4軟件組成分析在構建現(xiàn)代應用程序時，獲得開發(fā)速度的一個關鍵方法是利用開源或第三方的組件。然而，使用這些組件會帶來諸如安全漏洞、許可義務和潛在代碼質量問題等風險。軟件組合分析（SCA）是組件分析的一個子集，是一個過程和一套工具，用于識別、糾正開源和第三方軟件產(chǎn)品或應用程序組件所帶來的風險。?2024云安全聯(lián)盟大中華區(qū)版權所有SCA工具為團隊提供了整個應用程序的可視性，并能夠創(chuàng)建和強制執(zhí)行安全策略，以減輕使用這些組件所引入的風險。SCA工具可幫助開發(fā)人員檢測并修復開發(fā)環(huán)境和CI/CD流水線中的問題。它們通常在代碼提交到源代碼庫（SCR）后作為代碼安全掃描工具來部署，因為SCA不需要在運行時掃描代碼。通常情況下，SCA工具具有以下優(yōu)點:持續(xù)掃描代碼庫(例如源代碼、二進制文件、包管理器、清單、容器映像、無服務函數(shù))，并創(chuàng)建/維護所使用的開源組件和第三方組件的清單。該庫存可以作為軟件物料清單(SBOM)的起點。CycloneDX和SPDX是兩種主要的SBOM格式。將軟件BOM清單（主要是軟件名、版本號）與國家漏洞數(shù)據(jù)庫(NVD)等數(shù)據(jù)庫進行比對，以識別是否存在漏洞。提供關于組件許可要求的信息，包括歸屬權。使治理團隊能夠制定一套適用于整個公司的開源和第三方組件使用策在整個SDLC過程中自動執(zhí)行策略（例如，當違反策略時構建失敗，檢查開發(fā)人員IDE中的漏洞，以及觸發(fā)新開源或第三方組件的審批流程）。SCA解決方案是自動化的，并且可以作為開源或許可產(chǎn)品提供。開源SCA工具的一個例子是OWASP依賴項檢查（OWASPDependencyCheck）、OWASP依賴項跟蹤（OWASPDependencyTrack）。許可證信息由Synopsys、Snyk、Dependabot和Veracode等供應商提供。5.5靜態(tài)應用程序安全測試靜態(tài)應用安全測試（SAST）是一種分析源代碼以發(fā)現(xiàn)安全缺陷和漏洞的方法和工具。SAST也被稱為“白盒”安全測試。SAST幫助開發(fā)人員識別編碼階段的漏洞，為他們提供實時反饋，使他們能夠在這些漏洞進入?2024云安全聯(lián)盟大中華區(qū)版權所有SDLC的下一個階段之前修復問題。NIST源代碼安全分析工具功能規(guī)范v1.131規(guī)定了SAST工具必須檢測的源代碼漏洞類別應包括：輸入驗證、范圍錯誤、API濫用、安全特征、時間和狀態(tài)、代碼質量和封裝。由于SAST工具被設計在編譯之前掃描源代碼，因此它提供了更早執(zhí)行安全掃描的機會，即安全左移。SAST掃描既可以在代碼提交到SCR時手動啟動，最常見的情況下也可以在自動流水線操作時觸發(fā)。建立一個良好的SAST流程包括:10.在相應的開發(fā)環(huán)境中明確SAST工具，這些工具應該支持開發(fā)環(huán)境的編程語言、庫/框架和二進制文件。它必須能夠檢測OWASP的前十位和/或NIST規(guī)范附件A所中列舉的漏洞。11.在各自的開發(fā)組織中部署SAST工具，作為基礎設施集成在IDE和CI/CD流水線中以便訪問和使用。12.SAST掃描可以在IDE中運行，也可以在CI過程的不同階段（例如，預編碼check-ins、post-commit）運行。13.分析掃描結果以消除誤報。如果在CI/CD流水線中檢測到這些問題，則應停止下一步執(zhí)行，并將這些問題記錄在中央存儲庫中。?2024云安全聯(lián)盟大中華區(qū)版權所有SAST工具可以很好地擴展；它們可以針對源代碼重復執(zhí)行（例如，check-ins、nightlybuilds）。他們可以通過反饋來識別大量的源代碼漏洞，通過在SDLC中更早地捕獲漏洞，可以節(jié)省時間和精力。這些工具可以指出源代碼中漏洞的位置，并指導其修復問題。SAST工具也有可能導致許多誤報，即該工具在不存在缺陷的情況下報告缺陷。通過分析測試結果和調整工具的策略/配置可以改善誤報率。雖然SAST工具是有效的，但它們難以應對某些類別的漏洞(例如，身份驗證和訪問控制問題)，特別是與環(huán)境、配置和運行時相關的問題。這可以通過采用動態(tài)應用安全測試(DAST)來補救，因為SAST和DAST是相輔相成的。參見圖13。?2024云安全聯(lián)盟大中華區(qū)版權所有SASTvs.DAST?2024云安全聯(lián)盟大中華區(qū)版權所有雖然SAST可以由安全工程師手動執(zhí)行，但與自動化SAST解決方案相比，手動評審代碼的工作量太大且無法保證質量。雖然SAST工具的選擇取決于語言支持和誤報量，但Synopsys、Veracode和MicroFocus是許可產(chǎn)品的流行示例。OWASP社區(qū)還提供了業(yè)界推薦的開源和商業(yè)工具列表。5.6容器強化容器化應用程序和微服務架構(每個微服務都被容器化)是一種常見的組合。這是因為容器為快速和可重復的開發(fā)提供了一個平臺，并促進了相同基礎設施內的依賴關系管理，減少了應用程序多租戶影響和潛在依賴沖突。一般來說，容器成為啟用DevSecOps工作流的關鍵。容器可以理解為與計算機中其他進程隔離的進程33。容器隔離與虛擬機及其管理程序提供的隔離不同，理解這一點很重要。因此，在某些情況下，容器化應用比虛擬機的攻擊面可能會更大。因此，容器安全與虛擬化安全的處理方式會有很大區(qū)別每當使用容器時，考慮容器編排的概念非常重要（例如Kubernetes34、Nomad35、OpenShift36）。這種類型的軟件允許控制（或編排）數(shù)百個容器，從而使配置、資源調度、網(wǎng)絡、隔離和安全配置在某種程度上被集中起來，變得更容易管理。然而，使用編排器通常會在系統(tǒng)中引入額外的復雜層，這需要進行管理并考慮其安全性。安全考慮因素反映了需要加固的容器區(qū)域，以下是容器加固的安全原則:37最小權限：應限定容器運行時所需的最小化權限集。縱深防御：當應用縱深防御時，容器會成為一個額外的附加層。減少攻擊面：必須考慮容器編排層內的平衡和微服務架構的簡單性。這是因為容器化微服務體系結構可以提高簡單性。諸如Kubernetes這樣的容器編排器增加了一層復雜性。?2024云安全聯(lián)盟大中華區(qū)版權所有限制影響范圍：確保被破壞（入侵）的容器不會影響到其他系統(tǒng)部件，這對于限制影響范圍至關重要。職責分離：需要根據(jù)特定的職責分離策略授予權限和憑證，這意味著駭?shù)粢粋€容器不會讓黑客獲得系統(tǒng)內其他的資源和秘密。有幾個容器加固的指南。例如CISDocker基準38，美國國防部容器加固程序39和美國國家安全局Kubernetes強化指南。40基于此，我們確定了以下常見的重點關注方面：容器隔離、容器網(wǎng)絡、容器鏡像安全和容器編排安全性。容器隔離：確保容器正確隔離，對于確保容器不會危害主機(承載容器的機器)至關重要。這意味著要考慮以下實際因素:特權容器擁有對主機中所有設備的root訪問權限。這意味著如果您是容器中的root用戶，那么您實際上是主機中的root訪問權限。因此應謹慎對待特權容器。功能41允許Linux對進程在系統(tǒng)中執(zhí)行某些操作所需的不同權限進行細粒度控制。容器通常被分配了比他們需要的更多的功能。因此請確保您使用的容器時僅具有所需的已啟用功能。已掛載得卷允許容器訪問主機內的存儲。但是，掛載某些卷(例如“/"卷可以允許容器完全訪問主機文件系統(tǒng)。系統(tǒng)調用提供內核和應用程序之間的接口。但是,限制容器可以執(zhí)行的系統(tǒng)調用是非常重要的。一個可以用于此操作的工具是Seccomp。42升權限。這樣做的方法包括AppArmor43和SELinux。44KataContainers45和Firecracker.46?2024云安全聯(lián)盟大中華區(qū)版權所有容器網(wǎng)絡：容器通常需要相互交互，這是微服務的本質。因此確保正確管理網(wǎng)絡隔離至關重要。使用Web應用程序防火墻、路由表、服務網(wǎng)格和網(wǎng)絡策略（在容器編排器中）可以確保不應該相互通信的服務是完全隔離的。鏡像安全：容器通常需要相互交互，這是微服務的本質。因此確保正確管理網(wǎng)絡隔離至關重要。使用Web應用程序防火墻、路由表、服務網(wǎng)格和網(wǎng)絡策略（在容器編排器中）可以確保不應該相互通信的服務是完全隔離的:Dockerfile的安全性和構建過程：如果使用Dockerfile從頭開始構建映像，那么考慮以下建議非常重要:使用受信任的注冊表(例如專用Azure容器注冊表或彈性容器注冊表)。保持應用程序的安全要求要求在基本映像中使用標記或摘要的記憶。使用多階段構建。47使用rootless容器。對Dockerfile編輯訪問控制。檢查卷的掛載，以避免掛載敏感的目錄。不要在Dockerfile中包含任何敏感數(shù)據(jù)。避免使用SETUID二進制文件，因為它們可能允許攻擊者提升容器內的權限。避免在Dockerfile中使用不必要的代碼。確保對Docker守護進程的訪問受到控制，并且不是每個開發(fā)人員都可以訪問構建機器。4950對鏡像使用無守護進程構建:buildah,48podman,andbuildkit,。鏡像掃描和簽名：鏡像掃描旨在捕捉應用程序級別的漏洞和惡意代碼，這些漏?2024云安全聯(lián)盟大中華區(qū)版權所有洞和代碼可能已在基礎的鏡像中引入。然后的目標是定期掃描鏡像并對其進行簽名，以確保在掃描和構建后不允許進行未經(jīng)授權的變更。一些良好做法包括:運行私有注冊表。使用Notary51或Harbor52等工具對鏡像進行簽名。定期掃描鏡像以查找應用程序級漏洞或惡意軟件包。容器編排安全性：容器編排安全主題非常廣泛。因為它包括編排器底層基礎設施的安全性，以及它管理和編排的軟件定義的基礎架構層的安全性。因此，我們的建議是使用完整的框架，如Kubernetes53的CIS基準或美國國家安全局加固指南，以獲得系統(tǒng)的指導。一些一般性建議可以幫助保護諸如Kubernetes之類的編排器。確保:54允許控制器(例如OPAGatekeeper)強制在集群中創(chuàng)建對象。所有帳戶都正確定義RBAC，并且在不需要時不授予“星號”權限。除非必要，否則避免節(jié)點端口暴露在公共互聯(lián)網(wǎng)上。集群中部署的所有容器都遵循上述建議。所有使用的圖像都遵循上述建議。使用Istio55或Linkerd56等服務網(wǎng)格用于保證在容器之間傳輸敏感信息時，