網絡攻擊者利用了持續集成(CI)/持續交付(CD))管道和開發工具中的弱點，因此需要提高開發基礎設施的安全性。值得關注的是，無論環境多么安全，針對軟件審計商Codecov公司供應鏈的網絡攻擊事件都在警告人們不要在持續集成(CI)/持續交付(CD)環境變量中存儲機密數據。

[[412656]]

通過破壞數千名開發人員使用的Bash上傳程序，針對Codecov公司的網絡攻擊者設法從客戶環境中竊取憑據、密鑰和API令牌，而在入侵兩個月之后沒有被發現，據報道，此次攻擊還破壞了數百個受限制的客戶網絡。同樣，對Jenkins、GitHub Actions和云原生容器化環境等自動化工具的攻擊進一步促使企業探索和部署這些工具的有效防御措施。

以下是確保持續集成(CI)/持續交付(CD))管道保持安全的一些最佳實踐。

1.停止在持續集成(CI)/持續交付(CD)環境中存儲機密

對Codecov公司的供應鏈進行網絡攻擊取得成功背后的原因仍然是網絡攻擊者泄露的環境變量包含硬編碼的秘密，其中包括密碼、令牌和密鑰。由于其中一些憑證讓網絡攻擊者可以訪問企業的私有GitHub存儲庫，因此這些私有存儲庫可能會發生進一步的數據泄露，其中包含機密數據。

盡管包括HashiCorp、Twilio、Rapid7和Monday.com在內的Codecov公司多個客戶披露了供應鏈攻擊的影響，但迄今為止曝光的最嚴重的數據泄露事件發生在日本電子商務巨頭Mercari公司。在Codecov公司遭遇網絡攻擊之后，Mercari公司的客戶、商戶、業務伙伴、公司員工、承包商等組織泄露的總記錄超過27000條。

誠然，這些網絡攻擊中的每一個都可能始于Codecov漏洞，而有些人質疑為什么將客戶財務記錄等個人身份信息(PII)存儲在私有GitHub存儲庫中。

存儲在持續集成(CI)/持續交付(CD)環境中的HashiCorp的GPG私鑰也引起了類似的擔憂。這是用于簽署和驗證HashiCorp發布的軟件版本的密鑰。在密鑰被撤銷之前，網絡攻擊者可能已經濫用密鑰在惡意軟件版本上偽造HashiCorp的簽名。一位開發者在推特上寫道，“為什么沒有人談論Vault的制造商HashiCorp將他們的簽名密鑰存儲為ENV的事實?”

企業需要重新考慮哪些機密數據可以存儲在持續集成(CI)/持續交付(CD)工具、環境變量和私有GitHub存儲庫中。如果應用程序需要將憑證或令牌存儲在這些地方，最好將憑證存儲到具有最低權限的帳戶或資源中，這正是完成任務所必需的——通常稱為最小權限原則。這樣，即使機密數據確實在前所未有的網絡攻擊對外泄露，造成的損害也會得到控制。

2.審查自動拉取請求和計劃任務

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在一篇博客文章中說，“在任何Actions工作流程運行之前，拉取請求將需要具有寫訪問權限的存儲庫合作者的人工批準。當申請者打開拉取請求時，他們會看到一條消息，表明維護人員必須在運行之前批準他們的Actions工作流。”

行業領先的持續集成(CI)/持續交付(CD決方案和DevOps平臺可以效仿GitHub，添加一些安全檢查，以阻止惡意行為者大規模濫用其基礎設施。

3.強化并定期審核云原生容器

沒有什么比遵循標準最佳實踐更為出色，例如確保容器被正確配置并針對常見攻擊向量加強防范。這包括保護管道配置。

然而，簡單的配置錯誤有時很難被工作人員發現。那么就會出現一個問題，企業的基于Docker的環境是否沒有漏洞?這就是為什么定期對容器的弱點執行安全審計、掃描容器鏡像和清單文件以發現常見的安全問題仍然很有幫助的原因。

建議采用可靠的云原生容器安全解決方案，將其大部分實現自動化。每年報告的大量安全漏洞使得人類幾乎不可能跟蹤它們。

此外，隨著越來越多的企業采用Kubernetes框架和Docker容器來部署其應用程序，具有內置Web應用程序防火墻的容器安全解決方案可以及早檢測和阻止可疑的網絡流量。這有助于防止更大的危害，即使網絡攻擊者能夠入侵容器并獲得初始訪問權限也可以阻止。

4.集成深度代碼掃描，實現代碼質量檢查的自動化

在代碼提交進入生產環境之前，采用工具來自動發現代碼質量問題、安全漏洞以及諸如內存泄漏或競爭條件之類的錯誤，需要從一開始就保護持續集成(CI)/持續交付(CD)管道的有效策略。盡管其重點似乎主要是防止網絡攻擊，但無害的錯誤也可能產生大規模的影響。人們最近從Fastly 公司CDN在全球范圍內的中斷中看到了這一點，該中斷使該公司在世界各地的主要站點脫機。

GitHub代碼掃描器或Sonatype的Lift等解決方案無縫集成到企業現有的編碼工作流程中，并免費為開發人員提供基本的保護措施。最終，企業的目標應該是支持其開發人員的工作，同時盡可能地防止在應用程序中引入錯誤或安全漏洞。這需要在開發團隊和安全團隊之間的配合。在這里，實時通知提醒開發人員在編寫代碼時可能出現的疏忽，可以節省開發人員的時間，并從一開始就保護持續集成(CI)/持續交付(CD)工作流程。

5.盡早修補最新的持續集成(CI)/持續交付(CD)工具漏洞

2021年3月，網絡攻擊者利用名為z0Miner的加密挖掘僵尸網絡在易受攻擊的Jenkins和ElasticSearch服務器上挖掘加密貨幣門羅幣(XMR)。通過利用面向互聯網的服務器中的遠程代碼執行(RCE)漏洞，網絡攻擊者試圖攻擊并接管自動化基礎設施以進行他們的惡意活動。

正如去年媒體報道的那樣，網絡攻擊者可以利用Jenkins服務器來迅速造成分布式拒絕服務(DDoS)。這是由UDP放大反射DoS漏洞引起的，這個漏洞名為CVE-2020-2100，它影響低于Jenkins v2.219的版本以及低于Jenkins LTS的2.204.1的版本。

一旦發現這些嚴重漏洞，立即針對這些嚴重漏洞進行修補對于確保持續集成(CI)/持續交付(CD)基礎設施的安全性仍然至關重要。

6.在應用更新之前驗證更新的完整性

采用最新的更新和補丁是合理的建議，但能確定收到的更新沒有被篡改嗎?在SolarWinds供應鏈遭到網絡攻擊之后，幾十年來一直是安全專業人士的口頭禪的“更新最新版本”的建議受到了挑戰。

在SolarWinds的數據泄露事件中，對Orion IT產品進行的惡意更新使網絡攻擊者能夠向下游的18000多個客戶分發惡意代碼。Passwordstate密碼管理器的“就地升級功能”遭到破壞，以向Passwordstate用戶分發惡意更新。因此，盲目采用更新補丁并不是一個好主意。

在Codecov公司的案例中，簡單的完整性檢查發現了長達兩個月的數據泄露行為。一位客戶注意到托管在服務器上的Bash上傳器的校驗和哈希值與Codecov的GitHub存儲庫中列出的合法校驗之間存在差異，因此立即聯系Codecov公司，該公司于是致力解決數據泄露的問題。

縱深防御方法可以保證任何更新、補丁和下載的完整性都得到驗證，從而排除來自復雜供應鏈攻擊的風險。