CI/CD是應用程序開發周期的重要組成部分。然而，犯罪分子正在利用CI(持續集成)/CD(持續交付)管道中的漏洞，竊取敏感信息，挖掘加密貨幣，并交付惡意代碼。

最近的網絡攻擊利用了持續集成/持續交付(CI/CD)管道和開發人員工具中的漏洞，這說明了提高開發人員基礎設施的安全性迫在眉睫。最典型的案例則是Codecov供應鏈攻擊，這也提醒了用戶，無論環境多么安全都不要在CI/CD環境變量中存儲私密信息。

Codecov攻擊者入侵了數千名開發人員使用的Bash上傳器，成功地從客戶環境中竊取了憑證、密鑰和API令牌，且隱藏了兩個月，一直未被發現，據說還攻破了數百個受限的客戶網絡。同樣，對自動化工具(如Jenkins、GitHub Actions和云原生容器環境)的攻擊也進一步促使企業探索和部署對這些工具的有效防御措施。

以下是確保CI/CD管道安全的一些優秀實踐。

一、請不要在CI/CD環境中存儲敏感信息

Codecov供應鏈攻擊之所以能成功，背后的原因在于攻擊者滲出的環境變量包含硬編碼的敏感信息，包括密碼、令牌和鑰匙。由于其中一些憑證使攻擊者能夠訪問公司的私人GitHub存儲庫，因此可以從這些包含本應保密數據的私人存儲庫中進一步滲出數據。

盡管包括HashiCorp、Twilio、Rapid7和Monday.com在內的多個Codecov客戶披露了供應鏈攻擊帶來的影響，但迄今為止影響最為深遠的數據泄露還是在日本電商巨頭Mercari。在Codecov攻擊之后，與Mercari客戶的財務、商戶、商業伙伴、公司員工、承包商和各種實體有關的共27000多條記錄泄露給了未經授權的外部攻擊者。

盡管這些攻擊可能都是從Codecov漏洞開始的，但一些人也質疑了為什么客戶財務記錄等個人身份信息(PII)會被存儲在私人GitHub存儲庫中。

對于HashiCorp存儲在CI/CD環境中的GPG私鑰，人們也提出了類似的擔憂。這是由HashiCorp發布的用于簽署和驗證軟件版本的密鑰。在該密鑰被撤銷之前，攻擊者可以濫用該密鑰來偽造HashiCorp在惡意軟件發布上的簽名。一位開發者在推特上說："為什么沒有人談論Vault的制造商HashiCorp將他們的簽名密鑰存儲為ENV這一問題?"

企業需要重新思考哪些信息可以存儲在CI/CD工具、環境變量和私人GitHub存儲庫中。如果一個應用程序需要將憑證或令牌存儲在這些地方，最好是將憑證存儲在具有最低權限的賬戶或資源中，只是完成任務的必要條件，通常被稱為最小權限原則。這樣，即使私密信息在一次前所未有的攻擊中被暴露，也能夠控制損失。

二、審查自動拉取請求和計劃任務

像GitHub Actions這樣的CI/CD自動化工具允許開發者為他們的代碼庫設置計劃任務，比如自動審核和處理傳入的拉取請求。但是，如果向開源項目提出拉動請求的貢獻者不懷好意，會發生什么?

2021年4月，GitHub Actions被攻擊者濫用，他們向數百個倉庫提出自動拉取請求，目的是利用GitHub的基礎設施挖掘加密貨幣。這一大規模的攻擊發生在2月初GitHub Actions的漏洞曝光之后。

最低權限來說，這些拉取請求可以濫用GitHub的服務器來挖掘加密貨幣或執行攻擊者的惡意代碼。如果項目負責人疏忽大意，合并了這些拉取請求，那么他們便將把惡意代碼引入了他們的倉庫和更廣泛的軟件供應鏈。5月，GitLab報告說，其平臺上的攻擊者濫用分配給新賬戶的 "免費分鐘"(配額)，處理了類似的加密攻擊。

因為像GitHub Actions和GitLab這樣的CI/CD自動化工具的本質是為關鍵任務的自動化提供便利，所以把關成為一個挑戰。可能是有意為之的功能在被威脅者濫用后很快就變成了一個安全漏洞。

