安全沙箱在加强软件供应链安全的具体方式

早在2017年，黑客实施了 "NotPetya "供应链攻击。通过在广泛使用的会计软件中植入一个 "后门"，他们能够感染数百家公司的系统并窃取数据。多年来，黑客通过攻击PDF编辑器应用程序、第三方数据聚合器，甚至是暖通空调服务供应商（2014年臭名昭著的Target攻击）来发动供应链攻击。

2020年12月针对SolarWinds®的 "供应链攻击"被认为是网络安全界的一个里程碑事件。这次攻击是由SolarWinds的Orion软件中的安全漏洞导致的，使黑客能够入侵全球数百家公司的系统。

开源软件运动如火如荼的进行了二十四五年，极大程度的改变了软件业的面貌。当前全球企业超过90%直接或者间接甚至在无意识中使用了开源技术。享受便利的同时问题也随之而来，以上的软件供应链安全事件也层出不穷。为了保护自己免受此类攻击，企业必须超越传统的、有风险的 "信任但核实 "的网络安全方法。

软件供应链的四大风险

对于企业来说，当前软件供应链起码面临四类风险。

1、长期支持风险。企业软件所间接依赖的一些第三方开源零部件，并没有商业体在背后提供质量承诺和长期支持。开源项目因创始人退出或者社区活跃度低而不再维护、半途而废的，不在小数。产生维护支持需求时，企业自己不得不安排人手去处理该部分代码，先不说有没有这个意愿，企业自己的IT工程师是否有这个能力也难说。

2、软件质量风险。企业软件表面上由IT或者外包商开发，可是实质上背后是成千上万的第三方开源代码，企业的QA工程质量管理方法和流程，对于第三方完全失控无效。

3、信息安全风险。在开发人员写第一行代码前，一个系统可能就注定继承了一堆“安全债务” - 部分取决于这个系统的设计者、开发者选择采用什么第三方组件，部分取决于这些第三方组件的开发者又选择依赖于什么别的组件。反正安全风险是传递的，只要有一个零部件有安全漏洞、甚至是在漫长复杂的互联网分发链路上被篡改过注入了恶意代码，你的系统就继承了所有这些风险。

4、知识产权风险。开源软件的知识产权机制，反映在著佐权（Copyleft）和许可证（Permissive）。后者约束了你的软件的分发传播需要满足的条件，前者则往往更进一步要求你用开源组件开发的软件本身的源代码必须沿用同样的开源条款，导致你的软件知识产权不得不公开。国内软件企业在使用开源、贡献开源的过程中规则意识普遍薄弱，存在错误混用不兼容的许可证，违反许可证规定二次发布等问题，带来更为复杂的知识产权问题和法律合规风险。

在信息化程度比较高的金融业，软件作为金融信息基础设施的重要组成部分，安全问题将直接影响金融信息系统的安全稳定运行。对于企业来说，如何把软件供应链里的“恶意”关在笼子里？或许安全沙箱一种可操作的手段。

前端安全沙箱技术应用案例：

虚拟世界的“恶意”代码，也只能用虚拟的“牢笼”去“关住”它。安全沙箱（Security Sandbox），就是这么一种数字牢笼，它的形态和技术实现方式有很多种，本质上它是一种安全隔离机制，通过构建一个封闭的软件环境，隔离了它所在的“宿主”的资源包括内存、文件系统、网络等等的访问权限。运行在这个封闭环境中的进程，其代码不受信任，进程不能因为其自身的稳定性导致沙箱的崩溃从而影响宿主系统，进程也无法突破沙箱的安全管控以读写宿主系统的资源。

在云计算的环境下，云原生型安全沙箱技术也在演进，有望在企业环境中，对软件供应链安全问题提供一部分“治标”的解决方案（“治本”还得更加长期、综合、涉及面更广的综合策略）。

沙箱类技术以各种形态出现：在BSD等操作系统里就提供直接叫做“Jail”的虚拟化隔离；在JVM里为了支持Java Applet这里网络加载的代码的运行，实现了sandbox机制；浏览器里的HTML渲染引擎，一定程度上也可以视为一种在用户态的基于安全能力模型（Capability-based）的沙箱技术。

FinClip：前端安全沙箱技术

