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

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

分布式開發增加了風險

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

隨著我們的代碼越來越多地成為團隊的一部分，我們可以期望看到更多類似這樣的攻擊。我們如何保護自己和應用程序?首先也是最重要的是，我們需要了解軟件供應鏈確實存在，我們不是孤立地構建代碼，而且我們已經很久沒有這樣做了，如果我們曾經這樣做過的話。開源和第三方庫是我們如何制作軟件的一個重要部分，它們只會變得更加重要。

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

確保軟件供應鏈的安全

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

當我們使用像Kubernetes這樣的技術時，事情會變得更加復雜，Kubernetes的設計是基于微服務架構和容器的混合匹配理念。雖然我們的代碼可以在獨立的容器中運行，但它在嵌套的抽象用戶區中運行，每個dockerfile收集一系列依賴項，其中許多依賴項沒有完整的文檔記錄。我們如何才能相信我們使用的容器中的物料清單?

推薦白皮書：

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

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

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

政策推動的批準

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

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

構建您的第一個策略

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

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

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

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

參考文章：

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

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