2024DevSecOps六大支柱自動化

DevSecOps六大支柱自PAGEPAGE18目錄致謝 4序言 6前言 9介紹 90.1背景 90.2目的 100.3讀者群體 11適用范圍 11規(guī)范引用文件 11術(shù)語和定義 11CSADevSecOps軟件交付流水線 144.1總則 144.2結(jié)構(gòu) 154.2.1總則 154.2.2階段 154.2.3觸發(fā)器 164.2.4活動 174.3流水線的設(shè)置和維護(hù) 17風(fēng)險優(yōu)先的流水線 185.1概述 18風(fēng)險因素 19應(yīng)用程序風(fēng)險 19變更請求的風(fēng)險 19流水線及其交付物的可靠記錄的風(fēng)險 19流水線配置的優(yōu)先級 19交付流水線的活動框架 216.1概述 21安全的設(shè)計 21安全的編碼 22安全的軟件組件 23安全的應(yīng)用程序 24安全的運(yùn)行環(huán)境 24密鑰管理 25自動化最佳實(shí)踐 257.1概述 25緩解漏洞 25異步測試 26持續(xù)反饋回路 26破壞構(gòu)建 278.總結(jié) 27前言云安全聯(lián)盟（CSA）SAFECode都致力于提高軟件安全成果。20198月DevSecOps1：集體責(zé)任（2020.02.20發(fā)布）2：培訓(xùn)和流程整合3：實(shí)用的實(shí)施4：建立合規(guī)與發(fā)展的橋梁（2022.02.03發(fā)布）5：自動化（2022.07.06發(fā)布）6：度量、監(jiān)控、報告和行動SAFECode1解決方案。本文是此系列出版物的第二篇。介紹背景DevSecOps自動化支柱提倡使用安全自動化來實(shí)現(xiàn)反思性安全。具體而言，實(shí)施安全自動化和程序化執(zhí)行框架以及安全控制監(jiān)控，以識別、保護(hù)、檢測、響應(yīng)、并從網(wǎng)絡(luò)威脅中恢復(fù)。2DevSecOps誤。1SAFECode進(jìn)有效和可擴(kuò)展的軟件安全議題2反思性安全是一種動態(tài)的、交互式的、整體的、有效的信息安全管理策略。它代表了從現(xiàn)有協(xié)作概念和實(shí)踐中推斷出來的文化實(shí)踐，并提供了一套影響組織網(wǎng)絡(luò)安全態(tài)勢的廣泛含義和易于理解的原則洞掃描等。DevOps團(tuán)隊靈活利用持續(xù)集成、持續(xù)交付和基礎(chǔ)設(shè)施即代碼在內(nèi)的最佳實(shí)踐，能夠動態(tài)滿足用戶需求并更快速地交付。意義的反饋至關(guān)重要。當(dāng)今云基礎(chǔ)設(shè)施的復(fù)雜性意味著即使微小的代碼變更也可能對下游產(chǎn)生很計、實(shí)施、測試和發(fā)布，并在生產(chǎn)中保持監(jiān)控?；?qū)σ阎耐ㄓ寐┒磁叮–VE）進(jìn)行軟件組成分析。目的開發(fā)生命周期中：DevOps團(tuán)隊，通過設(shè)計連續(xù)的權(quán)衡軟件開發(fā)和安全需求，從而通過自動集成提高交付效率。讀者群體工作人員。包括最高管理層（CISO、CIO、CTO、CRO、COO、CEO）尤其是涉及DevSecOpsDevOps適用范圍DevSecOps化技術(shù)以及實(shí)現(xiàn)機(jī)制。DevSecOpsDevSecOps安全測試中的常見誤解。規(guī)范引用文件的最新版本參考使用。ISO/IEC27000:2018，信息技術(shù)—安全技術(shù)—信息安全管理系統(tǒng)—概述和詞匯；CSA通過反思性安全進(jìn)行信息安全管理；CSADevSecOps的六大支柱；術(shù)語和定義27000CSA軟件組成分析（SCA）分析具有已知漏洞的軟件組件的應(yīng)用或編譯代碼的安全測試。注釋1：軟件組成分析中的軟件組件可能包括開源、庫和公共代碼。注釋2：已知漏洞可通過漏洞庫（如CVE）發(fā)現(xiàn)。靜態(tài)應(yīng)用安全測試分析應(yīng)用源代碼中軟件漏洞和最佳實(shí)踐差距的安全測試。注釋1：靜態(tài)分析可以在多種環(huán)境中執(zhí)行，包括開放人員的IDE、源代碼和二進(jìn)制文件。注釋2：也稱為“白盒測試”。動態(tài)應(yīng)用安全測試通過行使應(yīng)用功能并根據(jù)應(yīng)用行為和響應(yīng)檢測漏洞來分析正在運(yùn)行的應(yīng)用的安全測試。注釋1：也稱為“黑盒測試”。交互式應(yīng)用安全測試（IAST）行的應(yīng)用是否存在漏洞。運(yùn)行時應(yīng)用安全保護(hù)（RASP）生產(chǎn)過程中目標(biāo)應(yīng)用里部署的安全技術(shù)，用于檢測、警報和阻止攻擊。注釋1：類似于WAF，但是安裝在應(yīng)用中進(jìn)行檢測。WEB應(yīng)用防火墻通過檢查HTTP流量來監(jiān)視、警報和阻止攻擊的應(yīng)用防火墻。云安全態(tài)勢管理（CSPM）能夠發(fā)現(xiàn)、評估和解決易受攻擊的云基礎(chǔ)設(shè)施錯誤配置的安全技術(shù)。云安全監(jiān)控和合規(guī)監(jiān)控虛擬服務(wù)器并評估數(shù)據(jù)、應(yīng)用和基礎(chǔ)架構(gòu)安全風(fēng)險的安全技術(shù)。威脅建模識別和理解影響資源或資源集的威脅的方法。白盒代碼審查閱讀源代碼以識別安全問題的人工過程。軟件交付流水線一組用于將軟件從概念交付到部署的自動化過程。軟件交付流水線（CDDP）一種符合DevSecOps原則以支持安全軟件交付的流水線。DevSecOps 軟件交付流水線總則線的每個階段都會執(zhí)行自動檢查，以防質(zhì)量問題流入下一階段。的工具包括源代碼控制、構(gòu)建、持續(xù)集成、容器化、配置管理、編排和監(jiān)控。檢查點(diǎn)把這些異步測試遺忘。結(jié)構(gòu)總則支持安全的軟件交付流水線被認(rèn)為具有三個粒度級別：階段觸發(fā)器和檢查點(diǎn)活動階段圖1-1：交付流水線中的階段熟度較低。當(dāng)軟件準(zhǔn)備好持續(xù)交付和部署時，軟件趨向成熟。部署到生產(chǎn)環(huán)境中。這與軟件開發(fā)方法（瀑布或敏捷）無關(guān)。每個階段都有機(jī)會嵌入適當(dāng)?shù)淖詣踊踩刂?。本文件識別了以下不同的階段：安全設(shè)計和架構(gòu)安全編碼（開發(fā)者IDE和代碼存儲庫）持續(xù)構(gòu)建、集成和測試持續(xù)交付和部署持續(xù)監(jiān)控和運(yùn)行時防御觸發(fā)器圖1-2：交付流水線中的觸發(fā)器觸發(fā)器和檢查點(diǎn)（參見圖1-2）表示在階段內(nèi)的轉(zhuǎn)換。當(dāng)滿足觸發(fā)條件時，將激活一個或多個安全活動，這些活動的結(jié)果決定是否滿足檢查點(diǎn)的預(yù)期要求。如果安全活動的結(jié)果滿足預(yù)期要求，則可交付成果將轉(zhuǎn)移到下一個檢查點(diǎn)（如果檢查點(diǎn)是最后一個，則轉(zhuǎn)移到下一階段）。否則，可交付成果將被暫停而不被允許進(jìn)入到下一個檢查點(diǎn)。示例適用該功能的一般或特定安全控制。示例2：開發(fā)人員的代碼提交或拉取/合并請求可能會自動觸發(fā)源代碼掃描和代碼審核過程。示例發(fā)漏洞掃描。有兩種類型的觸發(fā)器：基于變更的觸發(fā)器：這些觸發(fā)器由變更事件引發(fā)，例如代碼推送；循環(huán)觸發(fā)器：這些觸發(fā)由時間事件觸發(fā)，例如例行計時器；基于變更的觸發(fā)器用于保護(hù)檢查點(diǎn)的狀態(tài)變更。它們通常被用于可以以基于事件的方式運(yùn)行的短期安全檢查。循環(huán)觸發(fā)器則通常用于運(yùn)行時間較長的安全檢查，例如涉及批處理或組件之間集成的安全檢查。示例4：在批量代碼倉中掃描誤存的秘密憑據(jù)信息，循環(huán)觸發(fā)器是首選?；顒訄D1-3：交付流水線中的安全活動活動是將可交付成果作為輸入并產(chǎn)生肯定或否定等結(jié)果的單個過程。如果可交付成果符合活動的標(biāo)準(zhǔn)，則結(jié)果被認(rèn)為是肯定的。否則，結(jié)果是否定的。具體來說，每個活動都代表安全控制的實(shí)施——為檢測代碼、庫、應(yīng)用程序或應(yīng)用程序?qū)⒁\(yùn)行的環(huán)境中的安全漏洞而執(zhí)行的測試或驗(yàn)證任務(wù)。全活動的詳細(xì)描述和應(yīng)用指南。流水線的設(shè)置和維護(hù)DevSecOpsDevOps團(tuán)隊已經(jīng)在使用的工速的發(fā)布周期。從安全的實(shí)用角度來看，流水線安全的測試功能應(yīng)該由高價值、低影響的功能逐步引入。對已經(jīng)使用代碼質(zhì)量管理工具或庫管理3（術(shù)和儀器）。在引入例如靜態(tài)應(yīng)用安全測試（SAST）新的測試功能時，DevOps團(tuán)隊?wèi)?yīng)首（陰性）。DevOps團(tuán)隊在自動化測試中增加新的發(fā)現(xiàn)類型或功能之前，應(yīng)該對遺漏的漏洞和誤報進(jìn)行根本原因分析，以獲得最佳效率。大量的誤報會給DevOps團(tuán)隊帶來負(fù)擔(dān)，損害安全工具的可信度。一個好的策略是“在向右加速的同時安全向左轉(zhuǎn)移”。自動化的安全控制SDLC向自動化轉(zhuǎn)變。風(fēng)險優(yōu)先的流水線概述先級和可交付性方面取得平衡。在部署構(gòu)建時，應(yīng)使用基于風(fēng)險的方法來確定安全測試的總體嚴(yán)格程度。通常有如下三種類型的風(fēng)險因素需要考慮：3https:///article/3398485/28-devsecops-tools-for-baking-security-into-the-development-process.html風(fēng)險因素應(yīng)用程序風(fēng)險對應(yīng)用程序其固有的風(fēng)險進(jìn)行評估，包括考慮其處理的數(shù)據(jù)和使用環(huán)境。例如：處理銀行或醫(yī)療保健數(shù)據(jù)的應(yīng)用程序可被視為“高風(fēng)險”，而處理PII和信用卡的應(yīng)用程序可被視為“中等風(fēng)險”。那些處理靜態(tài)內(nèi)容或公共信息的應(yīng)用程序可被視為“低風(fēng)險”。變更請求的風(fēng)險因?yàn)樽兏氲娘L(fēng)險，包括變更可能帶來的安全影響、受變更影響的數(shù)據(jù)以及變更的性質(zhì)。（如身份驗(yàn)證或訪問管理更徹底的測試。流水線及其交付物的可靠記錄的風(fēng)險歸因于交付流水線和其所涉及應(yīng)用程序的可靠性和完整性歷史的風(fēng)險。洞的應(yīng)用程序更可靠。流水線配置的優(yōu)先級以滿足是否其需求。從而縮短交付時間。用交通燈的方式來解釋，即有三個不同顏色的處理流水線：綠色、黃色和紅色，每個流水線提供不同級別的安全審查：綠色流水線：運(yùn)行測試時間短，為持續(xù)交付而優(yōu)化。付。IAST交付。示例體風(fēng)險低”，并可以沿著“綠色流水線”繼續(xù)處理。2為“中等風(fēng)險”，可以沿著“黃色流水線”繼續(xù)進(jìn)行。示例3：對有重大漏洞記錄的應(yīng)用程序的交付，應(yīng)按照“紅色流水線”進(jìn)行更嚴(yán)格的安全審查。示例4。如果提議的變更為安全處理數(shù)據(jù)引入了新的標(biāo)準(zhǔn)組件，或要求開發(fā)人員接受相關(guān)安全最佳實(shí)踐的培訓(xùn)，則適用“紅色流水線”。當(dāng)檢測到新漏洞時，應(yīng)實(shí)施根本原因分析，以確定原因是否與人員、流程或技術(shù)有關(guān)，并對相關(guān)內(nèi)容進(jìn)行重新設(shè)計或變更，防止漏洞再次發(fā)生。下表提供了一個變化的評分樣本，結(jié)合這三個因素來確定目標(biāo)流水線配置。采用高（3）、中（2）、低（1）的數(shù)值，總分5分及以上被認(rèn)為是在“黃色流水線”，7分及以上被認(rèn)為是在“紅色流水線”。應(yīng)用風(fēng)險變更風(fēng)險可靠性風(fēng)險交付流程配置變更#1中（2）低（1）低（1）綠色流水線（4）變更#2低（1）高（3）中（2）黃色流水線（6）變更#3高（3）高（3）高（3）紅色流水線（9）表1：生成影響和結(jié)果發(fā)布流水線交付流水線的活動框架概述本節(jié)介紹了一個框架（見圖2），它代表了交付流水線中使用的六類安全活動，以及這些活動的指導(dǎo)方針。安全的設(shè)計是一種災(zāi)難性的做法，已知設(shè)計缺陷占漏洞的很大一部分。DevSecOps一個安全的架構(gòu)。威脅模型通常不需要，所以手動更新仍然是一種可行的機(jī)制。安全的編碼無論一個應(yīng)用程序的安全架構(gòu)是多么的周密和健全，漏洞都可能來自糟糕的編碼。如果開發(fā)人員編寫的代碼包含安全缺陷，應(yīng)用程序被攻破只是時間問題。SAST（和通用它們表現(xiàn)為安全漏洞。在自動化靜態(tài)代碼測試時，DevSecOps的目標(biāo)是盡可能早地通過上下文向開發(fā)人員提供代碼安全警報，并規(guī)范其反饋循環(huán)。在交付流水線中，很多時候會執(zhí)行安全掃描，包括：IDE或集成測試套件；代碼掃描；持續(xù)交付預(yù)部署：部署前掃描；圖3：應(yīng)用程序組件與環(huán)境之間的關(guān)系安全的軟件組件應(yīng)用程序的安全性依賴于其組件的安全性。無論是來自內(nèi)部開發(fā)、第三方引入還是開源項目引入的組件漏洞，都會損害更大的應(yīng)用程序。以系統(tǒng)的方式管理這些軟件組件至關(guān)重要，可以采取以下措施：及時發(fā)現(xiàn)和報告第三方軟件中的漏洞，如開源代碼和容器檢測未經(jīng)授權(quán)的組件使用情況組件的漏洞管理應(yīng)該是連續(xù)的，這樣不僅在開發(fā)過程中進(jìn)行，而且在其后也同樣實(shí)施。重要的是確保使用的第三方組件在應(yīng)用程序生命周期內(nèi)保持安全。在公開應(yīng)用程序組件的漏洞時，應(yīng)觸發(fā)一個提示需要將組件庫升級到無漏洞版本的流程。這個流程通?？梢酝ㄟ^持續(xù)集成過程或運(yùn)行時掃描，使用源代碼掃描工具自動執(zhí)行。安全的應(yīng)用程序應(yīng)用程序必須在現(xiàn)實(shí)環(huán)境中進(jìn)行安全性測試，才能被信任。即使使用了可靠的體系結(jié)構(gòu)、安全的代碼和無漏洞的組件，它們的集成也不一定會導(dǎo)致安全的應(yīng)用程序。動態(tài)應(yīng)用程序測試DAST可用于測試分段在測試和生產(chǎn)環(huán)境中對應(yīng)用程序進(jìn)行安全測試以保證安全性。DAST工具可以發(fā)現(xiàn)各種安全問題，從故障注入、故障檢測到資源和秘密泄露。（DAST在流水線中的適當(dāng)位置見圖1）。模糊測試也是識別安全漏洞的一種有效方法。在交付流水線中運(yùn)行各種類型的自動模糊測試，以確保應(yīng)用程序?qū)﹀e誤和惡意輸入具有一定的彈性。安全的運(yùn)行環(huán)境一般情況下不安全的環(huán)境會使得本來安全的應(yīng)用程（IaaC）用程序容器化和持續(xù)部署的方法為保護(hù)基礎(chǔ)架構(gòu)和環(huán)境提供了新的可能性，包括：IaaC代碼和工件掃描環(huán)境的運(yùn)行態(tài)防護(hù)IaaC安全I(xiàn)aaC些資源的實(shí)際配置。IaaC代碼和工件的安全分析可以通過兩種機(jī)制執(zhí)行：IaaC模板和配置狀態(tài)的靜態(tài)掃描運(yùn)行時安全部署的應(yīng)用程序受其環(huán)境的安全約束，因此必須進(jìn)行監(jiān)控。通常有兩種方法：保護(hù)的重要措施（4）。運(yùn)行態(tài)防御確保在運(yùn)行時發(fā)現(xiàn)的漏洞和攻擊得到緩解，并盡快報告。密鑰管理應(yīng)用程序和交付流水線中的機(jī)密管理至關(guān)重要，會影響到整個交付流水線。使用合適的加密算法不一定能提供足夠的安全性對抗攻擊者。例如，開發(fā)人員選擇了最佳的加密算法，但如果把密鑰存儲在公開的位置，安全性就會受到威脅。包括密鑰管理和密鑰輪換在內(nèi)的過程必須得到妥善處理。云密鑰存儲庫和密鑰管理基礎(chǔ)架構(gòu)可以被視為自動化解決方案的一部分。自動化最佳實(shí)踐概述在安全的交付流水線中使用的很多安全活動可以在任何DevSecOps（也稱為異步DevSecOps以外的最佳實(shí)踐和注意事項。緩解漏洞漏洞在剛出現(xiàn)時最容易解決?？紤]到這一點(diǎn)，我們采取的戰(zhàn)略是在部署之前，IDE前部署檢查安全問題的工具。解決。異步測試一般情況下異步測試有兩類：包括威脅建模、滲透測試和代碼審查；SAST。這些活動可以“帶外”觸發(fā)和執(zhí)行，而不是自動部署內(nèi)聯(lián)，避免中斷軟件部署流水線。適當(dāng)?shù)臋z查點(diǎn)將其視為連續(xù)交付過程的障礙。持續(xù)反饋回路應(yīng)用程序中存在的安全缺陷時間越長，進(jìn)一步的變更和部署就越有可能增加修復(fù)缺陷的復(fù)雜性和成本。DevSecOps團(tuán)隊必須盡早警示安全問題，以防止缺陷向下游蔓延。另外，及時的反饋能夠使個人實(shí)施快速診斷和漏洞補(bǔ)救，并能在記憶猶新時