針對代碼和應用程序的軟件供應鏈攻擊已經成為一種對互聯網經濟發展影響巨大的網絡攻擊手段。因此，加強代碼和應用程序的自身免疫力，保證應用程序敏捷安全地開發、交付和流轉，當前應作為網絡安全的一項重要任務來看待。在軟件供應鏈安全建設實踐中，DevSecOps平衡了代碼開發過程中敏捷和安全的需求，逐漸被行業接受和認可，加速DevSecOps的落地實踐并成為敏捷開發模式企業中開發安全建設的重要抓手。

　　日前，安全牛采訪了孝道科技聯合創始人兼CTO徐鋒，就如何在供應鏈安全建設中實踐運用DevSecOps進行了深入探討。徐鋒表示：“軟件供應鏈安全的影響已經上升到了國家安全的高度，企業對軟件供應商、產品供應商提供的軟件安全合規性要求越來越高，對違規處罰的力度也越來越高，這將有力促進安全開發、DevSecOps理念的快速落地。在DevSecOps模式下，更為強調全員的安全責任和共擔文化，每個人都要為系統應用安全承擔責任，因此需要團隊成員在安全意識和觀念上有了積極轉變?！?/p>

　　現任杭州孝道科技有限公司副總經理兼CTO，近20年安全行業從業經驗，浙江省網絡空間安全協會專家、云安全聯盟CSA（Cloud Security Alliance）專家組成員、全國信息安全標準化技術委員會（TC260） 相關工作組成員。主要研究領域包括軟件供應鏈安全、安全開發、SDL、DevSecOps,是數字應用安全領域的探索者，曾參與多項相關標準的研制工作。

　　01 目前，軟件供應鏈攻擊的主要特點是什么？企業應對軟件供應鏈攻擊的方法或框架主要有哪些？

　　徐鋒

　　目前在軟件供應鏈攻擊里面影響面最大、最容易被攻擊、最易得手的，多數是由開源軟件問題導致的。首先，目前軟件開發都在采用混源開發模式，其中大部分代碼都是開源的。開發者在引用開源軟件或開源組件時，準入控制的概念不強，前期對開源項目安全性、斷供等風險的評估基本為零；其次，從開源社區組織上來看，開源軟件管理相對比較松散，代碼提交門檻較低，并且很多社區項目對自身代碼安全性的關注度不足。這些因素都給軟件供應鏈安全埋下了嚴重的安全隱患。

　　面對軟件供應鏈攻擊，首先需要分析軟件的來源，不同來源的軟件攻擊防范方法差異非常大，目前可以粗略的把軟件來源分為：外部軟件和內部自研軟件。

　　對于從外部供應商采購的軟件，比如操作系統、辦公軟件、OA系統，或者委托他人開發的軟件，需要考察供應商的綜合實力、服務能力以及持續性，對交付物采用安全準入的檢查和控制措施。比如，對軟件進行成分分析，要求提交軟件物料清單（SBOM）清單，對于一些重要的系統軟件，除了基礎安全檢查之外，還需要進一步做安全測試。

　　外部軟件除了供應商采購獲得，還有很多來自開源軟件，開源軟件的引用同樣需要經過一系列的評估機制，對其安全性、健康度等各方面進行考察，以減少未來可能發生的供應鏈攻擊。

　　對內部的自研軟件有很多相應的安全開發模型和理念，比如軟件安全開發周期（SDL）、安全軟件開發框架（SSDF）、DevSecOps等，自研軟件的企業是相對而言比較好的軟件供應鏈安全參考模型。

　　此外，國家信息安全標準委員會在9月份正式發布了《信息安全技術 軟件供應鏈安全要求》征求意見稿，也給企業在軟件供應鏈安全方面的建設提供了一些方向性的指導，值得參考借鑒。

　　02 DevSecOps是一種理念、工具還是方法論？其核心價值或能力是什么？國內目前是否具備廣泛普及DevSecOps的基礎條件和市場環境？

　　徐鋒

　　DevSecOps是Gartner在2012年提出的一種理念，核心思想是盡可能地把安全無縫地、透明地集成到敏捷開發或者DevOps的開發過程中去。核心價值是在有限的成本投入以及保持業務開發敏捷性和速度的前提下，提升軟件的內生性安全。通過什么樣的方式、手段能達到這樣的目標，可以有哪些不同的做法，需要不同企業共同探索。

