保護 CI/CD ：6 個最佳實踐

最近的網絡攻擊利用了持續集成/持續交付 (CI/CD)管道和開發人員工具中的弱點，因此需要提高開發人員基礎設施的安全性。值得注意的是，無論環境多么安全，Codecov 供應鏈攻擊都警告所有人不要在 CI/CD 環境變量中存儲機密。

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

以下是確保 CI/CD 管道保持安全的一些最佳實踐。

1. 停止在 CI/CD 環境中存儲機密

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

盡管包括 HashiCorp、Twilio、Rapid7 和Monday.com在內的多個 Codecov 客戶披露了供應鏈攻擊的影響，但迄今為止曝光的最嚴重的數據泄露事件發生在日本電子商務巨頭 Mercari。 在 Codecov 攻擊之后，超過 27,000 條與 Mercari 客戶的財務、商家、業務合作伙伴、公司員工、承包商和各種實體有關的記錄暴露給未經授權的外部參與者。

誠然，這些攻擊中的每一個都可能始于 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 平臺：“在任何 Actions 工作流程運行之前，來自首次貢獻者的拉取請求將需要具有寫訪問權限的存儲庫合作者的手動批準。當首次貢獻者打開拉取請求時，他們會看到一條消息，表明維護者必須在其 Actions 工作流運行之前批準其工作流程，”GitHub 產品經理 Chris Patterson 在一篇博客文章中說道。

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

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

沒有什么比遵循標準最佳實踐更好的了，例如確保正確配置生產容器并針對常見的攻擊媒介進行加固。這包括保護您的管道配置。

然而，簡單的錯誤配置錯誤有時很難被人類發現。那么問題來了，您的基于 Docker 的環境是否沒有漏洞？這就是為什么定期對容器的弱點執行安全審計，掃描容器鏡像和清單文件以發現常見的安全問題仍然很有幫助。

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

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

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

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

GitHub 代碼掃描器或 Sonatype 的Lift [完全披露：Sonatype 是我的雇主]等解決方案無縫集成到您現有的編碼工作流程中，并免費為開發人員提供基本的保護措施。最終，組織的目標應該是支持其開發人員盡其所能地工作，同時盡可能地防止在應用程序中引入錯誤或安全漏洞。這需要發生，同時盡量減少開發和安全團隊之間的摩擦。在這里，實時通知提醒開發人員在編寫代碼時可能出現疏忽，可以節省每個人的時間并從一開始就保護整個 CI/CD 工作流程。 

5. 盡早修補最新的 CI/CD 工具漏洞

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

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

一旦發現這些嚴重漏洞，立即針對這些嚴重漏洞修補自動化工具和管道對于確保 CI/CD 基礎架構的安全性仍然至關重要。 

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

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

在 SolarWinds 事件中，對 Orion IT 產品進行的惡意更新使攻擊者能夠向下游向18,000 多個客戶分發惡意代碼。再一次，Passwordstate 密碼管理器的“就地升級功能”已被破壞以向 Passwordstate 用戶分發惡意更新。因此，盲目應用產品更新是一個壞主意。

在 Codecov 的案例中，簡單的完整性檢查導致發現長達兩個月的違規行為。一位客戶注意到托管在服務器上的 Bash 上傳器的校驗和（哈希）與 Codecov 的 GitHub 存儲庫中列出的合法校驗和之間存在差異，立即聯系 Codecov 解決了問題。 

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