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

[[412656]]

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

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

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

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

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

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

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

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

2.審查自動拉取請求和計劃任務(wù)

GitHub Actions等持續(xù)集成(CI)/持續(xù)交付(CD)自動化工具允許開發(fā)人員為其代碼存儲庫設(shè)置計劃任務(wù)，例如自動審查和處理傳入的拉取請求。但是，如果向開源項目提出拉取請求的人員具有惡意的話，會發(fā)生什么?

2021年4月，GitHub Actions被網(wǎng)絡(luò)攻擊者濫用，他們向數(shù)百個存儲庫發(fā)出自動拉取請求，其目的是使用GitHub的基礎(chǔ)設(shè)施挖掘加密貨幣。此次大規(guī)模網(wǎng)絡(luò)攻擊是在今年2月初報告GitHub Actions的“缺陷”之后發(fā)生的。

這些拉取請求可以濫用GitHub的服務(wù)器來挖掘加密貨幣或執(zhí)行網(wǎng)絡(luò)攻擊者的惡意代碼。如果項目所有者疏忽并合并這些拉取請求，他們現(xiàn)在已經(jīng)將惡意代碼引入到存儲庫和更廣泛的軟件供應(yīng)鏈中。今年5月，GitLab報告稱，網(wǎng)絡(luò)攻擊者濫用分配給新帳戶的“空閑時間”(配額)，在其平臺上實施了類似的加密貨幣挖礦攻擊。

因為像GitHub Actions和GitLab這樣的持續(xù)集成(CI)/持續(xù)交付(CD)自動化工具的本質(zhì)是提供自動化關(guān)鍵任務(wù)的便利，所以網(wǎng)關(guān)安全成為一個挑戰(zhàn)。在被威脅行為者濫用之后，原本可能是有意設(shè)計的功能很快就變成了安全漏洞。

GitHub公司最近發(fā)布了新功能，以防止加密攻擊者濫用其Actions平臺。GitHub公司產(chǎn)品經(jīng)理Chris Patterson在一篇博客文章中說，“在任何Actions工作流程運行之前，拉取請求將需要具有寫訪問權(quán)限的存儲庫合作者的人工批準(zhǔn)。當(dāng)申請者打開拉取請求時，他們會看到一條消息，表明維護人員必須在運行之前批準(zhǔn)他們的Actions工作流。”

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

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

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

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

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

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

4.集成深度代碼掃描，實現(xiàn)代碼質(zhì)量檢查的自動化

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

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

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

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

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

一旦發(fā)現(xiàn)這些嚴(yán)重漏洞，立即針對這些嚴(yán)重漏洞進行修補對于確保持續(xù)集成(CI)/持續(xù)交付(CD)基礎(chǔ)設(shè)施的安全性仍然至關(guān)重要。

6.在應(yīng)用更新之前驗證更新的完整性

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

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

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

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