你正在使用的開源專案原來有這麼多風險

你是否知道工程師隨便編寫的一個返回"Hello World"這麼簡單的微服務，後面居然依賴著上百個軟體包、5萬多行程式碼？你又是否知道這些軟體包在開源世界的來源、它們能帶來什麼樣的安全風暴？

現如今引用開源專案成為再習以為常的事，但你知道如果用的這個開原始碼包是一個遭駭客汙染過植入了後門的有毒元件，會有什麼影響嗎？今天想聊聊軟體供應鏈攻擊。

各行各業都有供應鏈，就像一家車廠，它生產整車，不可能從輪胎、車窗玻璃、車門把手做起。正如物理世界的任何產業都有自己的產業鏈、供應鏈一樣，在虛擬世界的軟體業也一樣，任何終極軟體產品，都用到很多的虛擬“零部件” - 以程式碼庫形態存在的元件、框架、工具，而且這些“零部件”本身也高度依賴其他“零部件”。

實際上， 隨便一個軟體，按絕對程式碼行數來算，一個不小心有一半是第三方的，例如在一些微服務裡，自己的程式碼只佔10%，也一點都不奇怪。

Hello，World 隱藏的秘密

每一個軟體工程師在學習一門新技術的時候，都會從最簡單的“Hello，World”程式開始。可是世界上確實沒有免費午餐 - 表面越簡單的東西背後的代價可能也越大。例如，你想用JavaScript+Node.js開發一個只能對網路請求返回“Hello，World”回覆的微服務，你決定採用一個最輕量簡約的微服務框架ExpressJS - 一動手的瞬間，你的開發工具npm就給你從上游拉取100+軟體包 - 54,000行程式碼拿去，不謝。如果你想再玩點高階功能，例如新增一個MVC框架（例如Locomotive），你的這個“微”服務實際程式碼量馬上升至220,000行 - 不好意思，起步價，哪怕你只寫一行程式碼。

每年各語言新增軟體包數量，其中npm生態2019年新增超過30萬個。上圖缺乏新興語言如Golang、Rust等的資料，但這些語言生態中的“零配件”數量的快速增長，對於開發工程師來說，都是可直接感知的。相比之下，Java、Ruby的元件生態增長率較低，但很大程度因為它們已經增長了近二十年，基數已經極其龐大。

軟體供應鏈遠比想象的無序凌亂

一套軟體的供應鏈，如果把它畫出來，很有可能是這樣的：

可以說， 今天的絕大部分開發者，根本搞不清楚自己的軟體供應鏈裡都有誰 ，因為他們所用到的很多技術元件都是他人提供的，這些“上游”元件本身又用了什麼其他元件、工具，開發者們往往不知道也不關注。可以說，我們在生產一個軟體產品的時候，很可能“非自願”的整合了大量“上游”、“上游的上游”、“上游的上游”的半成品。

對於企業來說，當前軟體供應鏈起碼面臨四類風險。

1、軟體質量風險

企業軟體表面上由IT或者外包商開發，可是實質上背後是成千上萬的第三方開原始碼，企業的QA工程質量管理方法和流程，對於第三方完全失控無效。

2、長期支援風險

企業軟體所間接依賴的一些第三方開源零部件，並沒有商業體在背後提供質量承諾和長期支援。開源專案因創始人退出或者社群活躍度低而不再維護、半途而廢的，不在小數。產生維護支援需求時，企業自己不得不安排人手去處理該部分程式碼，先不說有沒有這個意願，企業自己的IT工程師是否有這個能力也難說。

3、智慧財產權風險

開源軟體的智慧財產權機制，反映在著佐權（Copyleft）和許可證（Permissive）。後者約束了你的軟體的分發傳播需要滿足的條件，前者則往往更進一步要求你用開源元件開發的軟體本身的原始碼必須沿用同樣的開源條款，導致你的軟體智慧財產權不得不公開。國內軟體企業在使用開源、貢獻開源的過程中規則意識普遍薄弱，存在錯誤混用不相容的許可證，違反許可證規定二次釋出等問題，帶來更為複雜的智慧財產權問題和法律合規風險。

4、資訊保安風險

在開發人員寫第一行程式碼前，一個系統可能就註定繼承了一堆“ 安全債務” - 部分取決於這個系統的設計者、開發者選擇採用什麼第三方元件，部分取決於這些第三方元件的開發者又選擇依賴於什麼別的元件。反正安全風險是傳遞的，只要有一個零部件有安全漏洞、甚至是在漫長複雜的網際網路分發鏈路上被篡改過注入了惡意程式碼，你的系統就繼承了所有這些風險。

如何化解軟體供應鏈中的風險

虛擬世界的“惡意”程式碼，也只能用虛擬的“牢籠”去“關住”它。安全沙箱（Security Sandbox），就是這麼一種數字牢籠，它的形態和技術實現方式有很多種，本質上它是一種安全隔離機制，透過構建一個封閉的軟體環境，隔離了它所在的“宿主”的資源包括記憶體、檔案系統、網路等等的訪問許可權。執行在這個封閉環境中的程式，其程式碼不受信任，程式不能因為其自身的穩定性導致沙箱的崩潰從而影響宿主系統，程式也無法突破沙箱的安全管控以讀寫宿主系統的資源。

沙箱類技術以各種形態出現：在BSD等作業系統裡就提供直接叫做“Jail”的虛擬化隔離；在JVM裡為了支援Java Applet這裡網路載入的程式碼的執行，實現了sandbox機制；瀏覽器裡的HTML渲染引擎，一定程度上也可以視為一種在使用者態的基於安全能力模型（Capability-based）的沙箱技術。

FinClip是一種新型的輕應用技術，它有一個比較有趣的邏輯： 企業的軟體供應鏈在數字化時代可能是需要被重新定義的 - 有可能你的合作伙伴的程式碼執行在你這裡、也有可能你的程式碼借道合作伙伴的平臺去觸達對方的客戶。FinClip的核心是一個可嵌入任何iOS/Android App、Windows/MacOS/Linux Desktop Software、Android/Linux作業系統、IoT/車載系統的多終端安全執行沙箱。

FinClip安全沙箱中執行的輕應用，選擇了相容網際網路主流的小程式規範。這是一個非常明智的設計，FinClip的開發團隊沒有重新發明自己的技術規格，而是全力支援小程式這種形態的輕應用，一方面是因為小程式類技術的體驗和效果在網際網路上得到充分驗證、獲得巨大成功，另一方面是網上積累了豐富的技術生態、開發框架、以及更重要的 - 人才資源，從而讓企業IT幾乎是無縫掌握這個技術，能迅速投入應用。