讓企業數字化砸鍋和IT主管背鍋的軟體供應鏈安全風險

某天，某銀行被盜取大量資料、遭受巨大經濟損失，並遭到消費者集體訴訟和監管天量罰單。原因是技術系統用了某個開原始碼包，該開原始碼包原來是一個遭黑客汙染過植入了後門的有毒元件。不小心誤用這個程式碼包的，是IT部門某基層小弟所為。新聞爆出，CIO一臉蒙圈，卒。

上述情形目前...暫時是，虛構的。會不會發生呢？概率不小。罪魁禍首，叫軟體供應鏈攻擊。這個問題的潛在風險，大到什麼程度呢？根據Gartner，至2025年全球有接近一半的企業會會遭遇到。後果？對於企業數字化是巨大的爆雷，對於企業的技術高管，參照上述“CIO”。

今年初白宮都不得不召集中議討論Log4J，拜登都得知道Java，是不是莫名魔幻？但對於碼農來說是不是略感自豪 - 相當於所在銀行行長、公司CEO深入IT基層，親自了解一個用Java寫的、通常埋在十八層程式碼之下的日誌工具，“並作出重要指示”的既視感...

接下來，本文嘗試“貼心”的替百忙中未必有空學習瞭解“軟體供應鏈”的領導們作一點點學習，總結一些科普性內容，描述一下問題、歸納一下挑戰、整理一些概念、總結一些策略，但是難以高度濃縮，行文依然略長，感謝耐心讀完的看官。

什麼是軟體世界的“Supply Chain”

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

以銀行為例，消費者、業務部門使用的軟體，由銀行的IT部門提供。但這些軟體僅僅有小部分是IT自己開發的，更多是從第三方供應商採購。而且，無論軟體是自己開發，還是由系統整合商或軟體廠商開發，都依賴於大量的更加基礎的軟體元件、專案、工具。在這個時代，也許除了國防軍工領域的軟體，幾乎不可能存在每一行程式碼都100%由自己開發的軟體 - 工作量不允許、經濟規律也不符合。

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

“Hello，World”後面可能有幾萬行程式碼

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

上述情況不限於JavaScript/Node.js，對其他語言環境也一樣。現在的計算機語言，Java、Golang、Rust、Ruby、Python、Julia... 不可勝數，都自帶包管理工具、“零部件”中央倉庫、以及龐大的開發生態。

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

根源：全球化的開源大生產

開源軟體運動如火如荼的進行了二十四五年（如果從1998年2月3日在矽谷的一次會議中首次提出“open source”一說開始算 - 當時網際網路先驅Netscape剛剛宣佈開放他們的瀏覽器原始碼），極大程度的改變了軟體業的面貌。當前全球企業超過90%直接或者間接甚至在無意識中使用了開源技術。

可以說，今天我們開發的幾乎每一套軟體，都是全球化生產協作的結果。例如無數Java工程專案幾乎必然依賴的基本日誌工具Log4J，最早在二十一年前由瑞士程式設計師Ceki Gülcü個人獨立開發提供；多少網際網路公司牛哄哄聲稱自主研發的瀏覽器，核心來自谷歌的Chromium；再有技術能耐的銀行證券金融巨頭的網站和使用者端，也離不開React、Vue、Electron、Qt等前端基礎框架；馬斯克的SpaceX火箭和Tesla汽車，作業系統和軟體工具也離不開Linux和GCC編譯器。

計算機領域有一句格言，“"All problems in computer science can be solved by another level of indirection"，被稱之為“軟體工程基本定理”（"fundamental theorem of software engineering"），分層（layering）- 這就是計算機領域解決問題的一個典型的、最根本的思維方法。這很好的解釋了軟體供應鏈的需要 - 從硬體、網路層、作業系統、虛擬化管理軟體、中介軟體、開發工具、開發框架、前端元件、輔助程式碼庫，到編譯器、解析器、執行時，層層疊疊，每一層面對自己的領域、解決好自己的問題，最終到達面向終極使用者的應用軟體，再大的公司、再牛的工程師，都難以自己包打天下。全球化和開源運動相輔相成，而軟體技術人則在這個開源世界的“烏托邦”相互成就。

但問題也就來了：在你的供應鏈上的各種“零部件”，不僅面臨“依賴地獄”的挑戰，你甚至還無法知道這些零部件的依賴傳遞關係、不瞭解它們的作者和來源。

