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

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

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

這并不是為了減少維護人員所做的工作;它們是現(xiàn)代軟件供應(yīng)鏈的重要組成部分，提供從小型模塊到整個基于容器的平臺的一切。由于代碼的重要性，他們的價值被低估，薪酬也被低估?？杀氖?，有好幾次壞角色主動提出接管代碼維護工作，卻加入了惡意軟件，希望代碼能夠自動安裝，因為它有一段值得信賴的歷史。

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

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

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

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

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

推薦白皮書：

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

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

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

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

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

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

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

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

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

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

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

參考文章：

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

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