低代码/无代码工具允许非程序员用户通过一组拖放式用户界面来创建或修改应用程序，这样用户就可以开发新的数据驱动的应用程序，而无需依赖传统的开发团队。低代码/无代码开发使企业能够通过使用预构建的应用程序组件“块”轻松创建可快速部署的应用程序。

低/无代码工具和平台的目标用户是两个完全不同的人群。一群非技术人员，有时称为“平民开发人员”，使用这些工具创建自己的应用程序，通常是为了简化他们的工作流程，然后连接一些可能无法相互通信的产品。

另一组是传统的开发人员，他们使用这些预构建的模块来简化他们的工作，并帮助他们更快地将关键业务的预构建应用程序组件组合在一起。Mendix最近发布的一项调查[2]显示，64%的IT专业人员赞成将低代码作为他们的首选解决方案。

(相关资料图)

在所有使用低代码的项目中，多达59%是业务和IT团队之间的协作，这意味着用户需要像任何其他第三方代码组件一样，考虑软件供应链中的低代码/无代码组件。

— 1 —

低代码/无代码的风险

与软件供应链相关的业务风险也存在于低代码/无代码世界，因为它们也是传统的开发范式，如基于容器的架构或无服务器计算。

任何范式的实现都依赖于他们使用的框架是基于安全的前提。换句话说，假设他们不具备任何在发生网络安全事件时可能影响监管合规性或直接影响商业信誉的欺诈能力。

比如以容器世界为例，我们看到了大量的相关报道：一些恶意用户在容器镜像中植入挖矿软件，然后将恶意软件发布到公共Docker注册表中。这是一只肥羊，从一些知名注册中心拉容器的用户很少检查。但是，如果不仔细检查容器映像的内容，任何引用它们的部署都将为各种网络威胁打开大门，包括可能影响数据保护的意外功能。

这也是软件供应链会成为网络安全团队首要考虑的原因之一。

— 2 —

搭建第三方API的交互

过去的2021年告诉我们关于软件的一件事是，供应链是复杂的，攻击者会利用我们对一些开发范式的信任，不断寻找机会。

低代码/无代码产品的推出给平民开发者带来的安全风险可能比用户自己意识到的更复杂。

一个平民开发人员可能知道他的应用程序的数据隐私要求，但是他可能不完全理解脚手架如何与第三方API交互，这使得他的组织很容易在无意中违反一些遵从要求。

例如，《加州隐私法》(CPRA)定义了几个新的个人身份信息类别(PII ),并将数据传输要求扩展到了《加州消费者隐私法》(CCPA)的定义之外。熟悉CCPA需求并使用低/无代码框架的平民开发者可能不理解如何正确处理这些新需求，甚至不理解脚手架如何解决这些问题。

一些投资低代码/无代码解决方案的组织应该在其供应商选择过程中涵盖以下部分：

对一些常见的安全框架(如NIST 800-218 1.1、安全软件开发框架等)进行了全面的安全审计。);

提供供应商给出的软件物料清单(SBOM)，用于描述支持低代码/无代码框架的软件供应链的复杂程度；

审计数据传输实践和API使用，以确认数据操作的监管影响；

了解低/无代码供应商提供的漏洞管理相关补丁的服务水平协议(SLA)。

— 3 —

底层还是代码。

虽然低代码/无代码框架为开发者和平民开发者提供了一个简单的开发范式，但他们仍然需要代码的支持。术语“低代码”和“无代码”表示用户需要知道多少代码细节，而不是它们包含多少代码。

像所有现代软件一样，低代码无代码框架也是基于许多来源的代码库构建的：商业化的第三方供应商、开源组件和云API服务。这些元素中的每一个都可以代表一个独立的代码学校，每个学校都有自己的代码流。它们放在一起就构成了现代服务供应链，所以任何破坏供应链的行为都可以被视为供应链攻击。

这就是为什么理解软件供应链如此重要，即使对于低代码或无代码框架也是如此。在底部，这些应用程序仍然由代码支持。如果框架提供者不能管理相关的风险，他们的消费者最终仍将承担这些风险。

标签：