虛擬世界的供應鏈遠比物理世界的無序凌亂

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

產品P，依賴於子系統/元件/基礎庫A、B、C、D、E，其中A又依賴於F、G、H...，B則依賴於G、H、X、Y、Z，而G又可能依賴於H... 有些情況下，還可能出現迴圈依賴 - A依賴於B，B依賴於C，而C依賴於A... 這就是傳說中的dependency hell（“依賴地獄”）。

可是這還只是複雜性的一個維度！每一個軟體零部件還有不斷變化中的版本：產品P版本1.2必須依賴於零部件A的版本2.5.1、而該版本又必須建立在零部件B的版本1.0.3基礎上...

某些物理世界的產業鏈中，產品和零配件也可以類比“版本”一說，例如2022年版的某型號汽車，可能採用2021年版的某汽配件X，但該型號汽車的2021年版則可能採用X略有規格變化的更早期版本... 但是，物理世界的零配件，不可能像虛擬世界的零配件那麼頻繁的釋出版本 - 由主版本、此版本、修訂號等繁複的組合而成（見“ ”；而且也不可能像軟體元件那樣存在“迴圈依賴”的風險。

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

相比之下，物理世界的產業鏈沒有這種不可控的問題存在 - 特斯拉、比亞迪的每一輛車，用到的每一個零配件的生產商都是100%確定的。

軟體供應鏈的四大風險

企業的基層開發人員，往往並不關注（也難以有能力和工具去評估）自己的程式碼所間接、被動引用的第三方程式碼包的來源、質量、安全風險。傳統企業的IT主管、CIO們，焦點在業務科技賦能、企業科技戰略佈局等巨集觀事情上，或者在生產環境質量保障、緊急情況的滅火上，越是高階管理層，越有可能已經遠離一線的戰陣，十年以上技術管理資歷的管理層，很可能在充當碼農手寫程式碼的當年，像npm、cargo、gradle之類今天無處不在的“軟體零部件”管理工具（package manager）還沒有成型或出現，對一個“Hello，World”微服務後面可能隱藏著幾萬行程式碼這種情況，未必有親身體驗，對其中的風險瞭解不足，基層工程師採用一個開源包只是一行命令一個回車的舉手之勞，足以讓坐在IT金字塔頂層的CIO們坐在火坑上而不自知。

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

• 軟體質量風險。企業軟體表面上由IT或者外包商開發，可是實質上背後是成千上萬的第三方開原始碼，企業的QA工程質量管理方法和流程，對於第三方完全失控無效。
• 長期支援風險。企業軟體所間接依賴的一些第三方開源零部件，並沒有商業體在背後提供質量承諾和長期支援。開源專案因創始人退出或者社群活躍度低而不再維護、半途而廢的，不在小數。產生維護支援需求時，企業自己不得不安排人手去處理該部分程式碼，先不說有沒有這個意願，企業自己的IT工程師是否有這個能力也難說。
• 智慧財產權風險。開源軟體的智慧財產權機制，反映在著佐權（Copyleft）和許可證（Permissive）。後者約束了你的軟體的分發傳播需要滿足的條件，前者則往往更進一步要求你用開源元件開發的軟體本身的原始碼必須沿用同樣的開源條款，導致你的軟體智慧財產權不得不公開。國內軟體企業在使用開源、貢獻開源的過程中規則意識普遍薄弱，存在錯誤混用不相容的許可證，違反許可證規定二次釋出等問題，帶來更為複雜的智慧財產權問題和法律合規風險。
• 資訊保安風險。在開發人員寫第一行程式碼前，一個系統可能就註定繼承了一堆“ 安全債務” - 部分取決於這個系統的設計者、開發者選擇採用什麼第三方元件，部分取決於這些第三方元件的開發者又選擇依賴於什麼別的元件。反正安全風險是傳遞的，只要有一個零部件有安全漏洞、甚至是在漫長複雜的網際網路分發鏈路上被篡改過注入了惡意程式碼，你的系統就繼承了所有這些風險。

在資訊化程度比較高的金融業，軟體作為金融資訊基礎設施的重要組成部分，安全問題將直接影響金融資訊系統的安全穩定執行。

對於企業們來說，你的所謂“資訊保安”、“安全加固”，也就取決於xkcd.com畫的這張圖右下角那塊小積木 - 可能是地球上隨便哪個地方的一個路人甲工程師以無私“活雷鋒”精神默默耕耘多年奉獻的一段程式碼：

