最近，攻擊者在利用CI/CD以及開發工具當中的漏洞進行攻擊，導致對開發架構的安全性有了新的要求。Codecov供應鏈攻擊尤其對每一個在CI/CD環境中儲存機密信息的人發出了警告——無論這個環境看上去有多安全。

通過破解一個被幾千名開發者使用的Bash上傳組件，Codecov攻擊者能夠從客戶環境中竊取憑證、密鑰、以及API token，還能保持兩個月中不被發現。在此之上，還成功攻擊了數百個客戶的網絡。類似的情況還有針對像Jenkins、GitHub Action和云原生容器環境等自動化攻擊的攻擊，這些都進一步讓企業去針對這些工具探索并部署有效的防御手段。

六條保護CI/CD管道的建議

1. 不要在CI/CD環境中儲存機密信息

Codecov供應鏈攻擊獲得極大成功的原因，在于被攻擊者設法溢出的環境變量里存在硬編碼的機密信息，包括口令、通證和密鑰。攻擊者利用其中其中的一些憑證接入了企業的私有GitHub庫，進一步從庫中竊取的數據就包含了應該保密的數據。

盡管說包括HashCorp、Twilio、Rapid7和Monday.com等Codecov的多個客戶公開了供應鏈攻擊的影響，到現在為止受影響最大的公司是日本的電商巨頭Mercari。超過2.7萬條記錄被泄露，包括客戶的財務信息、商品信息、商業伙伴信息、公司員工信息、承包商信息等多個實體信息。

毫無疑問，這些攻擊都是由Codecov的泄露引起的，但也有些人質疑為何像客戶財務記錄這類的個人識別信息都會儲存在私有的GitHub庫里。

類似問題也發生在HashiCorp將GPG私鑰儲存在CI/CD環境當中。該密鑰用于簽署和驗證由HashiCorp發布的軟件。在密鑰被廢除以前，攻擊者可以濫用該密鑰來偽造一個帶有HashiCorp簽名的惡意軟件發布。一個開發人員甚至表示：“為什么沒有人提到Vault的供應商HashiCorp，竟然將他們的簽名密鑰作為ENV保存的事實?天啊，這讓我對自己的人生感到好多了。”

組織需要重新思考哪些秘密信息能夠儲存在CI/CD工具集、環境變量與私有GitHub庫中。如果一個應用需要將憑證或者通證儲存到這些位置，最好將憑證存到一個權限要求最小的賬戶或者資源中。那樣，即使相關秘密信息在不可預期的攻擊中被泄露了，損害也能被遏制。

2. 仔細檢查自動化pull請求與計劃任務

像GitHub Actions這類的CI/CD自動化工具能讓開發者為他們的代碼庫建立計劃任務，比如自動化否決和處理收到的pull請求。但是，如果一個貢獻者對一個有惡意意圖的開源項目發起pull請求，又會如何呢?

2021年四月，GitHub Actions遭到攻擊者濫用，對幾百個庫發起pull請求，試圖用GitHub的基礎設施進行挖礦。該大規模攻擊在2月份GitHub Actions的漏洞被報告后發生。

哪怕是最低限度的情況，這些pull請求會濫用GitHub的服務器進行挖礦，或者執行攻擊者的惡意代碼。如果項目所有者疏忽大意地合并了這些pull請求，就會將這些惡意代碼引入自己的庫以及更廣泛的供應鏈。五月，GitLab報告在他們的平臺發現了一個類似的挖礦攻擊，攻擊者濫用了新賬戶的免費時間。

由于像GitHub Actions和GitLab這種CI/CD自動化工具的本質是簡化關鍵任務的自動化能力，“守門”就成了一大挑戰。原本設計好的功能可能很快反而成為了一個安全隱患，被惡意人員所濫用。

GitHub最近宣布添加了新功能，以對抗濫用其Actions平臺進行挖礦的攻擊者：“從首次貢獻者發起的pull請求在任何Actions工作流能執行前，都需要庫合作者手動通過。當一個首次貢獻者打開一個pull請求，他們會看見一條信息告知在他們的工作流執行前，必須由一個維護者通過這個工作流。” GitHub的產品經理Chris Patterson在博客中提到。

CI/CD解決方案和DevOps平臺的領軍廠商可以追隨GitHub的方式，增加一些安全檢查，發現他們基礎設施中被惡意人員大規模濫用的行為。

