關鍵詞
- 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相關的工具和實踐，具體解讀上述關鍵詞。
RSA 2022: A Roadmap for Building Enterprise-Scale DevSecOps