压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

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

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

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

1、不要在CI/CD環(huán)境中儲存機密信息

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

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

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

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

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

2、仔細檢查自動化pull請求與計劃任務(wù)

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

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

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

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

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

CI/CD解決方案和DevOps平臺的領(lǐng)軍廠商可以追隨GitHub的方式，增加一些安全檢查，發(fā)現(xiàn)他們基礎(chǔ)設(shè)施中被惡意人員大規(guī)模濫用的行為。

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

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

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

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

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

4、集成深度代碼掃描以自動化檢查代碼質(zhì)量

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

GitHub代碼掃描或者Sonatype的Lift之類的解決方案能夠和現(xiàn)有的代碼工作流無縫集成，在對開發(fā)者沒有任何成本的情況下提供基礎(chǔ)的防護。組織最終的目的應(yīng)該是支援開發(fā)者做出他們能做的最好的工作，同時盡量防止應(yīng)用中漏洞或者安全隱患的出現(xiàn)。不過，這同時還要讓開發(fā)團隊和安全團隊之間的摩擦盡可能少。因此，實時在開發(fā)者寫代碼的時候?qū)ζ涓婢軌蚴∠滤腥说臅r間，同時從一開始就確保CI/CD管道整體的工作流安全。

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

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

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

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

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

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

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

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

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

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

來源：數(shù)世咨詢