RSAC解讀：如何安全地使用CI_CD工具

一、概述

2022年的RSA會議上，來自Coalfire的副總裁和首席戰略官Dan Cornelld的議題《What Executives Need to Know about CI/CD Pipelines and Supply Chain Security》從使用CI/CD管道的安全性出發，首先向各位觀眾講述了什么是CI/CD管道，并提出我們為何需要關注CI/CD使用過程中的安全風險，之后Dan Cornell面向安全從業人員以及DevSecOps實施人員講述了使用CI/CD需要注意的安全風險，包括源代碼倉庫安全接入CI/CD管道可能引發的風險，引入第三方開源依賴庫的風險，項目代碼在構建測試、部署、打包、分發過程中面臨的安全風險。最后，Dan Cornell提出了相應的安全建議并給出了未來6個月的具體DecSecOps實施計劃。

二、背景

DevOps 全稱為 Development & Operations，在 2009 年被提出，其代表的并非一種具體實現技術，而是一種方法論。DevOps 的出現最終目是為了打破開發人員與運維人員之間的壁壘和鴻溝，高效的組織團隊通過自動化工具相互協作以完成軟件生命周期管理，從而更快且頻繁地交付高質量穩定的軟件。如果說DevOps理念實現了軟件的快速交付、那么CI/CD(Continuous integration & Continuous Delivery & Continuous Deployment)便是實現這一理念的主要方法，CI/CD 的核心概念是持續集成，持續交付，持續部署。依托 CI/CD，應用的整個生命周期（從集成和測試階段，到交付和部署階段）可達到持續自動化和持續監控的效果。

如我們所知，DevOps影響的不僅包含開發團隊（Dev）和運維團隊(Ops)，還應包含安全團隊（Sec），在系統生命周期（SDLC Systems Development Life Cycle）中，安全團隊常聚焦于運營階段，因而往往忽視了開發階段的安全，所以“安全左移”的理念在近些年非常的火，其強調安全因素應納入應用開發的早期階段，常見的，我們在開發（Dev）與運維（Ops）之間加入安全（Sec），也就是DevSecOps理念，其側重點是將安全工具自身整合至CI/CD工作流中，且安全工具主要納入應用的測試、發布和運維階段。

隨著技術的不斷發展，用戶可采用的CI/CD工具逐漸增多，除了關注工具自身的安全問題之外，如何正確的使用CI/CD管道，關注并及時發現各個階段存在的安全風險也尤為重要。

三、供應鏈攻擊事件

供應鏈攻擊是一種網絡攻擊，攻擊者可利用軟件或硬件來篡改服務程序，針對組織供應鏈中的薄弱環節實施攻擊，從而導致服務程序被破壞。鑒于供應鏈自身的特性，惡意軟件可以安裝在供應鏈的任何階段，且供應鏈攻擊允許指定目標，若被攻擊的供應商有很多客戶，則受影響的數量會迅速增加。此外，由于供應鏈依賴于已被信任并且可以廣泛分發的軟件，因而供應鏈攻擊很難被檢測。

3.1 Solar Winds供應鏈攻擊事件

2020年12月，美國安全公司FireEye爆出有攻擊者通過在SolarWinds軟件中植入木馬程序入侵了公司網絡。該木馬程序具有合法的數字簽名并且伴隨著軟件的更新下發，借助軟件供應鏈的特性，APT攻擊者組織可對目標機構發起未授權訪問，達到長期對目標機構的控制，并不斷竊取核心數據。事件經歷短短一周內就有超過200家重要機構受到影響，其中不乏一些全球科技發達地區的敏感機構，其中美國占比超過60%，包括美國國務院、國土安全部、國防部、財政部在內的多家政府機構均受到此事件的影響，事件影響力可謂巨大.

3.2 Codecov供應鏈攻擊事件

2021年，國外軟件審計平臺Codecov（該軟件常被用于集成至CI/CD工作流中）遭受攻擊者攻擊，該事件直接導致近3萬用戶的隱私數據泄漏，究其原因，攻擊者主要利用Codecov鏡像Dockerfile中的錯誤配置提取Bash Uploader腳本（用戶可通過該腳本上傳測試數據）中的訪問憑證，進而通過該憑證修改用戶的Bash Uploader腳本[2]，在長達1000多行的Bash Uploader腳本中添加如下兩行代碼[1]：

圖1 Bash Uploader腳本中注入的惡意代碼

可以看出，以上代碼會將CI中所有的環境變量發送至第三方服務器，這些環境變量中可能包含Git訪問憑證、API Key等敏感信息和密鑰，攻擊者進一步可以訪問通過這些憑證訪問的任何服務、數據和應用程序代碼，危害巨大。

近兩年供應鏈攻擊事件層出不窮，分析并總結背后原因不難看出建立可信的軟件開發環境、定期進行安全檢查、關注依賴組件的已知漏洞、落實DevSecOps理念的重要性。