Supply Chain Attack - 軟體供應鏈攻擊

在複雜混亂的軟體供應鏈之下，黑客利用其中的漏洞進行安全攻擊，從中漁利，是顯而易見的。當程式設計師在開發軟體的過程中無知覺的使用了被惡意篡改的零部件，所開發出來的系統可以說天生就埋入了危險種子。以前段時間鬧的非常嚴重的Log4J遠端程式碼執行漏洞問題為例，一個存在了近二十年、極其大量的為開發者採用從而在無數的網際網路網站、企業軟體、Web工具中執行的日誌記錄元件，讓使用它的工程師做夢也想不到。這類攻擊，隱蔽性極高 - 你的程式碼不用Log4J不等於你所依賴使用的第三方程式碼或者它們所依賴的上游程式碼不用。

正因為其隱蔽性，大大增加黑客的興趣，這一類攻擊正在迅速增長，以至於拜登政府都不得不視之為嚴重危害。隨之而來是科技企業共同推動下，拜登政府成立開源安全相關的基金，以長期資助促進對安全漏洞的監控和修復。

根據Gartner的報告，到2025年全球將有45%的機構組織遭遇所謂的軟體供應鏈攻擊 - 是2021年的3倍。這些攻擊一旦成功，對於黑客而言經濟利益巨大，對被攻擊的企業則是摧毀性的 - 不僅危害執行遭受攻擊的企業，更可能因為其商業資料、使用者資料的丟失而延伸至損害受損企業的客戶。數字化世界裡，安全攻擊往往是有網路效應的、傳染性的。

軟體世界虛擬供應鏈攻擊的嚴重性隱蔽性，如果和物理世界類比，還是拿汽車產業做比喻：車廠所造的汽車裡不知不覺用到的某些零部件，不僅有質量風險，甚至還可能反過來搞破壞，例如監控駕駛者的行車資料偷竊傳送給黑客。如果把汽車換成火車甚至軍艦，可以想象所帶來的災難。

軟體供應鏈裡的“康帥博” - Low但致命的那種

2021年初，有一位安全技術研究者兼白帽黑客叫Alex Birsan的，就發文詳細描述了他如何通過一種叫Dependency Confusion的方法，把“惡意”（象徵性但無害）的程式碼，“種入”到Microsoft、Apple、Uber、Yelp以及好些其他較為知名的公司的程式碼庫（內部供應鏈）中，Alex成功“攻擊”了35家企業，其中大部分擁有千人以上的員工規模。

Dependency Confusion的手法也不復雜，就是把含有惡意程式碼的軟體包上傳至npm、PyPi等網際網路公共倉庫，軟體包名字和常用的開源包完全同名（或者就是在該開原始碼上增加惡意程式碼，然後釋出新版本，正常功能完全一樣）。如果一些企業的內部開發環境有漏洞，其專案構建工具、整合工具並沒有被妥善配置以保障完全從且僅從內部倉庫拉取零部件，則很有可能會拉到公網上的同名中毒版本，然後神不知鬼不覺的種入了安全漏洞，當這樣一套軟體成本被銷售、部署到客戶那裡，就是坐等配合外部黑客的攻擊。

此外還有所謂Typosquatting的攻擊，同樣也不高階，把帶有惡意程式碼的軟體包釋出至公共倉庫中，包的名字和被仿冒的開源專案非常相似 - 往往就是少個字母（例如CoffeeScript被CofeeScript或者CoffeScript假冒）、多一道橫槓（crossenv.js被cross-env.js假冒）... 嗯，就是“康帥博”、“奧利傲”、“六大核桃”這些李鬼玩法，不過危害嚴重到致命，這些軟體包往往維持原有的功能，在你的軟體系統中正常勤懇的工作著，但同時也默默的偷竊著你資料、充當著配合外部攻擊的內鬼。

開源工作者在開源社群的賬戶也可能被盜取，畢竟開源工程師也是普通人，他們在賬戶安全的防護上也不見得就比尋常人更強，例如在GitHub上的開發賬戶被破解盜取，黑客也可以悄悄的替這個賬戶的主人在他的原始碼裡添上幾行...

再有就是通過所謂social engineering的方法，惡意參與到一個開源專案的合作中，直接在上游汙染其所間接依賴的某些其他開源元件。開源社群因為成員有共同的對開放共享的理念認同，通常全心、熱情擁抱參與者，這也給作惡者可乘之機。