　　DevSecOps的市場應用依賴于敏捷開發或者DevOps的普及情況。研究數據顯示，我國目前90%的企業均不同程度地采用了敏捷開發模型或DevOps方法；還有60%的企業開始嘗試或者想要實現DevSecOps。從這些數據來看，國內DevSecOps的應用已經開始。頭部企業和規模較大的互聯網公司、金融企業已經在不斷的實踐、探索和優化了。從國內的普及率來看，DevSecOps正處于1到n快速推進的階段，將在近兩年快速增長。

　　03 構建DevSecOps軟件開發安全體系的核心技術和支撐技術分別是什么？

　　徐鋒

　　構建DevSecOps體系最核心的技術是安全工具鏈的建設，即軟件開發過程中需要的持續應用安全測試、賦能各種檢測類技術，包括很多應用安全測試工具，如代碼審計工具（SAST）、交互式應用安全檢測工具（IAST）、動態測試工具（DAST）以及模糊測試工具等。這類工具針對開發軟件代碼或者軟件制品進行自動化測試，發現軟件漏洞的核心技術。同時，用的較多的還有軟件成分分析工具（SCA），可以從開源組件安全、知識產權及開源許可的角度對軟件進行安全分析。

　　其次是運行時應用程序自我保護（RASP），安全編排（SOAR），響應自動化，也是DevOps轉向DevSecOps工具鏈建設中的重要支撐。

　　第三是與安全防護類產品如統一的單點登陸，防火墻，WAF等互聯互通的技術。由于DevSecOps在交付過程中，要保證交付速度，很多安全測試不夠充分，會遺留一些未發現的或低危的漏洞。因此，DevSecOps不能完全獨立，需要與傳統的應用防護類工具配合進行聯動防御。

　　此外，開發團隊在構建DevSecOps過程中也離不開DevOps開發基礎支撐類工具的熟練應用，具體包括代碼倉庫、制品倉庫、持續集成、持續部署、自動化測試、云原生等等。DevSecOps建設的時候，需要把上述的應用安全檢測工具、防護能力無縫透明的融入到DevOps的基礎開發環境中去，也是幫助整個團隊能更輕松落地DevSecOps的一個重要方面。

　　當然在構建DevSecOps的過程中，除了技術、工具以外，人、文化、流程這三大要素也是DevSecOps能力建設非常重要的核心力量。

　　04 與DevOps相比，DevSecOps流程上有哪些明顯區別？其中哪些環節對開發人員的挑戰會比較大？

　　徐鋒

　　傳統DevOps的參與者主要是開發和運維，安全只在即將上線時才會介入，并且安全責任只有安全團隊負責。但企業在轉向DevSecOps流程后，安全團隊需要融合進來，并且將安全開發的理念貫徹到開發的所有環節中去，比如需求階段會引入安全需求分析，設計階段會引入安全設計，編碼階段會引入安全編碼，測試階段也會引入安全驗證，最后還要經過安全發布和安全運營。所以從這個角度來說，DevSecOps并沒有完全摒棄傳統的安全開發模型，而是在做安全需求分析、安全設計、安全編碼、安全驗證、安全發布和安全運營的時候，更多利用工具的高效自動化。

　　從抑制供應鏈攻擊的角度來看，對于軟件自研的企業而言以下六個階段都是比較重要的，但從個人的角度來看，安全需求分析、安全設計、安全驗證這三個環節是對抑制供應鏈攻擊更為重要的環節。

　　從挑戰來看，開發人員原來更多關注的是功能的實現。而目前軟件設計階段需要融入安全設計，實現階段需要融入安全編碼，這都需要一定的安全知識儲備，去識別應用潛在的安全風險，并且設計出相應的消減安全威脅的方案，對開發人員是一個比較大的挑戰。針對開發人員的挑戰，在整個安全威脅識別的過程中，一般會引入威脅建模類工具，并且一般需要協調安全人員來共同承擔此階段工作。安全開發一體化平臺可以提供通用的安全設計模板及相應的知識庫，能為開發設計人員覆蓋60%以上的安全設計需求，降低開發人員安全設計難度；對于不能通用的部分需求可以采用威脅建模的方式進行定制化設計，定制化設計可以沉淀為模板使未來的安全設計更加方便；設計完成后要由專業的安全人員審核、把關這些安全設計，使安全設計應用更加科學完善。

　　安全編碼環節主要是消除不規范的代碼，難度相對安全設計低一些。通過開發人員安全編碼知識的培訓，以及安全工具對代碼檢查的反饋，就可以讓開發人員快速建立起安全編碼的能力。