GitHub最近宣布了新的功能，打擊加密攻擊者對其Actions平臺的濫用。來自首次貢獻者的拉取請求將需要在任何行動工作流程運行前得到具有寫入權限的倉庫合作者的手動批準。GitHub產品經理Chris Patterson在一篇博文中說："當首次貢獻者打開拉取請求時，他們會看到一條信息，即維護者必須批準他們的行動工作流才能運行。

領先的CI/CD解決方案和DevOps平臺可以效仿GitHub的做法，增加一些安全檢查，以阻止惡意行為者大規模濫用其基礎設施。

三、加強并定期審計云原生容器

實踐出真知，標準的最佳實踐具有很大的參考意義。比如確保生產容器配置正確，并對常見的攻擊載體進行加固，包括保護管道配置。

然而，簡單的錯誤配置有時很難被發現。那么問題來了，基于Docker的環境是否有漏洞?所以，需要定期對容器進行安全審計，以發現弱點，掃描容器鏡像和清單文件，以發現常見的安全問題，這些措施仍然是很有幫助的。

投資于可靠的云原生容器安全解決方案也是明智之舉，它可以自動完成大部分工作。每年都報告了大量的安全漏洞，并且難以被人發現。

此外，隨著公司采用Kubernetes框架和Docker容器來部署他們的應用程序，具有內置Web應用防火墻的容器安全解決方案可以在早期檢測和阻止可疑的網絡流量。這可以防止較大的損害，即使攻擊者能夠穿透容器并獲得初始訪問。

四、集成深度代碼掃描以自動進行代碼質量檢查

在代碼正式提交之前，需要自動化工具來發現代碼質量問題、安全漏洞和內存泄漏或競賽條件等錯誤，這可以從一開始就確保CI/CD管道安全的有效策略。雖然重點主要放在防止網絡攻擊上，但微小的錯誤也同樣可能產生大規模的影響。比如，Fastly的全球故障使世界各地的主要網站都下線了。

像GitHub代碼掃描器或Sonatype的Lift這樣的解決方案可以無縫地集成到現有的編碼工作流程中，并為開發者提供基本的保障。歸根結底，一個組織的目標應該是支持其開發人員做好工作，同時盡可能地防止在應用程序中引入錯誤或安全漏洞。這需要開發和安全團隊之間的相互契合。在開發人員編碼時提醒他們可能出現的疏忽，實時通知可以節省每個人的時間，并從一開始就確保整個CI/CD工作流程。

五、盡早對最新的CI/CD工具漏洞打補丁

2021年3月，攻擊者利用一個名為z0Miner的加密挖礦僵尸網絡，在有漏洞的Jenkins和ElasticSearch服務器上開采Monero(XMR)加密貨幣。通過利用互聯網服務器中的遠程代碼執行(RCE)漏洞，攻擊者試圖感染和接管自動化基礎設施，以進行他們的犯罪活動。

無獨有偶，去年報告了攻擊者利用Jenkins服務器開展造成分布式拒絕服務(DDoS)攻擊。事件背后是因為一個UDP放大反射DoS攻擊漏洞，被追蹤為CVE-2020-2100，它影響到Jenkins v2.219以下的版本，以及Jenkins LTS 2.204.1以下的版本。

一旦發現這些嚴重的漏洞，立即對自動化工具和管道進行修補，這對于確保CI/CD基礎設施的安全至關重要。

六、在應用更新之前驗證其完整性

應用最新的更新和補丁聽起來是合理舉措，但更新是否又被篡改這似乎很難確定?幾十年來，"更新到最新版本 "的建議一直是安全專家的口頭禪，但在SolarWinds供應鏈攻擊事件后，這一建議受到了挑戰。

在SolarWinds事件中，對Orion IT產品的惡意更新使攻擊者能夠向下游的18000多名客戶分發惡意代碼。然而，Passwordstate密碼管理器的 "本地升級功能 "再次被入侵，向Passwordstate用戶分發惡意更新。因此，盲目地應用產品更新未必是一件好事。

在Codecov的案例中，一個簡單的完整性檢查發現了長達兩個月的漏洞。一位客戶注意到托管在服務器上的Bash Uploader的校驗和(哈希值)與Codecov的GitHub倉庫中列出的合法校驗和之間存在差異，立即與Codecov聯系，隨后他們修復了這一問題。

因此，深度防御的方法要求對任何更新、補丁和下載的完整性進行驗證，以便排除來自復雜的供應鏈攻擊的風險。

參考鏈接：Securing CI/CD pipelines: 6 best practices