總之，“惡意”這倆字，不僅在現實世界，在軟體世界也是滿滿的。怎樣把“惡意”關在籠子裡？

安全執行沙箱類技術的崛起

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

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

在雲端計算的環境下，雲原生型安全沙箱技術也在演進，有望在企業環境中，對軟體供應鏈安全問題提供一部分“治標”的解決方案（“治本”還得更加長期、綜合、涉及面更廣的綜合策略）。

FinClip：前端安全沙箱技術

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

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

FinClip的嵌入式安全沙箱，又被稱之為小程式容器，它的本質其實是建立在Security Capability model基礎上的瀏覽器核心的擴充套件，其沙箱的特點，體現在三個方面：

• 沙箱內小程式之間的隔離
• 沙箱對執行其中的小程式程式碼，隔離其對宿主環境的資源訪問。以一家銀行與它的合作生態為例，銀行在自己的App上引入了衣食住行各類消費場景的小程式，這些小程式均非本行開發，也不能訪問到當前宿主App的任何資料資源
• 沙箱隔離了宿主對於沙箱中執行的小程式所產生的資料。以一家銀行與一家券商的合作為例，券商把自己的業務小程式投放到銀行的App中，銀行App作為宿主，並不能訪問沙箱內部該小程式的執行資料（當然，這是需要有一定的行業規範、監管政策去約束，但技術上首先是完全可能）

換句話說，FinClip試圖構建一個Zero Trust（“零信任”）環境，不管小程式的“供應商”是誰，它們的程式碼都被隔離、同時也被保護在沙箱環境中。

FinClip安全沙箱還配備了雲端的管控後臺，讓任何小程式可以被關聯到指定的App宿主所嵌的沙箱例項中，從而能且僅能執行在某一款App或者某一個終端上。像網際網路小程式一樣，FinClip的小程式也可以被實時上下架，對於金融機構來說，起到“實時風控”的效果，因為上下架的管理工具和許可權，都由企業私有化執行、自行負責。任何有潛在安全風險的前端程式碼，一經發現即可瞬間下架，使用者端再也無法開啟使用。

這些安全管控的能力，可以說是企業尤其是金融機構數字化轉型所必須。對於企業而言，內部IT、外部合作伙伴，均可以作為“供應商”以小程式方式實現、提供數字化場景，從而形成數字生態。

Deno：雲端安全沙箱技術

Deno是Node.js的發明者Ryan Dahl的重新發明。在推動伺服器端JavaScript的應用生態獲得巨大成功後，Ryan也看到Node.js的很多存在問題，在2018年的一次公開演講中，提到了其為Node.js感到後悔的十件事。最終他另起爐灶，按自己的理想重新打造一個新的技術，也就是Deno，其中最重要的設計考慮就是安全優先、為deno技術設計的第一性、並採用V8引擎作為JavaScript執行的安全沙箱。

[ 預設執行在Deno的沙箱裡的程式碼，沒有對沙箱以外任何資源的訪問權]

當然，Deno不僅是一個安全沙箱，在本文我們僅從這個角度去談論它。它的野心不僅在於替代Node.js把之前沒有做對的事情做對，它基於Rust語言實現，支援WebAssembly，提出了“Isolated Cloud”（隔離雲）的概念，給網際網路提供比docker等容器類技術更加輕量和啟動時間更短、實現程式級隔離的新一代安全基礎技術設施，最新訊息是幾天前由紅杉資本領投獲得了新一輪2100萬美元的投資。

治本的綜合防範策略

安全沙箱技術的採用，不失為一個短期見效的治標方案，相信早晚會成為企業數字技術安全的標配。但是長遠的治本，需要更加綜合的策略，起碼有以下幾點。

Shift-left：“左移”安全焦點

什麼是“左移”（shift-left）？

我們IT所繪製的SDLC（Software Development Lifecycle） - 軟體開發生命週期階段圖中，一般習慣於把開發階段畫在最左邊，然後依次向右是測試（功能性與非功能性）、部署、運維。一直以來，IT習慣於在非功能性測試階段就效能、高可用、健壯性、安全等進行檢測，到最後再來一道“安全加固”，然後上線。所謂安全策略，基本上是運維階段的事後補票。

