作者簡介：潘志祥，資深安全研發顧問、安全靈活教練、DevSecOps專家、安全工具專家、研發效能專家。有10年軟體安全行業從業經驗。具有豐富的研發實踐、安全工具開發和實踐、S-SDLC實踐、DevSecOps實踐經驗。輔導多家企業從零開始建構DevSecOps、S-SDLC。
一、DevSecOps與供應鍊安全
現在很多企業都建立了DevOps流程，但安全基本還處在流程之外，沒有融入傳統DevOps流程，導緻安全一直都是靈活傳遞的瓶頸。
1、DevSecOps———供應鍊安全治理基石
在很多企業尋求DevSecOps解決方案的背景下，安全左移的理念愈發重要。美國國防部白皮書中也提到DevSecOps落地的核心就是安全左移，但其中強調的安全左移是在研發階段做安全測試，這樣的左移并不徹底。真正實施安全左移比較徹底的是微軟的SDLC理念，強調安全應該在更早期階段介入。
經過近幾年的不斷實踐，DevSecOps已經做到了比較深度的安全左移，并不隻是在研發階段做安全測試，而是在需求階段就考慮安全，甚至是在立項階段就介入安全。
安全左移的價值不容忽視，我們知道在不同階段發現并修複問題的成本是呈幾何增長的。如果在研發階段發現并且修複問題的成本是“1”，在測試階段修複問題的成本就是“2”，在釋出階段修複問題的成本就變成了“10”，在運作階段發現并修複問題的成本就會是“100”，甚至于對業務營運的影響難以估量，因為有些安全問題就是一個企業的生命線。
2、供應鍊安全治理落地難點
供應鍊安全治理環節分散。在編碼、編譯、部署等環節都容易出問題。
研發修複成本高。安全問題修複滞後，頻繁回歸。
供應鍊安全治理依賴多工具能力。單一工具難以覆寫供應鍊安全所有的治理對象，現在提到供應鍊治理工具基本都是SCA，但是像作業系統、中間件這些都是在供應鍊治理過程中需要考慮的治理對象。
安全是孤島而不是流程。安全工具獨立使用，安全漏洞隻存在于安全工具内，沒有跟研發、測試、安全、運維流程打通，沒有融入流程，進而導緻安全工作隻能階段性介入，影響傳遞節奏和周期。
缺乏全流程治理經驗。基于安全木桶理論，補足安全短闆，做到供應鍊安全的全面治理也有賴于安全經驗。
沒有供應鍊資産管理。這一塊主要是針對SBOM解決方案而言，SBOM隻是一個靜态的軟體物料清單，如果發現0day安全問題，掃描所有代碼倉庫的效率顯然太低，而且掃描之後能否快速呈現有問題的軟體，也是需要去考慮的，從資産管理以及事後盤查等角度出發。
3、傳遞管道
CI/CD傳遞管道，也就是流水線，現在的安全工具基本都是采用編排的形式接入到流水線中。因為安全工具種類繁多，不可能每一個都登入進去制定掃描計劃，加上現在很多核心系統都實作了服務化改造，在每個工具上針對每個服務應用去建立檢測任務的工作量對安全團隊來講幾乎無法完成，是以現在的安全檢測工具已經上升到了編排的次元。
值得一提的是，盡管在流水線中可以同時發起多個檢測工具進行檢測，但在實際情況中并不會這樣來編排流水線。如果是研發測試環境的流水線，通常會将安全檢測全部靠後，因為此時要做的事情是快速把應用建構起來進行部署，然後讓研發和測試去驗證功能。驗證完功能之後，再去看安全檢測工具檢測到的漏洞，因為在部署之後，安全檢測工具同時開啟檢測，功能測試與安全檢測工作幾乎可同時完成。
如果是針對上線的流水線，所有安全檢測工具編排會盡量靠前，而且此時安全檢測工具必須要有安全卡點的能力，也就是在每個工具中設定一個安全門檻值，比如針對SCA工具，定義它的超危元件不能超過一個，否則不允許執行後續的流水線。通過這種方式，就能實作品質一緻性保障通道。所謂品質一緻性保障，就是無論在何種業務研發背景下，每次通過流水線傳遞出去的制品都符合品質要求。這就能形成一種文化，即研發人員在送出代碼時就會思考能否過安全卡點，如此思考安全問題的方式也就得以改變。
此外，現在針對安全工具的很多解決方案是在流水線裡寫一個腳本，把代碼送出到白盒檢測工具中掃描，然後去拿檢測結果，但是現在很多微服務應用少則幾十個，多則成百上千個。面對上千個應用，每天送出一次代碼到流水線中檢測，任何一款白盒工具能無法支撐。是以将安全工具放到流水線中，常态化、自動化執行對于安全工具的技術要求也發生了根本性的變化。它并不是在流水線中簡單寫個腳本去調用檢測工具的檢測接口，然後擷取資料，而是要考慮每一種檢測工具的檢測能力是分布式的。
是以我們在DevSecOps流水線中可以衍生很多跟現在企業實施思路不一樣的地方，我們可能要評估現在的流水線能否承載核心系統未來的業務發展，整個安全執行的效率是否達到要求。而且無論在什麼狀态下，軟體的品質都要符合風險可接受的範圍。
二、DevSecOps安全能力體系建設
DevSecOps有兩個發展方向，一個是One by one，一個是All in one。
One by one就是基于Jira、Jenkins、GitLab的解決方案，組合在一起形成一個自動化流程。All in one是一體化平台，它不是簡單的将工具內建進來，而是在平台上重新開發。
1、DevSecOps一體化平台
DevSecOps是效率的代名詞，之是以很多企業一直在提倡它，是因為供應鍊治理工作的複雜性，除了供應鍊治理以外，還要考慮雲原生安全、應用安全、資料安全、合規安全等，企業要想做好這些安全工作比較困難。White Hat組織在2021年針對全美公共事業部的網際網路應用釋出了一份安全調研報告，報告顯示制造業有60%以上的企業存在可利用漏洞，暴露視窗期在365天以上，金融行業有40%以上的企業存在此類問題。由此可見，國内的線上營運系統，其安全狀況也不容樂觀，在這種情況下一體化平台将是發展的必然趨勢。
根據GitLab和Jenkins的官網介紹，GitLab的配置檔案叫gitlab-ci.yml，是解決持續內建的問題；Jenkins的配置檔案是Jenkinsfile，是持續部署的解決方案。國外的CI/CD流水線比較嚴謹，CI與CD的功能更加明确，但是簡單的将GitLab與Jenkins相加并不等同于CI/CD，是以真正在做CI/CD時必然是向一體化的趨勢發展。
在一體化的平台架構之下，可以進行大量的資料挖掘。需求從郵件清單提出來，進入到需求中心，到産研環境，再到預發環境，然後上線。需求這一資料對象流經很多工具，每一個工具停滞的時間都由不同角色的工作來決定。DevOps講究高效的端到端價值流傳遞，但是像需求平均傳遞周期、需求流負載、産研周期等名額都統計不出來，就不能算真正的DevOps，隻是一個自動化流程而已，這也是很多企業的現狀。是以一體化的DevOps，也将是未來研發效能的發展趨勢。
2、DevSecOps安全能力體系
DevSecOps安全能力體系，就是針對整個研運流程去做安全能力抽象。比如在設計階段做威脅模組化，但現在做威脅模組化的企業并不多，因為它的落地非常依賴于負責人豐富的經驗，除了要懂安全，還要懂滲透、攻擊、研發、架構、業務等等，才能考慮怎樣去解決這些風險。
在供應鍊這一塊需要做很多檢測，比較多的就是直接引用的第三方元件，我們在供應鍊中經常會提到開源軟體，但是我更偏向于提開源元件或第三方元件，因為開源軟體的範圍太泛了。比如Redis緩存，從第三方元件的角度來考慮，就是在代碼裡引入了一個Redis的調用元件，這個元件可能有問題，但是Redis部署的服務可能也有問題，是以開源軟體治理的範圍從元件和軟體兩個角度來講，就有兩個不同的次元需要去治理。
Redis的環境基本上都要進行基線掃描，甚至要人工去做安全配置檢查，是以安全不能隻想着引入工具和如何使用它，而是這個工具能解決什麼問題，接下來要怎麼把它放到流程裡面，自動化建立起來。
接下來，如果要做供應鍊安全治理，隻需要建立一個視圖即可，能查到所有應用資産下面的元件漏洞資訊，以及每一個部署環境的資訊。所有的檢測任務或者漏洞的修複情況，隻需在流程中完成即可。
三、DevSecOps實踐落地
實踐一：IDE安全自測
一旦建立流程之後，必須確定讓研發有一個高效的流程可以提前感覺，因為研發會考慮送出的代碼要過安全卡點，否則會影響KPI考核。而且代碼送出到線上之後觸發CI流程比較耗時，如果在IDE層面有檢測插件，研發就可以快速自測，就能知道自己引入了哪些有問題的包，經修改檢測無誤就可以将代碼上傳。
實踐二：建立安全私服
如果我們使用第三方私服，或者不對内部的私服做任何安全管控，在做軟體建構之後就需要依賴大量的檢測。如前所述，在測試階段發現漏洞的修複成本是研發階段的兩倍，是以為避免在研發階段投入更多成本，可以在所有的第三方元件進入私服時進行安全審計，隻有符合安全要求才能進入私服。其實這也是SCA工具的一個功能，它開放了一個網絡代理，當我們去公共的元件倉庫下載下傳元件時，元件會經過代理的檢查，檢查通過再将其放到倉庫中；如果檢查有問題，可以有不同的處理政策，比如先放到一個緩存隊列中去做評估或者直接拒絕。在具體實施時，可以再配置外部私服，然後動态去做入庫檢測以及建構的動作。
實踐三：建立一緻性品質内循環
CI/CD是兩個階段的流程，但是現在企業能做到CD的并不多，因為CD有不同的了解，一個是持續傳遞，一個是持續部署。持續部署是一個技術行為，跟CI差不多，但是持續傳遞則需要非常多的能力來支撐。CI環節也不是一個過程，因為在不同的環節有不同的流水線去做安全工作，整個安全工作已經實作了一個常态化自動化，靈活的特點就是小步快走，檢測到增量漏洞後快速修複，這個增量漏洞并不隻是定義到修複超危漏洞，而是低危漏洞也要一起修複。這是進入了一個比較好的狀态，品質内循環建立起來會非常高效，軟體安全的品質控制也會更加高效。
實踐四：建立安全管控機制
安全管控機制，就是前面說到的安全工具卡點，現在幾乎是沒有哪一個安全工具有卡點能力。一般做安全卡點，都是自己通過寫腳本，然後去判斷目前的安全漏洞資料情況。現在的工具可以去配置添加不同的卡點門檻值要求，然後去選擇執行政策，比如說終止或繼續，同時還可以快速通知到相關的責任人。