四、CI/CD應用過程中需要考慮的安全問題

Dan Cornell舉例從數據流的角度看CI/CD管道安全，如下圖所示：

圖2 CI/CD管道示例圖

可以看出示例中的CI/CD管道流程分為以下幾個階段：

1.   開發者提交代碼至源碼倉庫；

2.   CI/CD管道流程的構建階段從源碼倉庫及開源倉庫獲取最新提交的代碼以及相應依賴的開源組件代碼；

3.   構建結束后生成二進制文件，進入測試階段；

4.   測試階段包括安全測試、集成測試、單元測試三個部分；

5.    測試完成后進入評估階段，若測試通過進入后續的打包和分發階段

上述流程結合一定的安全知識背景，我們可以看出安全風險可能存在于各個階段，Dan Cornell從信息安全三要素機密性、完整性、可用性的角度闡述了這些風險，如從機密性上來看，主要涉及敏感數據泄露，如IP泄露、密鑰泄露、漏洞披露為造成風險的主要因素；從完整性上來看，源代碼植入后門、惡意挖礦或是其他惡意行為成為供應鏈攻擊的主要一環；從可用性上來看，功能受到影響導致延遲發布與漏洞修復無法及時推送到生產環境[1] ，最終都會對軟件交付產生不同程度的影響。

值得注意的是，隨著業務越發復雜，系統架構從單體走向微服務化，CI/CD管道的復雜性也會相應增多，每個階段都可能會產生大量的敏感數據，這些敏感數據往往會成為巨大的攻擊杠桿。試想一旦攻擊者拿到了源碼倉庫的訪問憑證，那么整個CI/CD環境都可能遭到淪陷。因此，DevSecOps實施人員需要對數據的最終輸出負責，評估軟件CI/CD的運行環境，在CI/CD管道的每個階段評估安全風險，如每一階段涉及的服務種類、敏感數據、敏感數據存儲、敏感數據分級、敏感數據傳輸加密等。

Dan Cornell從CI/CD使用的角度出發，闡述了各個階段產生的風險，筆者將其進行了匯總，主要分為以下五部分。

4.1 CI/CD管道接入源碼倉庫的風險

通常情況下，CI/CD工具根據用戶自定義的管道流程，在開發者進行git push或git pull等操作時觸發接入源碼倉庫，在接入過程中由于源碼倉庫自身提供多種接入方式，進而擴大了風險面，下圖展示了Gitlab提供的幾種訪問途徑：

圖3 源碼倉庫訪問途徑

可以看出除了常規的源碼訪問（push/pull/merge request等）、Web訪問以及API訪問，Gitlab還提供Webhook訪問。在第三方開發團隊對源碼倉庫進行push/pull操作時，若未對源碼倉庫接入進行有效認證，則可能會導致本地代碼在CI/CD以外的環境中運行，進而造成源碼不可控的風險。

4.2 引入第三方開源組件的風險

關于引入第三方開源組件的風險，通常包含以下四部分內容。

4.2.1 開源組件自身漏洞導致的風險

許多開源組件自身存在漏洞，不同風險級別的漏洞會導致CI/CD環境面臨不同程度風險，例如若開源組件存在RCE漏洞，攻擊者則可能利用該漏洞獲取CI/CD管道中的環境變量，進而獲取Gitlab或Github的有效訪問憑證，最終接管整個源碼倉庫，引起巨大風險。

4.2.2 不安全的開源組件管理導致的風險

在CI/CD管道中，我們通常會引入第三方開源組件對項目依賴項進行構建管理。例如Java項目中，通常會引入Maven倉庫，若我們的項目直接從Maven中央倉庫進行拉取，我們就無法確定是否引入了含有漏洞的組件，進而可能導致組件漏洞被攻擊者利用的風險。

4.2.3 攻擊者為開源組件添加后門程序導致的風險

若攻擊者擁有訪問開源組件倉庫的權限，進而可以通過為開源組件添加惡意后門程序，之后重新對外發布的形式，引發大規模供應鏈攻擊的風險。若用戶的項目源碼中引入了含有后門的開源組件，攻擊者則有可能利用該漏洞對CI/CD環境進行探測，進而導致整個環境淪陷的風險。

4.2.4 開源軟件許可證導致的風險

開源組件的許可證類別較多，如常見的Apache License、MIT是相對寬容的許可證，這些許可證通常沒有真正的限制條件，若將相應的開源組件引入自己開發的項目，并對外發布，僅需保留版權聲明即可，不會面臨使用上的法律風險。除此之外，還有一些頂級的開源許可證，例如GPL 3.0 和AGPL，其為限制性的許可證，若引入了相應開源組件并進行商用，則會面臨法律風險。

4.3 構建階段的風險

