什么是“数字化时代”？数字化时代就是连拜登都得听说过 Log4J 的时代。在大谈数字化转型、数字化基建的当下，数字化安全风险却首先成为严重问题。更甚于过去所谓的“信息安全”的地方是，在以“网络效应”为特点的数字化世界里，安全攻击往往是有网络效应的、传播性的、高维复杂的。

其中利用污染软件供应链进行的攻击，尤其隐蔽和危害性大。软件供应链攻击“恶意”手法常见有 4 种：dependency confusion（恶意白撞）, typosquatting（恶意“康帅博”）, account compromise（恶意盗取开发者账户对开源代码掺毒）、social engineering（恶意浑水摸鱼污染上游）。

数字世界中软件供应链遭受攻击带来的风险越高越频繁  – 软件供应链里的“康帅博”、“六大核桃”、“奥利傲”等李鬼们会越来越多。根据 Gartner 的报告，到 2025 年全球将有 45%的机构组织遭遇所谓的软件供应链攻击 - 是 2021 年的 3 倍。换而言之，你的企业在未来几年有接近一半的机会遭到攻击甚至中招。

因为软件供应链的安全攻击风险，是一个日益严峻的问题，是现代软件开发模式、开源运动带来的副产物。其危害之大，引起各国政府级别的关注。在金融领域，解决这个问题尤为紧迫，需要在金融数字基建的层面去考虑方案。

可是，防范供应链安全攻击没有银子弹，在此我们探讨一些工具、方法和策略。

安全运行沙箱类技术的崛起

虚拟世界的“恶意”代码，也只能用虚拟的“牢笼”去“关住”它。安全沙箱（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”（“永不信任，总是验证”）的宗旨，数字化企业需要去除不言而喻的、隐含的对内外网任何应用、网络、用户的信任假设，应用之间、服务之间、组件之间的通信连接，并不建立在假设的安全信任基础上，完全隔离、大家都是陌生人、每一次的交互都必须做足安全认证、不因为在同一组织或者网络下就可以安全降级，并且任何代码的运行始终受到监控以捕捉任何可疑行为。

不错，就是一种“草木皆兵、疑神疑鬼”的架构准则。但是对于通过供应链污染而“播种”内鬼的安全攻击，似乎这是最有效的手段。