Shift-left的宗旨，就是我們要把安全焦點左移至開發階段，對開發階段所依賴的軟體供應鏈進行檢測，搞清楚自己的軟體的（1）where - 是在哪裡開發的、源頭為何，（2）how - 怎樣開發的、“工藝流程”為何。

事實上每次發生Log4J這類安全漏洞，最終出來負責修復（和背鍋）的還是開發人員，不是運維人員。軟體供應鏈上的風險，只能左移至開發階段防控。

這幾年越來越多的IT在建立DevOps實踐，但是，現在恐怕應該一步到位邁向DevSecOps。

SBOM：掌握自己的軟體“物料清單”

首先是建立高度自動化、智慧化的CI/CD流水線，讓安全檢測和功能測試、迴歸測試接受同等待遇，充分利用安全檢測工具去分析軟體生產過程中不同階段的潛在漏洞和風險。在這裡，要堅持的宗旨不是“完美無缺”的安全檢測，而是“從小處做起”，形成“反覆驗證”、“持續優化”、“迭代”的迴圈。

近年來針對軟體供應鏈安全出現的工具門類SCA（Software Composition Analysis），值得關注和運用。這類工具，顧名思義，就是對複雜的軟體包的組成、依賴關係、傳遞依賴關係進行分析，向企業提供潛在安全風險的預警。通常SCA類工具，能檢測包管理工具（package manager）、啟動清單檔案（manifest file）、原始碼（source code）、二進位制檔案（binary）、容器映象（container image）、軟體許可證（License & Permit）等等，最終為企業生成完整呈現傳遞依賴關係的“物料清單”（Software Bill of Materials - 簡稱SBOM），並以之與網上某些政府或者可信商業組織執行維護的安全風險資料庫進行比對，從而就企業客戶當前的軟體的安全風險、智慧財產權風險作出評估反饋。

每一家企業，只要用到開源的“零配件”，最終可能都需要一張自己的SBOM。

Database：從外部獲得公共安全設施的支援

光有SBOM還不行，需要公共的安全攻擊事件庫、開源軟體漏洞資料庫，統一收集全球性的相關的資料，一方面調動公眾參與提供最及時的資訊，另一方面提供協議、介面，以支援自動化的安全漏洞管理工具。這方面美國國家標準技術研究所（NIST - National Institute of Standards and Technology）提供了示範，他們執行一個稱之為NVD（National Vulnerability Database）的公共資料庫，並通過SCAP（Security Content Automation Protocol）協議規範了這些安全漏洞資料相關的命名、格式，讓工具開發商在安全漏洞檢測、評估和自動化處理的應用工具中連線、更新和使用資料。例如一家使用這種工具的企業，不僅獲得一張SBOM，還可以實時基於NVD資料庫進行校驗，從而及時評估自己的風險。

今天的開原始碼在軟體世界可以稱得上“無遠弗屆”，安全漏洞的發現與彌補，也不是單一企業能解決，需要權威可信的公共設施的支援配合。

這好比食品行業的供應鏈，你一家小餐廳能保證所採購的豬肉不是死豬肉、進貨的調味料沒有地下作坊摻和的有毒化學品？食品行業有衛生組織的監督、黑名單、法律追責。在跨國的虛擬世界，需要全球的公共資源配合，共同維護個黑名單、共享預警，已經是必要條件。

Governance：在內部建立軟體開發的安全治理

大概在十五年前，國際的大型銀行、華爾街的巨頭們，大部分都建立了一定的內部開源技術白名單，相比之下，國內金融機構們的IT是否已經完善類似的制度，沒有公開的統計數字可考，但要打個問號。

另一方面，開源技術白名單，在這些傳統國際金融巨頭裡，其實也有相當大的弊病。例如某美國銀行，直至2017年，白名單上可用的開源軟體依然是“遠古”版本的Apache、Tomcat，導致軟體廠商、開發商為了符合該銀行的要求而不得不“降級”自己的零部件。過於保守的白名單策略，阻礙了企業的技術發展，甚至製造額外不必要的成本。而且古老穩定的開源軟體版本，並不等同於安全，安全漏洞這種東西可真是不分時段，任何軟體的設計與執行，總是基於一定的環境假設，過去沒有被發現的問題，可能在新的網路環境、作業系統環境下，反而就變成漏洞。傳統金融機構所特有的保守技術做派，未必是安全風控的最佳做法。以官僚化的OA慢流程來“風控”技術世界的快迭代風險可以理解，但過度的僵化同樣帶來高安全風險，例如你所依賴的某個異常古老的開源元件A，忽然因為A自己或者A所傳遞依賴的上游元件被黑客挖出了安全漏洞，需要緊急升級A最新的版本，可是你的應用軟體太老無法相容A的新版本，也就等於被活活噎死，無計可施。