FinClip安全沙箱中运行的轻应用，选择了兼容互联网主流的小程序规范。这是一个非常明智的设计，FinClip的开发团队没有重新发明自己的技术规格，而是全力支持小程序这种形态的轻应用，一方面是因为小程序类技术的体验和效果在互联网上得到充分验证、获得巨大成功，另一方面是网上积累了丰富的技术生态、开发框架、以及更重要的 - 人才资源，从而让企业IT几乎是无缝掌握这个技术，能迅速投入应用。

FinClip是一种新型的轻应用技术，它有一个比较有趣的逻辑：企业的软件供应链在数字化时代可能是需要被重新定义的 - 有可能你的合作伙伴的代码运行在你这里、也有可能你的代码借道合作伙伴的平台去触达对方的客户。FinClip的核心是一个可嵌入任何iOS/Android App、Windows/MacOS/Linux Desktop Software、Android/Linux操作系统、IoT/车载系统的多终端安全运行沙箱。

FinClip的嵌入式安全沙箱，又被称之为小程序容器，它的本质其实是建立在Security Capability model基础上的浏览器内核的扩展，其沙箱的特点，体现在三个方面：

沙箱对运行其中的小程序代码，隔离其对宿主环境的资源访问。以一家银行与它的合作生态为例，银行在自己的App上引入了衣食住行各类消费场景的小程序，这些小程序均非本行开发，也不能访问到当前宿主App的任何数据资源
沙箱内小程序之间的隔离
沙箱隔离了宿主对于沙箱中运行的小程序所产生的数据。以一家银行与一家券商的合作为例，券商把自己的业务小程序投放到银行的App中，银行App作为宿主，并不能访问沙箱内部该小程序的运行数据（当然，这是需要有一定的行业规范、监管政策去约束，但技术上首先是完全可能）

FinClip安全沙箱还配备了云端的管控后台，让任何小程序可以被关联到指定的App宿主所嵌的沙箱实例中，从而能且仅能运行在某一款App或者某一个终端上。像互联网小程序一样，FinClip的小程序也可以被实时上下架，对于金融机构来说，起到“实时风控”的效果，因为上下架的管理工具和权限，都由企业私有化运行、自行负责。任何有潜在安全风险的前端代码，一经发现即可瞬间下架，用户端再也无法打开使用。这些安全管控的能力，可以说是企业尤其是金融机构数字化转型所必须。对于企业而言，内部IT、外部合作伙伴，均可以作为“供应商”以小程序方式实现、提供数字化场景，从而形成数字生态。

换句话说，FinClip试图构建一个Zero Trust（“零信任”）环境，不管小程序的“供应商”是谁，它们的代码都被隔离、同时也被保护在沙箱环境中。

Deno：云端安全沙箱技术
Deno是Node.js的发明者Ryan Dahl的重新发明。在推动服务器端JavaScript的应用生态获得巨大成功后，Ryan也看到Node.js的很多存在问题，在2018年的一次公开演讲中，提到了其为Node.js感到后悔的十件事。最终他另起炉灶，按自己的理想重新打造一个新的技术，也就是Deno，其中最重要的设计考虑就是安全优先、为deno技术设计的第一性、并采用V8引擎作为JavaScript运行的安全沙箱。
deno-sandbox

[缺省运行在Deno的沙箱里的代码，没有对沙箱以外任何资源的访问权]
当然，Deno不仅是一个安全沙箱，在本文我们仅从这个角度去谈论它。它的野心不仅在于替代Node.js把之前没有做对的事情做对，它基于Rust语言实现，支持WebAssembly，提出了“Isolated Cloud”（隔离云）的概念，给互联网提供比docker等容器类技术更加轻量和启动时间更短、实现进程级隔离的新一代安全基础技术设施，最新消息是几天前由红杉资本领投获得了新一轮2100万美元的投资。

企业必须面对真实存在的网络攻击威胁，这就是不可改变的事实，一旦遭遇软件供应链攻击，其造成的破坏都是非常严重的，数字化企业需要去除不言而喻的、隐含的对内外网任何应用、网络、用户的信任假设，应用之间、服务之间、组件之间的通信连接，并不建立在假设的安全信任基础上，完全隔离、大家都是陌生人、每一次的交互都必须做足安全认证、不因为在同一组织或者网络下就可以安全降级，并且任何代码的运行始终受到监控以捕捉任何可疑行为。

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