让企业数字化砸锅和 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、开发商和商业合作伙伴的代码，是一个无需再等、值得马上开始的尝试。