白名單是否必要？由什麼部門職能來維護？軟體進出白名單的稽核流程是怎樣的？在一個擁有數千工程師的大型機構裡，如何有效貫徹？對於採用了不在白名單上的開源技術的軟體廠商和開發商，作為甲方要提供怎樣的合理政策？這些問題都是企業必須梳理回答的。

數字化轉型？先建立“零信任”架構

數字化企業的一個特點是：企業的內外邊界在數字世界被重新定義。數字銀行無法再由物理世界中營業網點門口的兩隻石獅子來區隔消費者，它是連線的、開放的、生態化的，在網上通過各種各樣的第三方與客戶實現互動，與提供各種消費場景、商業場景的合作伙伴之間，是一種你中有我、我中有你的融合關係。或者套用FinClip安全沙箱這個產品的邏輯：傳統物理世界的交叉合作、資源整合，在數字世界就是合作伙伴之間的程式碼（可能是小程式化的）交換 - 你執行我的、我執行你的。

傳統的企業安全模型，無法保障數字化環境下的運轉，因為傳統模型建立在一個重大的假設上：任何成功進入、處於企業內部網路的軟體、系統、工具、程式碼、使用者，都是可信任的。在這樣的假設下，黑客只要通過例如上述軟體供應鏈攻擊，成功的進入內網，就成為了授信的insider（內部人士）。在資訊化時代，這樣的問題發生機率相對低。在企業內外數字邊界日益“模糊”、員工與客戶日益通過社交工具互動而“社群化”、分散式組織遠端辦公成為常態的數字化時代，恐怕連傳統定義下的“內網”都需要重新商榷，再也難以假設在公司內網裡的東西就是可信的。

就是在這樣的背景下，Zero Trust Architecture（“零信任”架構）應運而生 - 奉行“Never trust，Always verify”（“永不信任，總是驗證”）的宗旨，數字化企業需要去除不言而喻的、隱含的對內外網任何應用、網路、使用者的信任假設，應用之間、服務之間、元件之間的通訊連線，並不建立在假設的安全信任基礎上，完全隔離、大家都是陌生人、每一次的互動都必須做足安全認證、不因為在同一組織或者網路下就可以安全降級，並且任何程式碼的執行始終受到監控以捕捉任何可疑行為。

不錯，就是一種“草木皆兵、疑神疑鬼”的架構準則。但是對於通過供應鏈汙染而“播種”內鬼的安全攻擊，似乎這是最有效的手段。

數字化時代就是連拜登都得聽說過Log4J的時代

作為記憶提醒，以幾個技術關鍵詞作結：Supply chain Attack、Zero Trust、DevSecOps、Security Sandbox、SBOM、Capability model（本文未及展開）...，未來我們將越來越頻繁的聽到更多的這些不僅僅再是概念的“熱詞”。因為軟體供應鏈的安全攻擊風險，是一個日益嚴峻的問題，是現代軟體開發模式、開源運動帶來的副產物。其危害之大，引起各國政府級別的關注。在金融領域，解決這個問題尤為緊迫，需要在金融數字基建的層面去考慮方案。

企業數字化轉型，改變了企業的數字邊界，顛覆了傳統內外網的簡單分割；按凡泰極客（FinClip技術的研發團隊）的觀點， 企業軟體供應鏈也發生了外部動態化 - 諸如小程式、輕應用型別程式碼的供應與執行，誰都可以提供、也誰都可能執行，數字資源整合，就是程式碼級合作、基於Security Capability Model的能力互動、以及零信任的執行。

軟體供應鏈安全的保障機制，需要企業在軟體開發規範、流程、工具、技術架構方面採取綜合策略，甚至需要行業雲提供行業級的基礎設施支撐和聯合行業內經營機構、行業外技術提供商進行協作。

與此同時，建立zero trust的原則和架構理念，利用Capability-based的安全沙箱技術，去隔離執行企業內外來源於IT、開發商和商業合作伙伴的程式碼，是一個無需再等、值得馬上開始的嘗試。