DevSecOps：應當做好的十件事

09-20

DevSecOps：應當做好的十件事

來自專欄從運維安全到DevSecOps

本文介紹的便是《DevSecOps：初入江湖》中提到的《Gartner 2017調研報告》原文。

背景介紹

慘痛的教訓告訴我們：DevSecOps很重要！

對於很多企業而言，雲和DevOps是推動企業業務發展的關鍵的技術引擎。企業的IT、安全和開發人員都知道在雲和DevOps環境中，有大量的敏感信息（如密鑰和憑據）需要保護。儘管大部分人都有安全方面的意識，但我們仍能看到諸多的數據泄漏事件。

以2017年發生的Uber數據泄露事件為例：

「11月22日，Uber發布聲明，承認2016年曾遭黑客攻擊並導致數據大規模泄露。根據這份聲明，兩名黑客通過第三方雲服務對Uber實施了攻擊，獲取了5700萬名用戶數據，包括司機的姓名和駕照號碼，用戶的姓名、郵箱和手機號。」

對於面向消費者的企業而言，信任是企業順利發展的一個重要組成部分。然而，不幸的是，最近幾年，企業或機構發生用戶信息泄露事件正在變的越來越普遍，引發的危害及潛在的破壞不可估量。

調查發現，Uber數據泄露的原因竟然是工程師將解鎖資料庫的安全密鑰被存儲在GitHub的一個可以公開訪問的頁面。媒體將稱作是「In major goof」（超級傻瓜）的失誤。

然而，這類由於操作不當引發數據泄漏的事件並不是孤案，尤其值得注意的是，當今雲環境和DevOps的迅速發展導致安全風險顯著地提高了。安全公司 Detectify 的安全顧問 FransRosén 曾於2017年 7 月 13 日發布一份報告稱「網路管理員經常忽略 AWS 訪問控制列表（ ACL ）規則，因伺服器錯誤配置而導致大量數據泄露。」

在網路急速發展的大數據時代，很多企業都貫徹著「敏捷」的思維和行動，這是一個危險的信號，而且正在不斷的被驗證著：越來越多的消費者、監管機構和市場發現由此所造成的數據泄漏的代價是高昂的、無法接受的。由於數據泄漏，你可能會看到市場資本中一夕之間損失數億美元、消費者對企業和機構的信任度下降，在某些情況下，高管們的職業生涯可能會結束或停滯不前。毫不誇張地說，一些依賴數據生存的企業甚至可能在無意中因為一個密鑰存儲的疏忽而使整個企業面臨滅頂之災，至少競爭對手不會放棄這些機會。

事實上，通過實施最低限度的特權，很多數據泄露事件都是可以提前預防的。接下來，我們將重點討論一下DevSecOps的概念，以及企業想要成功實行DevSecOps應採取的十項有效措施。

DevSecOps的概念

DevOps是Development和Operations的縮寫，而DevSecOps則是Development、Security和Operations的縮寫。John Willis(DevOps Cookbook合著者之一)稱Patrick Debois是DevOps的締造者，而DevOps的傳道者們認為，DevSecOps的基本理念是讓每一個解決方案、開發測試的多個跨部門協作人員都融入開發運維和安全的理念，並正確地理解DevOps的做法與含義。也就是說DevSecOps是一個項目組織方式，因此並不不存在DevOps者，更不是說將開發環境和生產環境整合在一起的意思，DevSecOps是一個群體做法，核心理念是：「安全是整個IT團隊（包括開發、運維及安全團隊）所有成員的責任，需要貫穿整個業務生命周期（從開發到運營）的每一個環節。」

將安全整合到DevOps的「DevSecOps」會帶來思維方式、流程和技術的整體變化。安全和風險管理的領導者，必須堅持合作，DevOps的敏捷性意味著其在開發過程是無縫的和透明的，同理，「DevSecOps」中的「安全」也應當是沉默的。

企業在執行DevSecOps時通常會面臨以下幾個方面的挑戰：

作為一名安全或風險管理人員，應當很清楚企業的業務發展是核心，因此向客戶提供新的IT功能的產品開發團隊才是王道，而不是信息安全或IT團隊。
信息安全工作必須適應開發過程和相應的工具，而不是背道而馳。
組織使用DevOps生產新的應用和服務，DevOps相關的過程和工具也有責任遵照公司對其他應用程序的要求，產生安全且符合要求的代碼。
要求應用程序達到百分百地安全是不現實的，企業一旦陷入「將安全漏洞的數量降為零」的錯誤追求中，安全測試的負擔識別加重，且很可能成為業務發展的一個障礙。

