低代码/无代码工具通过一套拖拽式的用户界面，允许非程序员用户创建或修改应用程序，使得用户无需依赖传统的开发团队即可开发新的数据驱动型应用程序。低代码/无代码开发让企业得以通过使用预构建好的应用程序组件“块”，轻松地创建出能够快速部署的应用程序。
低/无代码工具及平台的目标用户是两组完全不同的人群。一组是非技术人员，有时被称作是“平民开发者”，他们使用这些工具来创建自己的应用程序，通常是为了简化他们的工作流程然后连接一些可能无法相互通信的产品。
另外一组则是传统的开发人员，他们使用这些预构建的块来简化自己的工作，帮助他们更快地将关键业务的预构建应用程序组件组合到一起。Mendix 最近发布的一项调查显示，64% 的 IT 专业人士认可低代码作为他们的首选解决方案。
在所有使用低代码的项目里，有多达 59% 的项目是属于业务和 IT 团队之间的协作，这意味着用户需要像处理其他任意第三方代码组件一样考虑软件供应链里的低代码/无代码组件。
1. 低代码/无代码的风险
和软件供应链有关的业务风险在低代码/无代码的世界里同样存在，因为它们同样是基于容器的架构或是无服务器计算这些较为传统的开发范式。
任何这些范式的实现都有赖于它们所使用的框架是建立在安全的基础之上这一前提假设。换句话说，这假定了它们没有任何可能影响监管合规性或是在发生网络安全事件时直接影响商业声誉的造假能力。
举个例子，拿容器世界作个示范，我们已经看到了相关的大量报道：一些恶意用户在容器镜像里植入了挖矿软件然后将这些恶意软件发布到公共的 Docker 注册表。这可是一只肥羊，那些从一些知名的注册表拉取容器的用户很少会去检查它们。然而如果没有仔细检查容器镜像里面的内容的话，任何部署，只要引用了它们，也就等于为各种网络威胁敞开了大门，这里面还包括了可能会影响数据保护的意想不到的功能。
这也是为什么软件供应链会成为网络安全团队首要考虑因素的原因之一。
2. 将第三方 API 的交互脚手架化
过去的 2021 年在软件方面教会我们的一件事情就是，供应链很复杂，而且攻击者会利用我们对于一些开发范式的信任不断寻找可乘之机。
向平民开发者推出低代码/无代码产品将会带来的安全风险，可能会比用户自身意识到的要更加复杂。
一个平民开发者也许知道其应用程序的数据隐私要求，但是他未必能完全清楚脚手架是如何与第三方 API 交互的，从而使他们的组织很容易无意中就违反了一些合规性要求。
比如，加州隐私权法案（CPRA）定义了几个新的个人身份信息（PII）类别，并将数据传输要求扩展到加州消费者隐私法案（CCPA）定义的范畴之外。熟悉 CCPA 要求并且使用低/无代码框架的平民开发者可能不理解如何正确处理这些新的需求，甚至对于脚手架是如何解决这些问题也并不是很清楚。
投资低代码/无代码解决方案的一些组织应当在其选择供应商的过程中涵盖以下部分：
- 执行过一些常见的安全框架（如 NIST 800-218 1.1，安全软件开发框架等）的全面安全审核；
- 提供一份由供应商给出的软件物料清单（SBOM），用于描述支持低代码/无代码框架的软件供应链的复杂性；
- 审核数据传输实践以及 API 的使用以确认数据操作的监管影响；
- 了解低/无代码供应商提供的与漏洞管理工作相关的补丁的服务级别协议（SLA）。
3. 最底下的仍然是代码
尽管低代码/无代码框架为开发人员和平民开发者提供了一种简单的开发范式，它们却仍然需要代码的支持。“低代码”和“无代码”术语代表着用户需要知道多少程度的代码细节，而不是说它们具体包含多少代码。
和所有现代软件一样，低代码\无代码框架同样也是基于多种来源的代码库构建的：已经商业化的第三方供应商、开源组件以及云 API 服务。这些元素中的每一个都可以代表一门独立的代码流派，每个流派都拥有属于自己的代码流。将它们放到一起，也就构成了一个现代服务的供应链，因此任何损害该供应链的行为都可以看作是一次供应链攻击。
这也即是为什么了解软件供应链是如此重要的原因，即便对于低代码或者无代码的框架来说同样如此。它们最底下仍然是靠代码赋能了这些应用程序，如果框架提供者没有能力管理相关风险的话，那么最终承担这些风险的仍然会是它们的消费者。