構建階段，CI/CD管道通常會引入插件對源碼以及第三方開源組件代碼進行構建，該插件實際上也運行在CI/CD環境中，對于開發者而言，插件是不受信任的，含有漏洞的插件可能被攻擊者利用進而訪問到CI/CD管道中產生的數據，并將數據傳送至第三方服務器，如3.2中提出的Codecov供應鏈事件影響，受害者下載了攻擊者精心注入惡意代碼的文件，導致CI/CD中的環境變量泄露，攻擊者可以利用這些環境變量竊取受害者隱私數據，造成巨大影響。

4.4 測試階段的風險

自動化測試是CI/CD管道中必經的一環，自動化測試常包含集成測試、單元測試、安全測試這幾類流程，CI/CD工具會調用測試插件（可能來自CI/CD環境外部或內部）進行測試，例如Gitlab的CI/CD管道默認支持引入開源代碼審計工具bundler-audit、gemnasium等，這些開源工具是否可信是我們需要關注的重點，如測試階段產生的流量是在CI/CD環境內部還是外部，若是外部將不受DevSecOps實施者的控制，可能進而會導致測試流量被代理到第三方服務器的風險，再如當測試階段完成后，測試結果最終存儲在哪里，若存儲在外部，也會導致數據泄露的風險。

此外，風險漏洞管理也十分關鍵，如當Gitlab進行鏡像掃描后產生了一系列待修復的漏洞，誰擁有什么權限訪問這些漏洞很重要，若管理員分配了錯誤的權限，則可能導致未授權訪問的風險，這里的未授權訪問主要針對的是第三方團隊的開發人員。

4.5 打包和分發階段的風險

經歷測試階段后，CI/CD管道會評估最新的測試結果，一旦測試通過會將軟件進行打包以及后續的分發，此處以微服務架構的項目舉例，打包階段時，各個微服務通過Dockerfile文件進行鏡像構建，并進行簽名后將鏡像上傳至倉庫。分發部署階段時，Kubernetes會從鏡像倉庫中拉取最新版本的鏡像以完成后續部署。以上過程中可能會產生一定的風險，主要包括以下兩方面：

鏡像自身內容引發的風險

若業務鏡像依賴的基礎鏡像含有漏洞，可能導致攻擊者利用已知漏洞對服務自身或其他微服務發起攻擊，若鏡像中的應用代碼含有漏洞，也將會導致被攻擊者利用的可能。

鏡像分發過程引發的風險

由于CI/CD與Kubernetes可能不在同一環境，因而可能導致攻擊者在分發過程中趁虛而入，利用鏡像來源的不確定性（惡意鏡像簽名）對鏡像的傳輸過程進行劫持，并替換成惡意鏡像，亦或是對鏡像倉庫直接發起攻擊，造成巨大影響。

五、面向CI/CD使用者的安全建議

在本次RSA演講中，Dan Cornell面向CI/CD使用者提出了一些安全建議，

筆者將其進行了匯總，主要包含以下幾部分：

針對4.1提出的風險，建議DevSecOps實施人員在CI/CD管道與源碼倉庫的接入上做好認證管理，并能夠清晰的了解到項目源碼的所處地，做好源碼安全管控。

針對4.2提出的風險，建議首先梳理項目中所有依賴的開源組件，可通過SBOM（Software Bill of Materials）進行梳理，并采用SCA（Software Components Analysis）工具對開源組件進行漏洞掃描。其次，當項目中引入了新的開源組件，能夠具備針對性的安全管控措施。最后，引入掃描組件的自身風險范圍也應達到可控。

針對4.3提出的風險，建議對構建過程中的插件來源、插件需要訪問的數據、數據最終的傳送地進行確認，同時注意構建的頻率是否異常。

針對4.4提出的風險，建議首先確認測試階段是否包含第三方團隊，若包含則需要確定測試產生的流量以及測試結果的最終去處。其次，需要確認掃描工具自身的安全性，做好實時修復漏洞的準備。最后，風險漏洞管理需要給予用戶適當訪問權限，遵循最小權限原則。

針對4.5提出的風險，建議首先從可靠源下載容器鏡像，并定時對鏡像進行漏洞掃描、漏洞修復以及后續的漏洞管理。其次，針對鏡像構建過程進行簽名，鏡像拉取過程進行簽名校驗。最后，做好鏡像倉庫的安全管理，為鏡像倉庫用戶分配合理訪問項目的權限。

六、總結

從近年RSA議題及創新沙盒入圍的安全初創公司來看，DevSecOps已成為一項必不可少的話題，從最初的DevOps到安全左移的DevSecOps理念，這一過程必然會引起相應技術以及用戶使用行為上的變革，將安全部分納入DevOps并不難，難的是如何充分的踐行DevSecOps理念，如我們所知，開發人員和運維人員通常沒有安全背景，如何讓其安全地使用CI/CD工具是一大問題，Dan Cornell的議題分享較為全面的闡述了使用CI/CD工具過程中需要注意的安全風險，并針對這些風險提出了相應的安全建議，可為各企業在DevSecOps的實際落地過程中提供一定參考。