因此，問題的關鍵是風險的控制和管理，而非單純的追求安全。想要確保應用程序和數據安全，在進行安全和風險管理（Security and risk management，SRM）時，應當注意：

將安全和合規測試無縫地整合到DevSecOps中，使開發者專註工作在持續集成和持續部署工具鏈環境中。
持續的掃描已知的漏洞和配置錯誤，對象包括所有開源的和第三方組件。理想情況下，管理並維護一套完整的資產清單，便於完成對所有軟體組件的分析。
不要嘗試刪除自定義代碼中所有未知的漏洞，相反，應把開發人員看作放在最嚴謹和最自信的人。
鼓勵嘗試使用新的工具或方式，以減少與開發人員的摩擦，例如使用互動式應用安全測試（IAST）來取代傳統的靜態和動態測試。
把信息安全團隊完美地融入DevOps進程中。
使用相同的統一的規範來處理所有自動化腳本、模板、圖像和設計，並保證安全工作覆蓋了所有的源代碼。

企業對DevSecOps的戰略規劃

Gartner 分析師的調查結果顯示：

2019年，超過70%的企業將實施DevSecOps的相關舉措，實現針對開源軟體和商業軟體包的自動化安全漏洞和配置掃描，2016年這一數據低於10%。
2021年，80%的快速發展團隊將實踐DevSecOps的舉措，2017年這一數字為15%。

當今，DevOps已經成為企業IT能力快速發展和持續交付的首選方法，正確的實施DevOps對企業發展至關重要。

儘管大多數情況下，DevOps未能合理的處置安全性和合規性的問題，但值得高興的是，企業越來越重視這一情況，根據Gartner的調查數據顯示，在受約束的環境中實施DevOps，最優策略是與信息安全緊密結合，如下圖所示：

*來源：Gartner（2017年10月）

在過去的一年中，Gartner的調研數據顯示，「如何安全地將安全性集成到DevOps中（即交付DevSecOps）一直是客戶感興趣的領域中關注度遮增長最快的結點之一，Gartner的分析師們進行了600多次的調查，不斷的與不同的客戶進行交流，溝通他們在DevSecOps方面實施了那些卓有成效的舉措，通過分析這些案例，總結出了十項最佳實踐，SRM的領導者如果想要成功的交付DevSecOps，可以優先考慮這些方法。

成功交付DevSecOps的十條建議

（1）使您的安全測試工具和過程能夠很好的適應開發人員，而不是背道而馳

DevOps的哲學植根於它打破了傳統IT領域的陳規，打通了開發和運營的脈絡，然而，安全是另一個需要被移除和整合的領域。如果能正確的實施，DevSecOps里的「安全」應當是靜默的，換句話說，DevSecOps的目標應該是儘可能的將「安全」無縫並透明地交付給開發者。

不要強迫DevOps開發者去適應信息安全的傳統過程，相反，應當有計劃的持續性的將安全無縫地集成到開發者的持續集成/持續部署（CI / CD）的工具和流程中。對於那些習慣於迫使開發人員遵從我們的流程的信息安全專業人員來說，重要的是要轉變心態，因此有必要進行一些調整，例如：

不要使開發者離開他們熟悉的工具鏈環境。這意味著你的安全測試需要集成到開發者的開發環境（IDE）和CI/CD工具鏈的工具中（如Jenkins、Bamboo、Microsoft Team Foundation Server、Chef、Puppet 或Ansible）。
集成安全掃描，使信息安全專業人員不需要再掃描應用程序，例外情況下，才需要信息安全人員提供援助。應儘可能做到，一切對開發人員來說都是自動化的和透明的。
通過應用編程介面（API）構建安全性和合規性掃描平台，而不是通過安全廠商的本地控制台。測試結果應在通過你自己開發的儀錶板來呈現（例如Sonar、Maven 或 Jenkins）。因此，要求所有安全掃描工具和服務都完全API化。
使用威脅建模工具作為非功能性需求的一部分，自動化簡單的收集所有新增應用程序的安全需求。
通過開發者現有的漏洞跟蹤過程（如JIRA或BugTraq），解決檢測到的安全問題。
改變心態，將一次性的安全掃描轉化成連續地安全保證過程，從項目一開始就將安全集成進去，並評估每一次新的迭代。

