現(xiàn)代軟件開發(fā)實(shí)踐使得軟件供應(yīng)鏈的安全比以往任何時(shí)候都更加重要。我們的代碼依賴于開源庫，而開源庫依賴于其他庫(一系列我們沒有開發(fā)、沒有編譯、幾乎不知道或根本不知道它來自何處的代碼)。

其中一些代碼幾乎無處不在。在整個(gè)行業(yè)造成嚴(yán)重破壞的Log4Shell漏洞是由常見Java日志記錄組件log4j中的一個(gè)舊bug引起的。我們正在建設(shè)一個(gè)不是站在巨人的肩膀上的行業(yè)，而是站在少數(shù)應(yīng)用程序和組件維護(hù)者的肩膀上的行業(yè)，這些應(yīng)用程序和組件維護(hù)者讓我們的全球基礎(chǔ)設(shè)施在業(yè)余時(shí)間工作，并出于他們內(nèi)心的善良。

分布式開發(fā)增加了風(fēng)險(xiǎn)

這并不是為了減少維護(hù)人員所做的工作;它們是現(xiàn)代軟件供應(yīng)鏈的重要組成部分，提供從小型模塊到整個(gè)基于容器的平臺(tái)的一切。由于代碼的重要性，他們的價(jià)值被低估，薪酬也被低估?？杀氖?，有好幾次壞角色主動(dòng)提出接管代碼維護(hù)工作，卻加入了惡意軟件，希望代碼能夠自動(dòng)安裝，因?yàn)樗幸欢沃档眯刨嚨臍v史。

隨著我們的代碼越來越多地成為團(tuán)隊(duì)的一部分，我們可以期望看到更多類似這樣的攻擊。我們?nèi)绾伪Ｗo(hù)自己和應(yīng)用程序?首先也是最重要的是，我們需要了解軟件供應(yīng)鏈確實(shí)存在，我們不是孤立地構(gòu)建代碼，而且我們已經(jīng)很久沒有這樣做了，如果我們曾經(jīng)這樣做過的話。開源和第三方庫是我們?nèi)绾沃谱鬈浖囊粋€(gè)重要部分，它們只會(huì)變得更加重要。

我們可以采取哪些步驟來確保軟件供應(yīng)鏈的安全?在提供管理軟件材料清單的工具方面已經(jīng)做了大量的工作：掃描庫的代碼，使用靜態(tài)和動(dòng)態(tài)分析，向代碼中添加數(shù)字簽名和散列，并將其全部納入托管存儲(chǔ)庫。但有一個(gè)方面還不清楚：我們?nèi)绾悟?yàn)證這項(xiàng)工作以及我們正在使用的代碼?畢竟，古老的安全格言之一仍然是“信任但要驗(yàn)證”。

確保軟件供應(yīng)鏈的安全

我們需要信任我們使用的代碼，但我們也需要驗(yàn)證它是否可信。我們還需要在時(shí)間緊迫的情況下完成這項(xiàng)工作，隨著存儲(chǔ)庫中的代碼發(fā)生變化，云本機(jī)代碼將發(fā)布新的構(gòu)建。現(xiàn)代開發(fā)的自動(dòng)化本質(zhì)在這里是關(guān)鍵，像GitHub這樣的平臺(tái)是我們軟件生命周期的核心，提供持續(xù)集成和持續(xù)交付(CI/CD)。

當(dāng)我們使用像Kubernetes這樣的技術(shù)時(shí)，事情會(huì)變得更加復(fù)雜，Kubernetes的設(shè)計(jì)是基于微服務(wù)架構(gòu)和容器的混合匹配理念。雖然我們的代碼可以在獨(dú)立的容器中運(yùn)行，但它在嵌套的抽象用戶區(qū)中運(yùn)行，每個(gè)dockerfile收集一系列依賴項(xiàng)，其中許多依賴項(xiàng)沒有完整的文檔記錄。我們?nèi)绾尾拍芟嘈盼覀兪褂玫娜萜髦械奈锪锨鍐?

推薦白皮書：

介紹：一個(gè)工件驗(yàn)證工作流微軟的云本機(jī)開源團(tuán)隊(duì)一直在研究一個(gè)新的規(guī)范，該規(guī)范將有助于解決這一問題。Approval是一個(gè)驗(yàn)證框架，它支持Kubernetes應(yīng)用程序中的各種工件。它使用一組受信任的安全元數(shù)據(jù)和已簽名的物料清單來確保您部署的所有內(nèi)容都是您希望部署的內(nèi)容。