3. 加強并周期性審計云原生容器

沒有什么比確保業務容器恰當配置并針對通常攻擊載體加固等標準最佳實踐更重要的了，這還包括了保證管道配置正確。

但是，一些細小的配置錯誤有時候很難被人發現。然后問題就來了，基于Docker的環境是否會不受漏洞威脅呢?這就是為什么需要經常對自己的容器做安全審計發現脆弱性的原因，掃描容器映象和清單文件以發現常見的安全問題依然很有幫助。

建議可以投資可以自動化處理這些事情的可靠云原生容器安全解決方案。每年公布的大量安全隱患幾乎不可能全部由人工進行追蹤。

另外，隨著企業啟用Kubernetes框架以及Docker容器來部署他們的應用，WAF內置的容器安全解決方案可以早期檢測并阻斷可疑的網絡流量。這就可以防止更大的失陷事件，即使攻擊者能夠滲透入容器并獲取最初的接入權限。

4. 集成深度代碼掃描以自動化檢查代碼質量

在代碼進入業務環境之前，就被自動化檢查代碼質量、安全隱患和內存漏出這類的漏洞，就可以有效地從頭開始保護CI/CD管道。盡管說關注點看上去主要針對網絡攻擊的防御，但是某些看上去無害的漏洞同樣產生大規模影響——比如最近的搞垮全球多個主要站點的Fastly事件。

GitHub代碼掃描或者Sonatype的Lift之類的解決方案能夠和現有的代碼工作流無縫集成，在對開發者沒有任何成本的情況下提供基礎的防護。組織最終的目的應該是支援開發者做出他們能做的最好的工作，同時盡量防止應用中漏洞或者安全隱患的出現。不過，這同時還要讓開發團隊和安全團隊之間的摩擦盡可能少。因此，實時在開發者寫代碼的時候對其告警，能夠省下所有人的時間，同時從一開始就確保CI/CD管道整體的工作流安全。

5. 盡早對最新的CI/CD工具漏洞進行補丁修復

2021年三月，攻擊者利用名為z0Miner的挖礦僵尸網絡在有漏洞的Jenkins和ElasticSearch服務器上進行門羅幣挖礦。通過對暴露在互聯網的服務器利用RCE漏洞，攻擊者得以感染并接管自動化基礎設施，實施他們的惡意行為。

同樣，在去年，Jenkins服務會被攻擊者利用，快速實現DDoS攻擊。這是基于一個能引起UDP反射放大攻擊的DoS漏洞，漏洞編號為CVE-2020-2100，分別會影響Jenkins v2.219和Jenkins LTS 2.204.1以下的版本。

盡快在高危漏洞被披露的時候給自動化工具和管道打上補丁，這依然是確保CI/CD基礎設施安全的關鍵。

6. 在進行更新前驗證其完整性

應用最新的更新和補丁是一個好主意，但是如何確保收到的更新并未被篡改?“升級到最新版本”這個被安全人員用了十幾年的銘言在SolarWinds供應鏈攻擊后開始遭到質疑。

在SolarWinds事件中，Orian的IT產品遭到惡意更新，使得攻擊者通過他們將惡意代碼下發到1.8萬個客戶中。同樣的，Passwordstate的口令管理功能失陷，將惡意更新傳播給了他們的用戶。因此，現在盲目地進行產品更新是一個糟糕的主意。

在Codecov的案例中，一個簡單的完整性檢查就能發現為期兩個月的泄露事件。一個客戶注意到了在服務器上Bash Uploader的哈希校檢和與Codecov在GitHub庫上的合法校檢和不符，從而通知了Codecov。Codecov隨后修復了該問題。

因此，一個深度的防御機制，要求對任何更新、補丁和下載都進行完整性驗證，從而將復雜的供應鏈攻擊可能排除。

點評

CI/CD管道安全不僅僅需要拓寬對攻擊面的防御范圍，還需要一系列的安全意識與規范的補充。而從技術層面，由于CI/CD本身帶有極強的自動化屬性，對于防護能力的自動化水平也有了新的要求——安全不能以過于犧牲業務為代價而存在。同時，開源軟件帶來的供應鏈攻擊也意味著代碼也需要賦予“零信任”，并非來自可靠來源的代碼都必然是安全的。