目錄致謝 4行業合作伙伴 6簡介 8概述 8高層支持與參與 10計劃設計與實施 11將冠軍帶到挑戰中 14通過安全意識和培訓加強該計劃 15計劃持續運維與成效評估 17總結 19附錄一：健康問題與討論要點 21附錄二：延伸閱讀 22簡介云安全聯盟（CloudSecurityAlliance）和SAFECode都堅定地致力于改善軟件安全成果。2019年8月發布的論文《DevSecOps的六大支柱》提供了一套高層次的方法和成功實施的解決方案，作者通過這些方法和解決方案來快速構建軟件，并盡量減少與安全相關的錯誤。這六大支柱是支柱1：集體責任支柱2：培訓和流程整合支柱3：務實的實現支柱4：建立合規與發展的橋梁支柱5：自動化支柱6：測量、監控、報告和行動云安全聯盟（CloudSecurityAlliance）和SAFECode將聯合出版一套更為詳細的出版物，介紹支撐上述每個支柱的成功解決方案。本報告是這些后續出版物中的第一份。概述DevSecOps將安全原則、流程和技術整合到持續的軟件開發和IT運營文化中，從而影響其實踐和工作流程。它將傳統上相互隔離的開發、基礎設施運營和信息安全領域匯聚在一起，通過一套共同的流程、程序和工具自動化，促進安全軟件的開發。DevSecOps動的，這種環境具有越來越短的產品生命周期、更迭代的開發方法以及開發和IT運營的日益集成。傳統的安全開發方法往往難以滿足那些在云環境中工作的人快速采用的持續開發方法的需求。將安全開發實踐集成到DevOps中需要一種更敏捷的安全方法，包括增加安全流程的自動化、更周到和務實的安全實施規劃、更明確地列舉風險和合規要求，以及更具操作性的監控和測量方法。此外，要使所有這些元素作為一個整體的DevSecOps方法協同工作，需要每個接觸該流程的人都有集體安全責任意識。鑒于對DevSecOps的興趣增加，云安全聯盟（CSA）和軟件保證卓越代碼論壇（SAFECode）組成了一個DevSecOps工作組，以識別和分享開發和維持DevSecOps項目的最佳實踐。作為第一步，工作組根據CSA的反射性安全框架中描述的六大支柱，確定并定義了將DevSecOps集成到組織中的六個關鍵關注領域。隨著時間的推移，我們將重新審視并建立每個DevSecOps支柱的更詳細的研究和指導，以維護特定行業的標準。本文是計劃中的系列文章的一部分，將重點關注arguably其他所有支柱基礎的領域——集體責任。培養集體安全責任意識不僅是將安全融入DevOps環境的重要組成部分，也是最具挑戰性的任務之一。這需要培養組織在軟件安全方面的思維方式、理念、習俗和行為的轉變。在本報告中，我們將這種努力稱為構建支持安全的文化。這種文化的一些顯著特征包括以下特點：實施安全設計的心態：在軟件開發和運營的每個階段都考慮和解決安全問題。安全不是事后的想法，也不是僅僅通過審計發現來處理的問題。一種全員參與——從開發到IT運營再到高層管理——在確保軟件安全方面發揮作用，并作為組織應對當今復雜威脅環境的第一道防線的意識。強調個人責任和信任。這種方法使自主性和敏捷性得以增強，提供必要的安全信息和工具，以便進行知情的分散式行動和決策。這與傳統上限制性較強、手動密集且相互隔離的安全流程有所不同。明確認識到安全并非與業務目標分開或截然不同，因此，積極的安全行為和激勵措施之間存在明確且可識別的一致性，并且相信團隊成員在其安全工作中會得到支持。盡管關于培養支持安全的文化的必要性已有大量著作，但它仍然是DevSecOps執行過程中最常被提及的挑戰之一。文化通常被描述為組織的一個關鍵但無形的要素。不幸的是，這可能導致一種相當臨時的文化變革方法。在軟件安全方面，這通常表現為偶爾的黑客馬拉松或漏洞清理活動，或者可能是關于軟件安全實踐價值的年度培訓課程。這并不是說這些活動沒有價值，而是說如果它們沒有在團隊目標的背景下呈現、沒有得到加強，或者沒有包括正確的受眾，它們的影響是有限的。在周期開始時引入安全知識和培訓可以幫助避免這些臨時會議的需要。高層支持與參與用于創建和維持支持安全的文化的方法各不相同，但幾乎所有成功的組織都共享的一個基本要素是支持和參與型的領導團隊。管理層的支持不僅是確保對DevSecOps進行足夠的時間和資源投入的必要條件，也是確保這些努力得到實地支持的關鍵。員工能夠分辨出對安全計劃的象征性支持或勉強支持與嚴肅承諾之間的區別，并且他們的這種認識不可避免地會反映在他們執行計劃部分的方式上。為了獲得管理層對安全文化發展的支持，通常需要提出一個全面的、以結果為導向的計劃，而不是一系列臨時性的活動。設計一個計劃級的方法至少需要制定一個與業務戰略緊密相關的商業案例、一個詳細的實施計劃以及關鍵的項目指標。參與云安全聯盟（CSA）和SAFECode等組織也有助于了解類似組織是如何處理安全文化發展的，這同樣可以支持商業案例的提出。計劃設計與實施建立安全文化應被視為一項重要且持續的計劃級工作，而不僅僅是一系列臨時性活動的簡單集合。這需要對旨在培養集體安全責任感的新舉措進行精心規劃和周密部署。以下是那些希望采用計劃管理方法的人需要考慮的一些常見問題。當一個企業設計一個支持安全文化的計劃時，任務是將安全意識和集體責任感融入現有的組織文化中。這要求安全領導者在計劃設計中考慮其組織和開發團隊的現有文化和業務實踐。一個有用的方法是研究過去需求或流程變更的例子，以嘗試找出有效的溝通和社交化方法，并將其應用于安全開發工作。例如，安全領導者可能會考慮財務和會計團隊如何與開發團隊合作，以促進和慶祝其新發票和費用報告系統在全公司的推出，初步威脅模型如何有助于簡化產品設計并降低成本和風險，或者為什么盡管增加了工作量，產品管理的新文檔要求卻如此迅速地被接受？其他一些常見問題包括以下問題：團隊是更傾向于響應公司高層的指令，還是更傾向于接受來自工程內部的更基層的方法？哪些類型的激勵措施更有助于促進行為改變？組織中的關鍵影響者是誰，他們是否有可能在這方面提供幫助？集體安全責任文化與工程團隊以及整個公司的目標和愿景之間有什么關系？安全要求和實踐在哪些方面與開發流程相沖突，如何最小化這些目的沖突？中高層管理人員應該如何參與？現有的文化和相關流程是否仍然與業務目標保持一致，還是已經過時？如果過時了，是否還有價值/可以改進？你的團隊可以使用的內部討論要點包括這些考慮因素：預定義的結構和流程通常內部聚焦，服務于組織結構本身而非更廣泛的業務需求（例如無效的變更控制流程，管理層和工程師都對流程不滿意，看不到其中的價值，但流程仍未改變，開始充當阻礙者而沒有增加太多價值）。在部門隔離的模式下，跨層級的溝通可能會緩慢且低效。信息從上到下以及從下到上流動緩慢。是否可以通過簡化流程或補充一些舉措，如共享安全責任（授權）、使用自動化工具進行控制和度量，以及向管理層清晰報告有意義的度量數據（數據驅動的業務決策），來改善這一點。政策、規則和程序阻礙了戰略決策的快速制定。我們看到了去中心化控制的趨勢，借助自動化的安全“緩沖器”和個體責任，并通過更好的安全培訓和諸如“安全冠軍”等計劃的支持。人們固守舊習，害怕失去權力和地位。如果我們反復依靠少數幾個可信賴的人來領導關鍵舉措，而非從更廣泛的利益相關者群體獲取意見，文化和進步可能會受到抑制（這再次強調了授權和改進溝通/協作的重要性）。快速創新和顛覆是否存在正當的業務需求，以及更高的風險偏好，或者相反，業務需求是否更傾向于規避風險或由合規驅動？安全團隊往往與開發過程相距甚遠，無法被視為合作伙伴；他們被認為在周期后期介入，下達指令或要求更改，但對工程環境的實際情況沒有充分考慮。事實上，軟件安全領域的早期先驅者學到的最深刻的教訓之一是，忽略開發者的成功需求是最快失敗的方式。在DevOps環境下，這一挑戰可能更為嚴峻，因為開發團隊非常重視自動化和迭代的速度。乍一看，DevSecOps方法似乎將安全性完全集成到開發和運營團隊中，消除了對單獨安全組的需求。雖然這可能是許多人所期望的未來狀態，但實際上大多數組織都發現需要維持一個專門的軟件安全團隊，以確保所需的專業知識并專注于安全問題。在實踐中，最大的組織挑戰是如何以支持所需安全文化特征的方式整合安全、開發和運營團隊的工作。在早期的軟件開發模型中，安全人員和開發人員之間存在著天然的緊張關系。安全人員通常認為軟件管理在道德上是模棱兩可的，“現在發布，以后再修復”，而業務目標只是實現構建下一個更好的增量軟件版本所需的收入流。DevSecOps允許合并這兩種思維方式。安全成為產品的組成部分，用戶的安全和隱私要求成為明確的功能要求。這并不意味著使用獨立安全團隊的組織注定要失敗。這也不一定意味著將安全完全納入發展是正確的做法。事實上，這兩種模式都有成功的組織。重要的是要考慮人員配置計劃和周圍的組織結構圖支持或阻礙文化發展的方式，以便減輕任何一種方法帶來的任何挑戰。此外，這不需要是一場要么全有要么全無的討論。事實上，使用混合方法的勢頭越來越大，即使用安全冠軍來彌合安全與發展之間的差距。將安全冠軍帶到挑戰中安全冠軍是開發團隊的成員，他們有權持續參與幫助指導和執行日常安全活動。與可用性有限或受限的安全團隊專家不同，安全冠軍可以可靠地支持開發團隊級別的DevSecOps執行和安全活動。許多組織發現安全冠軍計劃是擴展其軟件安全工作的關鍵。此外，安全冠軍對組織文化有直接影響。事實上，他們經常站在將集體安全責任社會化的任何努力的第一線，并有權在需要時將問題上報給安全團隊和管理層。當SAFECode努力比較其成員之間成功的安全冠軍計劃時，它發現它們有一些共同的特點。軟件安全需要一個冠軍——構建和維護成功的安全冠軍計劃的簡短指南首先，安全衛士的角色應被視為主要職責，最好是全職或接近全職的工作。僅僅將已經不堪重負的軟件開發人員標記為新的常駐安全專家是不夠的。安全冠軍需要與更廣泛的安全團隊密切合作，并能夠根據風險優先考慮安全問題。通過這種方式，它們是工程團隊中上下文感知的安全驅動程序，也是安全團隊的接口。其次，雖然安全冠軍最初可能需要在工程團隊中擔任戰術安全職位，但目標應該是隨著團隊安全知識的增長而發展他們的角色。安全冠軍不應該為開發人員做安全工作，而應該充當培訓開發人員的導師，這樣他們就可以自己解決安全問題，在需要時尋求額外的澄清或幫助。理想情況下，安全冠軍將與首席架構師和利益相關者密切合作，擁有威脅和隱私模型，并成為由此產生的活動（識別安全相關功能、組件選擇等）的主要焦點。如果沒有這種心態，不僅難以擴大其影響，而且安全可能會繼續被視為其他人的工作（在這種情況下是安全冠軍的工作），而不是每個開發人員的集體責任。第三，僅僅找到一個安全冠軍并告訴他們去解決安全問題是行不通的。要取得成功，安全冠軍需要一個正式的、管理層支持的計劃的支持，該計劃具有明確的組織和專業目標，以及一個支持性的組織生態系統。這樣，安全冠軍計劃的成功與安全文化發展計劃的努力密切相關，因此許多組織應該將其視為一項工作。至少，如果同時推行安全冠軍和文化發展計劃，就應該一并考慮。通過安全意識和培訓加強該計劃培訓是任何成功的DevSecOps計劃的重要組成部分。事實上，鑒于安全開發實踐很少被納入軟件工程教育，它長期以來一直是軟件安全領域的一個重點。CSADevSecOps工作組認為培訓是必不可少的DevSecOps規劃的支柱，正在制定更詳細的指導方針，稍后分享。SAFECode在其最新版本的《安全軟件開發基本實踐》【3】中還談到了培訓的重要性，指出“整個組織都應該意識到安全的重要性，必須為開發團隊提供更詳細的技術培訓，明確闡述個人和團隊的具體期望。”雖然為直接負責實施安全開發方法的人員提供詳細技術培訓的必要性是相當明顯的，但許多組織在意識培訓工作中可能沒有接觸到足夠廣泛的受眾。為了使DevSecOps取得成功，整個團隊——架構師/設計師、技術作家、項目經理、開發工程師、服務和質量保證（QA）工程師、IT運營等——都應該具備扎實的基礎安全知識。培養對安全重要性和每個團隊在安全方面所扮演的具體角色的認識，對于建立支持安全的文化至關重要。考慮其他形式的外展活動，如午餐和學習課程、與安全專家安排的開放時間以及安全指導計劃。安全的游戲化也越來越受歡迎，作為一種讓安全知識更加觸手可及和引人入勝的方式，可以通過在外展組合中添加定期的黑客馬拉松來實現。據了解，培訓課程和外聯活動的時間有限，因此組織者一定要提供一種方法來獲取參與人數，并收集參與者和外聯負責人的反饋。這些評估將有助于確定最受歡迎和最有影響力的外聯活動，以便可以復制，而不太有用的活動則可以放棄。此外，考慮如何利用其他現有的團隊和面向同行的活動來進一步建立安全意識和發展安全專業知識。已建立的開發方法，如對等編程和配對，可用于安全代碼審查。如果定期使用bug抨擊，可能有機會邀請一個通常不會參加此類活動的額外團隊參與。威脅建模應該已經作為一項團隊活動進行，包括多個角色。重要的是要確保這些會議的參與率保持較高水平，不會因日程安排問題而犧牲。威脅建模會議也可以戰略性地擴展，以包括傳統上可能不會被邀請的其他人，以增加安全利益。值得注意的是，那些喜歡并在威脅建模課程中表現良好的人通常是安全冠軍和其他安全外展角色的優秀候選人。最后，考慮除了安全意識和技術之外的其他技能是否有助于提高安全計劃的影響。例如，提供一組已識別的安全影響者或者接受過領導力培訓的安全冠軍可能會提高他們在團隊中的效率。提供演示培訓的機會可能會鼓勵其他人挺身而出，自愿領導內部棕色袋子會議。雖然培訓計劃和外聯活動的確切組合因組織而異，甚至可能因團隊而異，但在文化發展計劃的背景下，對這些舉措采取整體和全面的方法非常重要。這并不一定需要采用集中的方法來規劃培訓和外聯計劃。事實上，有時，當在團隊層面確定需求并采取行動時，外聯工作可能是最有效的。然而，了解整個組織正在做什么很重要。這不僅有助于確保培訓和外聯保持相關性和影響力，但也將確定執行中的差距，優化資源，為其他領域的工作提供信息，并為培養安全文化提供額外的機會。計劃持續運維與成效評估制定監視和報告策略是DevSecOps規劃的一個不可或缺的元素。可操作的指標通過度量進度和及時檢測故障來啟用DevSecOps計劃。度量是DevSecOps的重要組成部分，它也是CSA-SAFECodeDevSecOps工作組確定的DevSecOps4，并且是即將發布的指南的主題。因此，本文不會嘗試涵蓋DevSecOps度量和報告實踐的全部范圍。但是，它將解決兩個與文化相關的關鍵度量問題如何度量文化驅動的內容度量像文化這樣無形的東西的挑戰首先必須認識到，公司的度量標準會驅動其行為方式。這樣，組織選擇用于監控其DevSecOps計劃成功的指標將對其安全文化產生直接影響。考慮到許多組織將激勵措施直接與項目績效指標掛鉤，度量與行為之間的聯系變得更加明顯。例如，如果生產時間是唯一重要的指標，那么幾乎沒有動力去放慢速度來解決已識別的風險。或者，如果最有價值的指標側重于功能交付而不是質量，那么這可能會促使組織生產被未來技術債務和推卸責任的文化所淹沒的軟件。相反，如果優先考慮有意義的質量指標，那么就更有可能創造一種豐富的產品owner文化和著降低的遞延債務水平。當集體責任得到適當實施時，所有安全例外都必須在執行級別具有一定程度的明確問責制。安全指標不再只是用于衡量安全程序的性能/有效性。鑒于安全性在文化和技術上都嵌入到DevSecOps中，因此每個人都參與檢測和收集安全指標，并共同擁有和跟蹤安全性能。此外，組織文化從來都不是一成不變的;它會隨著組織的發展而改變，而最初推出DevSecOps時有效的方法可能不如項目成熟時有效。安全和開發實踐也在不斷發展，可用于支持它們的工具也在不斷發展，這反過來會影響DevSecOps運營的環境并創造文化變革。正如沒有一種單一的方法來構建支持安全文化一樣，今天有效的方法可能與明天有效的方法不同。在衡量計劃有效性、識別失敗點并確保實現持續改進所需的任何變革的過程方面，必須有一個精心設計的方法。擁有強大的衡量計劃將有助于指導任何保持高管的支持是長期項目維持的基本要素。衡量文化發展計劃影響的能力將使安全團隊能夠向高級領導者提出更強有力的商業案例，以繼續組織對這些活動的投資。毫無疑問，衡量像文化這樣無形的東西會帶來挑戰。使用的具體指標將取決于組織的不同目標。例如，一個專注于確保管理支持工程工作的文化計劃可以衡量在計劃推出之前和之后請求的風險異常數量。如