　　從運維的角度來看，DevSecOps對交付速度要求非常高，在安全驗證階段，會更多依賴自動化工具，如果出現了安全漏洞，運維人員能夠快速的監測并進行響應處置。因此，DevSecOps在落地階段，對運維人員安全監測和相應處置能力會有更高的要求。此外，版本的發布和迭代又比較快，對運維人員適應快節奏的變化過程要求也特別高。

　　05 軟件開發有較強的繼承性和延續性，對于目前采用DevOps開發模式的企業，應該如何過渡到DevSecOps模式中？

　　徐鋒

　　首先，安全理念的轉變，也是我們過度到DevSecOps的重要前提。在DevOps模式下，安全責任都歸屬于安全團隊，開發和運維團隊不背安全的KPI。但DevSecOps模式下，人人要為安全承擔責任，要強調全員的安全責任和共擔文化，需要團隊成員在安全意識上做一些轉變。企業一般會從諸多產線中找一個項目或者一個團隊來做試點，在試點團隊里面去做磨合，去做適應，解決安全、開發、運維團隊之中存在安全責任割裂的問題。

　　其次，選擇合適的工具，從單一團隊開始，從關鍵節點介入，逐步推廣到單一團隊的全流程，然后再去復制到其他團隊。初期建設中工具的選擇非常的重要，可以先引用一些侵入性小，見效快的工具，如IAST、SCA等，進行部分流程的試點。當大家逐步適應部分流程的時候，再慢慢的擴展到安全需求、安全設計過程，然后貫穿到整個流程，最后再去復制到其他團隊。如果剛開始引入的工具太多，對現有的開發流程和開發人員的使用習慣侵入性比較大，就會出現集體反彈。

　　然后，從組織角度看，企業還需要配置相應的崗位為安全開發能力賦能。不同規模的企業在實踐DevSecOps的時候并不是一樣的。如果更加專業、更加細分的話，需要分成獨立的安全需求分析師、獨立的安全架構師、獨立的安全測試人員，甚至還有項目的安全顧問。這些人有些可能是通過兼職的方式，可能是專職的方式。但是這些職責也可以分散到不同團隊的不同人身上。因此，組織架構方面可以根據企業規模來調整。

　　最后，建立好安全開發的流程和制度，也是DevSecOps體系建立非常重要的一個方面。比如，如何根據項目級別不同，定義安全基線、評審流程、例外處理流程等方面的相關制度。

　　06 您認為目前階段DevSecOps應用的主要難點是什么？未來會呈現怎樣的發展趨勢？

　　徐鋒

　　目前，大部分應用軟件的開發都在使用敏捷的方法，DevSecOps在未來將會越來越普及。

　　但從技術方面來看，工具鏈建設的落地還有難度。各個廠商之間或者是各個工具之間還沒有完全打通，需要各個工具廠商按項目去對接，嚴重約束了DevSecOps的發展。比如說，不同安全工具測試出來的結果，目前只能做到相互歸類和優先級排序，用戶引入的工具越多，就需要投入越多時間去處理同一類漏洞，安全人員的工作量越來越大，效率越來越低。提升不同AST類工具組合應用時檢測的效能、效率，不同產品之間不光要結果互認，更重要的是相互補強、相互驗證、與平臺持續集成以及將AST類工具的檢測結果更好的輸送給各種防護類安全產品。不同工具之間相互協調、相互協作、相互補充以及自動化程度能力的提升是目前DevSecOps發展過程中需要去進一步解決的問題。

　　在政策方面，軟件供應鏈安全已經上升到了國家安全的高度。網絡安全和數據安全相關的法律規對軟件供應商、產品供應商提供的軟件安全合規性要求越來越高，對違規處罰的力度也越來越高。這也促進了安全開發、DevSecOps的理念更加快速的落地。

　　從理念發展來看，DevSecOps的落地仍需要不斷探索和深化，未來需要吸取更多其它安全開發模型和框架的思想進行完善。

　　牛評

　　敏捷開發作為數字經濟建設的重要組成部分，應用程序成份越來越復雜，代碼安全驗證不足等問題給應用程序安全留下了嚴重的缺口。同時，安全開發涉及了產業上下游，開發過程的多個環節，某一個點的安全能力的增強并不能有效閉環和緩解其所面臨的軟件供應鏈攻擊的影響。做好敏捷環境的開發安全需要人、文化、技術、流程多個方面的共同努力，但工具鏈、平臺化工具的使用體驗是改善人、文化和流程的重要約束條件，在整個供應鏈安全能力的建設中可以起到事半功倍的效果。

更多信息可以來這里獲取==>>電子技術應用-AET<<