（2）不要試圖在開發過程中消除所有漏洞

有一句流傳了幾百年的格言，後來因伏爾泰的推崇而聞名：

Il meglio è nemico del bene (Pescetti)

Le mieux est l』ennemi du bien (Voltaire)

這句話的意思是「完美是好的敵人/完美是效率的敵人」，其所揭示的寓意放到現在依然適用，尤其是在數字化商務領域，在那裡，「信息安全驅動完美」的安全理念與企業和開發者對速度和敏捷性的需求往往是不一致的。

沒有完美的安全，零風險是不可能的。對於DevSecOps而言，我們要做的是持續的風險和信任評估以及對應用程序漏洞進行優先順序排序。為了消除應用程序可能存在的所有漏洞，我們將會放慢開發人員的進度，尋找那些不是真實的（誤報）的問題，或者解決真正的、但不是直接或容易利用的低風險漏洞，無疑是在浪費開發人員的時間。

在測試速度、浪費開發者時間（誤報和假陰性風險增加）之間需要權衡。實施DevSecOps時，信息安全人員必須接受：「零漏洞」既不可能也不可取，尤其是當它明顯阻礙了新服務開發和創新步伐的時候。

此外，我們可以通過使用運行時保護控制來補償已知的、較低風險的脆弱性或未知的脆弱性的剩餘風險：

基於網路和主機的入侵防禦系統（IPS）（以防止對已知的操作系統和軟體包的攻擊）。
Web應用防火牆（WAF）。
運行時應用程序自我保護。
將應用程序性能監視和應用程序安全監控融合在一起。
使用合適的殭屍網路緩解方案。
在應用層進行深度防禦，包括負載均衡、拒絕服務和分散式拒絕服務保護。

思考並處理應用安全問題時，通過DevSecOps持續改進應用程序的開發和運營過程。需要明確，我們不需要消除開發過程可能存在的所有漏洞，運行時保護措施是DevSecOps戰略的重要組成部分。DevSecOps是一個需要不斷完善的過程，如下圖所示：

安全不應止步於開發階段（上圖的左側），整個DevOps生命周期都需要保護，包括新服務的部署後的運行階段（上圖的右側）。安全，就像開發一樣，成為一個連續的交付、學習和改進的過程。

在開發過程中執行基於風險的掃描，被接受的一些漏洞將運行時的持續評估來進行補償。總之，如果沒有監管方面的缺陷，那麼可以接受多少風險並不取決於信息安全，而是由產品/服務所有者最終做出的商業決策。

（3）首要任務是識別並移除已知的嚴重漏洞

現代軟體是組裝而成的，而不是開發出來的。開發者們從公開可用的源代碼和代碼庫（如GitHub，SourceForge，Maven central 和 Docker Hub）中收集並整合了大量的預編譯組件、代碼庫、容器和框架（如Apache Struts和Swing）。自定義的代碼在現代軟體中所佔的比例少之又少。

相應的，安全掃描的焦點也有所轉移。大多數風險都可以通過識別這些公開庫、框架和組件的已知的漏洞和錯誤配置來完成，問題解決之後才投入生產。從安全的角度來看，識別已知代碼中已知的漏洞比自定義代碼中的未知漏洞要容易得多。實現方式多種多樣，最簡單的一種方式是將文件與漏洞庫相匹配。脆弱性評估供應商調整他們的掃描能力，將這些操作集成到DevSecOps中自動化的完成，諸如Docker之類的工具供應商也提供此類整合能力，這種最佳實踐的重要性不能低估。Equifax公司因Apache Struts漏洞而遭遇數據泄露的教訓十分沉重。

開源軟體（OSS）提出了一個獨特的挑戰，因為開發人員可以簡單地剪切和粘貼源代碼，而不是關聯整個庫或框架。這樣一來就不能簡單地通過哈希值進行識別，，而是需要全面的掃描源代碼本身。此外，OSS的使用可能因授權問題產生一些法律風險，因此建議使用商業軟體組成分析（SCA）解決方案為應用程序構建詳細清單，這個清單還有一個延長生命周期的好處，如果之後所使用的組件包含一個嚴重的安全漏洞，安全團隊通過這份清單可以快速的查詢並明確「哪些應用程序受到了影響」（例如，著名的Apache Struts或OpenSSL的Heartbleed攻擊）。

