關鍵詞
- DevSecOps — 在不影響敏捷性的前提下，將安全充分融入到SDLC的所有環節中
- SDLC—軟件交付生命週期
- SCA—軟件組成分析-用於識別和檢測軟件中使用的開源/第三方組件的已知安全漏洞
- SAST—靜態分析安全測試
- DAS—動態分析安全測試
- IAST—交互式分析安全測試
- SBOM— 在這裏特指軟件中使用開源組件的完整信息列表
開源帶來的供應鏈風險
軟件供應鏈是將“原材料”（代碼）進行加工（修改、編譯等）交付（分發或再分發）給用戶的過程。
軟件供應鏈安全指在軟件設計與開發的各個階段中來自本身的編碼過程、工具、設備或供應鏈上游的代碼、模塊和服務的安全，以及軟件交付渠道安全的總和。軟件供應鏈因其複雜多樣且攻擊簡單的特點，極易成爲攻擊者的攻擊目標
- 超過90％的企業/組織在關鍵開發項目使用開源軟件
- 超過90％的新代碼庫由開源軟件構成
- 其中85％的對應開源軟件社區超過兩年沒有或很少被維護
- 開源不等於不需要/不遵守licenses
- 超過80%的企業/組織不能清晰的掌握“SBOM”，更無法快速修補漏洞
- 2017年Equifax大規模數據泄露的主要誘因之一就是缺乏完整的“SBOM”
- 2018年AST漏洞的平均年齡爲6歲，略高於2017，補救措施沒有顯着改善
- ”開源工具“的快速廣泛普及，漏洞利用窗口時間從45天縮短到3天
開源治理的建議步驟
使用開源本身並不存在風險。爲了抵禦開源的安全性和合規性風險，我們建議採取以下方法步驟
1、安全充分融入到SDLC的所有環節中—實施自動化流程，使用高度集成的SCA/AST工具追蹤審計代碼庫中的開源組件及其已知的安全漏洞，並根據嚴重性確定補救緩解的優先級。
2、建立完善的“SBOM”體系—任何組織無法防禦自己不知道的威脅。獲取其代碼庫中已經在使用的開源組件“SBOM”至關重要
軟件供應鏈安全防護一般需要遵守以下原則，供應商需要給出明確的軟件物料清單（SBOM），SBOM描述了軟件包依賴的一系列元數據，這些信息在分析軟件安全漏洞時發揮着重要作用。同時在軟件開發、交付、使用的所有階段，需要最小限度暴漏軟件的SBOM及其他詳細信息，避免被攻擊者有針對性的利用漏洞進行攻擊，提高攻擊者的攻擊成本。隨着新漏洞的出現，安全防護系統需要及時響應漏洞以應對新的威脅，定期監控組件的狀態，如組件使用壽命即將耗盡或開源貢獻者可能放棄組件並對其停止維護，在這些情況下，必須能夠檢測到組件風險狀態的變化，確定風險嚴重程度的優先級，並在必要時關閉或維護組件。
3、建立與NVDs的合作體系—從NVD、CERT、平臺級SRC獲取開源軟件漏洞披露信息是一種必要的手段和能力。同時這些信息的貢獻者—安全公司/組織通常會更早提供詳細的通知和修補建議。
4、漏洞監測伴隨終身——即使您的開發過程已經結束，跟蹤漏洞的工作也不會結束。只要你軟件仍在使用，就需要持續監控新的威脅。
5、識別開源組件的許可證風險—沒有遵守開源許可要求可能會使公司面臨法律訴訟等重大風險。培訓開發人員瞭解開源許可證及其義務，並讓您的法律顧問參與其中。
6、商業估值應充分考慮開源問題—如果您正在進行收購/投資，如果軟件資產是目標公司估值的重要部分，請不要猶豫的進行第三方開源代碼審計。
實施DevSecOps緩解風險
許多企業/組織已經充分認識到使用開源組件所帶來的風險，同時清楚的意識到事後補救遠遠比事前預防要花費更多的成本和時間。
那麼良好實現DevOps的最後一步，既是將安全管理與合規性審計集成到開發和運營團隊的日常工作中，從而使安全管理成爲SDLC中所有環節的一部分，而不是將此任務侷限在安全團隊。在開發和運營團隊已經應用的DevOps流程和工具中構建自動化安全舉措，並且及時更新、反饋、總結和改進這種措施。
DevSecOps 是 Gartner在 2012 年就提出的概念，自2017年首次引入RSA大會，從DecOps的概念延伸和演變而來，其核心理念安全是整個IT團隊（包括開發、運維及安全團隊）每個人的責任，需要貫穿從開發和運營整個業務生命週期每一個環節才能提供有效保障。
2018 RSA大會提出了“Golden Pipeline“（黃金工作流）概念，強調自動化工具鏈支撐。是指一套通過穩定的、可落地的、安全的方式自動化地進行CI/CD的軟件研發工作流。 其中，關鍵安全活動包括：“Golden-Gate”、AST應用安全測試、SCA第三方組件成分分析和RASP運行時應用自我保護。
- Golden-Gate黃金門，目的是制定安全閾值，也是軟件可以接受的最低安全標準，應該也是採用威脅分析和安全建模得到需要後續流程中應該進行達到的安全設計、安全實現、安全測試驗證需要達到的目標。
- AST應用安全測試，則包括了SAST、DAST和IAST三類安全測試技術。通過在DevOps流水線的不同階段，分別從靜態代碼分析，動態應用測試以及交互式應用安全檢測三個方面引入合適的工具。
- SCA則是針對軟件中的開源軟件（OSS）和第三方庫軟件鎖涉及到的框架、組件、庫等，識別軟件成分清單並識別其中的已知漏洞。
- RASP則主要是在運營中進行安全檢測和安全阻斷。
相比複雜的雙環模型，Golden Pipeline無疑是一種便於理解和落地的實現方式。
2019 RSA大會上，大量從業者意識到DevSecOps實施過程帶來的文化衝突，並嘗試解決這個問題，並提出了DevSecOps宣言（如下），強調DevSecOps融合文化的建立需要對組織重新設計，將安全人員融入每個開發團隊，使得掌握安全能力的專家深入業務、開發、運維等各工作活動，讓DevSecOps真正創造價值，避免成爲效率瓶頸。
- 建立安全而不僅僅是依賴安全
- 依賴賦能的工程團隊而不僅僅是安全專家
- 安全的實現功能而不僅僅是安全功能
- 持續學習而不是閉門造車
- 採用一些專用或常用的最佳實踐而不是“僞”全面的措施
- 以文化變革爲基礎而不僅僅依賴規章制度
2020 RSA大會上，將風險管理、合規與治理融入DevSecOps的實踐探索。研討了企業如何向DevSecOps轉型以及過程中可能所面臨的障礙，如何從公司各層面上獲得支持，包括DevSecOps人才招聘、培養也是需要考慮的重要方面。
實施DevSecOps的具體舉措
1、優先將安全檢測應用到現有的軟件缺陷審計和安全事件調查中——首先將安全檢測集成到已知的軟件缺陷審計和安全事件調查流程中，目的是對已知問題充分進行安全方向上的根因分析，以防止再次出現同樣的問題，並將經驗更新到DevSecOps流程的Checklist中。
2、管理維護好自己的源代碼共享資源庫——所有團隊應該使用經過安全認可的源代碼庫，除了代碼本身是經過安全審計，企業級的代碼共享庫還應包含經過合規批准的框架、組件、許可證、管理工具等。
3、儘可能多的自動執行安全測試——可持續集成CI/CD中，並且與整個過程中的其他測試並行開展。目的是通過簡單有效的反饋循環，以便開發和運營團隊及時驗證與處理。而不是等到SDLC結束以後，再進行耗時且昂貴的補救工作。使用可以與SDLC良好集成的商業工具已經成爲普遍有效的實踐
4、確保軟件供應鏈的安全性——90%的現代應用都是由開源組件構成的，使其成爲當今軟件供應鏈的基礎部分。我們繼承開源代碼功能的同時也意味着集成其漏洞和風險。因此先行檢測其中已知的漏洞必須作爲開發人員選擇開源組件及版本的重要選項。
5、持續培訓將DevSecOps作爲一種良好的企業文化——“全面質量管理”和“大Q”早以成爲企業的高層級文化建設之一，那麼“全面安全管理”或是“大S”是否也應該被考慮提升高度是管理層值得關注的事情。
實現DevSecOps的關鍵工具
1、SAST(靜態分析安全測試)——在編程和/或測試軟件生命週期（SLC）階段分析源代碼的安全漏洞，在發佈前修復它們。將自動化的SAST解決方案集成到SDLC中，持續識別潛在的安全問題非常重要。優秀的SAST工具還能提供準確的高可操作性修復指導，使開發人員能夠在早期處理安全問題。
2、DAST(動態分析安全測試)——在測試或運行階段分析軟件在運行狀態下應對攻擊的反饋，又稱爲黑盒測試，大多數DAST只針對web的應用。雖然DAST工具可能比SAST更容易使用，但它不能精確地定位軟件代碼中的特定弱點。
3、IAST(交互式安全測試)——IAST交互式安全測試是新一代“灰盒”代碼審計、安全測試工具，是近年來興起的一項新技術，其融合了SAST和DAST技術的優點，無需源碼，支持對字節碼的檢測，可良好的適用於敏捷開發和DevOps，可以在軟件的開發和測試階段無縫集成現有開發流程。
4、SCA（軟件組成分析）——類似於SAST，軟件組成分析(SCA)識別應用程序中的開源代碼組件並檢測其安全漏洞。通常單憑SAST很難識別這些開源漏洞，因爲有太多的開源組件被直接調用且非常複雜，準確的識別檢測並給出可操作的修補建議是評價SCA解決方案良好的重要指標。與SAST一樣，SCA工具應該能很容易地集成到DevOps流程中。
Building Security Into DevOps Process
傳統的DevOps往往對安全不夠重視。過去Ops 通常在部署之前被排除在外，而Dev將其代碼丟在無形的牆上，因而造成了消除開發和運營團隊之間的一些傳統衝突。同樣的，如果Sec是孤立的，也會存在類似的問題。安全必須是軟件開發流程中的“一等公民”，而並非最終步驟部署，或者更糟糕，只有在發生實際的安全事件後才受到重視。
DevSecOps 可以給研發效能提供諸多好處，主要表現在三個方面：
- 更快 - DevSecOps 通過自動化安全工具掃描，無感地左移了部分傳統模式中在上線前最後階段進行的安全掃描工作，使得整個交付週期變得更短，交付速度因此變得更快。
- 控制風險 - DevSecOps 減少了開發團隊對安全部門/團隊的依賴，通過安全左移讓開發團隊具備發現和修正部分安全隱患和漏洞的能力。
- 節省成本 - DevSecOps 由於在 SDLC 前期階段發現並且修正安全隱患和漏洞，避免了傳統模式中在上線前最後階段進行安全掃描發現高危安全漏洞後進行的返工，從而從流程上節省了成本
不過需要注意的：DevSecOps是將“安全”融入“研發活動過程”之中，將兩者融合起來。缺乏合適的管理，流程制度，和相關的安全運營團隊，最終依然是DevOps+Security，而不是DevSecOps。
- 例如對開發人員、測試人員的安全意識培訓、制定安全編碼規範並實施培訓，安全人員介入需求梳理、源代碼審計、上線前安全審查等，實現了軟件安全保障工作的左移。
- 安全工具不是 “DevSecOps” 的全部，更不是“銀彈”，缺乏安全團隊的監管和運營，安全工具只是“擺設”
- 加強“研發過程數據”的關聯，有助於“安全”風險的跟蹤和追溯
後續，會逐步跟大家分享DevSecOps相關的工具和實踐，具體解讀上述關鍵詞。