圖像和其他組件利用公證人V2簽名和驗(yàn)證工具以及ORAS(OCI注冊表作為存儲(chǔ))工件規(guī)范。ORAS是OpenContainerInitiative注冊表定義的一部分，它擴(kuò)展到存儲(chǔ)任何東西，而不僅僅是容器。它作為一種整理軟件材料清單的方式工作得很好。有趣的是，Bindle分布式應(yīng)用程序安裝程序定義和ORAS清單之間存在共性，這使得從SBOM到經(jīng)過驗(yàn)證的分布式應(yīng)用程序安裝程序變得簡單。兩者一起提供了一個(gè)供應(yīng)鏈圖，該圖可以被解析并用作Kubernetes集群內(nèi)驗(yàn)證方案的一部分。

將這些概念捆綁在一起，添加一個(gè)工作流引擎，將策略應(yīng)用于軟件物料清單，驗(yàn)證代碼及其依賴關(guān)系中的許多不同供應(yīng)鏈。它的核心是一個(gè)協(xié)調(diào)器，負(fù)責(zé)跨容器映像管理策略工作流。它是可擴(kuò)展的，因此它可以跨公共和私有注冊中心工作，使用與Kubernetes中使用的插件模型類似的熟悉插件模型。

政策推動(dòng)的批準(zhǔn)

Proparly使用的策略模型基于熟悉的工具，提供了一種使用您自己的配置以及使用Open policy Agent構(gòu)建的更復(fù)雜的策略快速推出基本策略的方法。它還將在應(yīng)用程序開發(fā)生命周期的不同階段工作，插入CI/CD系統(tǒng)以在構(gòu)建時(shí)驗(yàn)證工件，并插入Kubernetes以確保代碼在構(gòu)建和運(yùn)行之間不會(huì)發(fā)生更改。重要的是要有一個(gè)在堆棧中工作的驗(yàn)證模式，確保避免在構(gòu)建、存儲(chǔ)庫和注冊中心以及運(yùn)行時(shí)發(fā)生在代碼上的供應(yīng)鏈攻擊。

讓一個(gè)工具在整個(gè)軟件生命周期中處理驗(yàn)證非常重要，因?yàn)樗_保您只需要編寫一次策略。針對不同場景的不同工具增加了策略中轉(zhuǎn)錄和翻譯錯(cuò)誤的風(fēng)險(xiǎn);使用單一工具和單一策略格式有助于避免這種風(fēng)險(xiǎn)。您還可以擁有一個(gè)外部策略測試工具，該工具可以幫助您在交付代碼之前調(diào)查“假設(shè)是什么”。

構(gòu)建您的第一個(gè)策略

Approval團(tuán)隊(duì)在他們的GitHub存儲(chǔ)庫中有一些演示代碼，展示了如何在Kubernetes中將Approval與Gatekeeper一起使用。使用Helm圖表進(jìn)行安裝，并附帶一些示例配置模板。您可以使用這些來測試這些操作，例如，阻止所有沒有簽名的圖像。Gatekeeper將拒絕任何未簽名的容器映像，阻止它們運(yùn)行。

策略文件是用YAML編寫的，因此您可以在Visual Studio代碼或其他工具中編輯它們，并利用代碼格式化工具。它們構(gòu)建成一個(gè)簡單的規(guī)則引擎，通過驗(yàn)證逐步生成工件。它們是否來自核準(zhǔn)登記處?您是否多次檢查一個(gè)工件以獲得不同的簽名?您自己的私有注冊表中的工件是否比公共注冊表中的工件更可信?當(dāng)您運(yùn)行多個(gè)檢查時(shí)，您的所有驗(yàn)證引擎都同意嗎?事實(shí)證明，運(yùn)行時(shí)驗(yàn)證的規(guī)則很容易定義，但對于運(yùn)行在CI/CD系統(tǒng)中的運(yùn)行時(shí)驗(yàn)證來說，這種情況不太可能發(fā)生，因?yàn)樵贑I/CD系統(tǒng)中，您需要確定許多不同工件的狀態(tài)以及來自許多不同信任根的簽名。

Approval目前是一個(gè)有趣的初始建議，它提供了一套工具，可以管理軟件BOM表中的所有元素。雖然它不能防止零天影響長時(shí)間隱藏的bug，但它可以快速確定哪些代碼受到影響，創(chuàng)建規(guī)則以防止其被使用和運(yùn)行。

隨著供應(yīng)鏈風(fēng)險(xiǎn)成為人們關(guān)注的焦點(diǎn)，行業(yè)必須仔細(xì)研究這樣的提案，并在公共場所開展工作。很高興看到微軟已經(jīng)承諾與云計(jì)算計(jì)算基金會(huì)共享批準(zhǔn)，在那里它應(yīng)該得到它需要的更廣泛的Kubernetes開發(fā)社區(qū)的審查。

參考文章：

https://docs.ceph.com/en/latest/dev/cephfs-snapshots

https://knowledgebase.45drives.com/kb/kb450160-cephfs-snapshots/