評估應用程序已知漏洞的過程中，SRM負責人應該掃描：

開發人員工作相關的全部內容（包括虛擬機、容器和機器鏡像），應充分考慮容器安全及相應的最佳實踐。
所有嵌入的OSS代碼的已知漏洞。
所有的OSS組件（包括庫和框架）。
所有的操作系統文件、可執行文件和動態鏈接庫。
所有平台文件（如Apache和Microsoft IIS）。
第三方商業性的代碼庫。
第三方公共的應用程序（如SQL Server和Oracle）。
與配置相關的漏洞（例如埠的打開/關閉、服務的激活和正在運行的進程）。

「掃描」的概念也應該擴展到識別惡意軟體和敏感數據，而不僅僅是編碼方面的漏洞。SRM負責人應該確保加密密鑰和其他機密數據不會意外地嵌入到代碼中。

（4）不要固守傳統的靜態/動態分析方法，應當適應新的變化

上文中我們強調了識別已知的組件、庫和框架中的已知漏洞的重要性，但是對於應用程序中那些實際存在的10%～40%的自定義代碼該如何處置呢？執行DevSecOps，意味著你應該尋找自定義代碼的未知漏洞。但是，不要固守那些傳統的針對應用程序安全測試的靜態和動態分析工具和服務，要明白這些傳統的測試解決方案需要被重構、調整或更換，具體步驟如下所示：

可以從把簡單的測試直接集成到IDE開始。一些開發者提出基於IDE的安全掃描的指標無法被跟蹤和報告，這可能成為與DevOps建立合作夥伴關係的契機。
所有的掃描工作應該是完全自動化的，在開發者的CI/CD工具鏈和諸如代碼提交之類的事件處理過程中自動的通過APIs的方式觸發，通過API引發開發商的CI / CD的工具鏈和過程事件像提交代碼。第三方產品（如Cybric和BMC）可以幫助開發者實現安全檢測自動化。
掃描不應該要求安全專家運行、配置或解釋結果，開發者就可以做到。
掃描應該不斷調整，以減少誤報，即使是犧牲假陰性（漏報增多）。
掃描結果應直接運送到bug跟蹤系統或開發者面板，這依賴於開發者使用的CI / CD工具和方法。

無論執行哪種安全掃描，SRM負責人都應該按風險把發現的漏洞進行優先順序的排序，並提供給開發者。工作重點應放在減少誤報，在充分信任開發者的基礎上指導他們優先修復嚴重的漏洞。正是因為這個原因，幾個AST供應商正在嘗試使用機器學習來修正掃描結果。接受較低風險的漏洞是可以的，這些漏洞可以通過運行時的保護控制來減輕，或者在將來的軟體迭代中加以解決。

考慮互動式應用安全測試（IAST）替代傳統的靜態應用安全測試（SAST）和動態應用安全測試（DAST）是可行的，我們建議這麼做。IAST是在DAST基礎上的一種該進形式，測試過程更加可視化，包括內部和外部的。IAST綜合了DAST和SAST的優勢，在確保測試代碼覆蓋率的基礎上儘可能的做到了減少誤報。然而，目前支持IAST的平台有限，需要應用程序在運行狀態下才能執行IAST。如果IAST工具被用作開發者進行掃描的誘導工具，那麼之後需要一套完善的全回歸測試（而且最好是自動化的）進行配合。

一些AST供應商提供「測試即為服務」。可以將其融入DevSecOps中，但運作時間限於雙方嚴格的服務水平協議（SLA）約定，使用IDE進行輕量級的、近實時的掃描。例如雙方可以約定，四小時內掃描50%，八小時內掃描80%， 24小時內掃描90%，SLA還包括一些服務有效性的保障，不符合條件的話可能就會被罰款。注意，即使SLA約定的條款「時間緊迫」，以致於可能不適合極為迅速的DevOps周期，但供應商也應該通過API提供測試服務，確保開發人員仍能使用相同的應用程序「提交」代碼進行測試或檢索結果。

（5）培訓所有開發人員基本的安全編碼知識，但不要期望他們成為安全專家

DevOps產品團隊的每個人都應該接收安全培訓，培訓內容因角色不同而有所不同。開發人員應當獲得最多的培訓，測試人員和產品負責人相對少一些。注意，儘管應當向所有開發人員培訓基本的安全編碼知識，但卻無法讓這些團隊成員成為安全專家。例如，大多數應用層漏洞可以通過設置輸入白名單和過濾掉多餘的字元進行處理；SQL注入和跨站點腳本攻擊的根本原因是在輸入時缺乏適當的檢測；同樣的原則也適用於資料庫和配置文件以及網路流量的輸入檢測。

重點推薦OWASP Top10和類似的公開可用的安全測試指南。培訓應包括：

如何構建並維護簡單的威脅建模場景（像壞人一樣思考）
設置輸入白名單，對用戶的輸入和文件進行過濾和消毒

SQL注入
XSS
CSRF

注射
破壞認證和會話管理
不安全的直接對象引用
安全性的配置錯誤
基本的安全防護

為什麼不能在應用程序代碼或腳本中嵌入密鑰或憑據？
打補丁的重要性
為什麼黑客專註於盜竊管理員的憑據？如何避免此類攻擊？

理想情況下，第一次培訓時應當由相關人員當面進行，之後定期進行年度培訓，同時運用線上培訓的方式加以強化。此外，如果在開發中發現了安全問題，則可以根據需要對開發人員或團隊進行進一步的具體培訓。例如，如果在開發人員的代碼中發現了一個嚴重漏洞，則可就該問題上進行進一步的培訓，避免問題再次發生。

（6）採用安全捍衛者模型，並實現簡單的安全需求收集工具

在《DevOps Security Champions Help Organizations Gain Leverage Without Training Everyone 》一文中，我們建議企業使用安全捍衛者模型，將有效的信息安全團隊資源充分應用於開發組織。將安全捍衛者的頭銜授予組織中能夠擔當現場顧問和專家的員工，他們可以在開發過程的早期就預見到可能存在的潛在的設計或實現問題。

安全捍衛者可以有效提高複雜的安全編碼問題的感知度，他們能夠提供及時的、針對團隊編碼過程中遇到的實際問題提出修復方案，而不是抽象的、不可靠的問題。例如，對於風險為低級或中級的新應用程序開發項目，安全捍衛者可以作為安全需求收集和威脅建模的起點。推薦企業使用一個簡單的安全需求收集和威脅建模工具，使得開發人員儘可能地輕鬆完成任務。對於風險級別高的應用程序，目標應該儘可能的提高，建議直接聯絡信息安全團隊進行全面地威脅建模和安全需求收集。

SRM負責人應該識別那些對安全感興趣的開發人員，並為他們提供一個擴展的角色，即安全捍衛者。這樣做會使有限的安全培訓的效果更佳，為敏捷開發過程和DevOps團隊成員提供一定級別的安全監督。

（7）禁用源代碼中已知的易受攻擊的組件

前文已經提及，現代應用程序的大多數風險是由於使用已知的易受攻擊的組件、庫和框架導致的。與其等到應用程序組裝好之後在掃描環節才被識別出這些已知漏洞，提前警告開發人員不要下載和使用這些已知的易受攻擊的組件可能是更好的解決問題的辦法，尤其是當存在嚴重漏洞時，可以選擇提前阻止開發人員下載。

實際開發環境中，是否允許開發者從互聯網上下載代碼的問題應由安全和開發架構師共同協商處理。某些組織認為這樣做的風險很高，因此開發人員被阻止直接從Internet下載這些風險組件；還有一些組織，會限制用戶將代碼託管到公共代碼平台上（如GitHub）。

開發人員下載的代碼庫中可能包含較老的、已知的易受攻擊的軟體版本。為了解決這個問題，一些提供商提供了「開放源碼軟體防火牆」，以便向開發人員披露這些代碼庫的安全態勢，便於更好的決策使用哪個版本的軟體。通過這種方法，開發人員可以明確的清楚那些組件和代碼庫存在嚴重漏洞，避免下載並使用（例如，可以使用漏洞的CVE評分來判斷該漏洞的嚴重程度）。

對於那些不允許開發人員直接從公共Internet下載代碼的組織，需要考慮使用安全的代碼存儲庫模型，此時，需要信息安全團隊與開發團隊協同合作，建立、審查並維護這些組織內部託管的組件存儲庫，在這個過程中，開發架構師和信息安全工程師之間應保持聯繫，隨時更新開發人員請求使用的新框架和代碼庫。此外，一些機構會要求使用符合安全需求的、預先批准的、標準化的代碼庫或組件（如認證、授權、密鑰管理、加密、點擊劫持和輸入過濾），以便於進一步降低風險。

（8）使用自動化腳本確保並踐行操作的規範化

不要對基礎設施和運營平台的安全管控。想要實踐「基礎設施作為代碼」的話，針對基礎設施也應當有類似源代碼控制一樣的措施，包括所有的軟體項目的版本控制（如配置腳本和可執行文件）。應確保這些控制項使用了正確的腳本版本，平台控制和配置腳本不應包含機密信息（如憑據、密鑰或其他公開的漏洞）。可能的話，需要針對這些工具進行專門的安全掃描。

對於這些自動化代碼、腳本、方法或生成腳本的工具等基礎設施和平台構件，應看作具有特定附加風險的有價值的源代碼，因此，有必要對它們使用源代碼相關的安全管控，包括審計、保護、數字簽名、變更控制和版本控制，以保護這些基礎設施和平台構件。

容器和容器管理系統必須具有記錄並留存變更控制信息的功能，確保所有已知的漏洞已經被妥善處理。

總而言之，所有變更都應當有明確的記錄。

（9）使用強大的版本控制措施管理所有代碼和組件

在軟體開發的整個生命周期中，使用適當的工具（如分散式版本控制系統[DVCS]和應用程序生命周期管理[ALM]工具）進行恰當的源代碼版本控制。

在快速更迭的開發環境中，捕捉變更的每一個細節至關重要，包括代碼的出處、更改的內容、時間和操作者，以及是否已經獲得了相關授權（例如，其他產品經理的產品可能受到變更的影響）。在大多數情況下，並沒有一個明確的許可權模型，但是這種情況可以適用「信任和驗證」的原則，使用一些方法獲知某人調用了某個API或使用了某些代碼。明確使用的代碼與生產中實際使用的代碼之間的區別，這樣做有利用在將來的迭代中通過刪除未使用的組件來降低風險，或者刪除那些存在漏洞但卻未實際使用到的代碼。

代碼從預發布到生產，檢測代碼的數字簽名，並確保最終的版本是最後一次掃描過的版本。注意，在代碼運行時不要實例化，無需確認它是否被篡改，代碼配置即防篡改確認是「防護」階段的功能。平台運營團隊將使用傳統的變更控制技術（包括ITIL方法）為產品團隊提供底層的基礎設施和平台。

（10）默認的基礎架構應當是「不可變的」

對於經常更新的現代化應用程序而言，維護這些應用程序需要採用一種更安全的操作方式。在可能的情況下，不允許任何人直接對生產系統進行更改。基礎設施應當是「不可變的」。當需要更新時（包括安全補丁和配置更改），這些需求應該返回到開發階段並由自動化工具進行部署。

生產的鏡像（包括庫、組件和OS）應當保存在安全的存儲庫中。如果某個文件需要修補，請在安全的存儲庫中進行，而不是直接在生產系統上修改。此外還需要確保新修補的應用程序可以使用現有的DevOps流程進行部署。要知道大多數的安全事故和操作不當導致的事故產生的根本原因是管理不刪或未打補丁，流程規範化可以帶來安全和操作上的益處。

從操作和安全的角度來看，許多現代容器和工作流程系統都包含自動化的健康監測功能，當偏離預期狀態時會發出警報。如果工作流程行為怪異或與正常狀態相比偏移過多，則可以從活動資源池中刪除它，用清洗後的良好狀態的工作流程取代它。

從安全的角度來看，這種模式是先進的，並且有可能從根本上提高安全性，通過主動「殺掉」目前的工作流程，並用已知的良好狀態替換它們，即使它們看起來是「健康的」。假設一個聰明的黑客以某種意想不到的方式在系統中獲得了立足點，通過周期性地、隨機的殺死工作中的進程，可以使得攻擊者的立足點丟失，無法獲得持久性。五年前，曾提出過一種「利用系統的工作流程作為一種對抗對抗高級持續性威脅的策略」的概念，那時候還只是一種願景，但現在技術的發展使得這種方法成為可能。

DevSecOps：應當做好的十件事

背景介紹

DevSecOps的概念

企業對DevSecOps的戰略規劃

成功交付DevSecOps的十條建議

更多資料