在过去的几年中,低代码和无代码工具以及平台在企业中兴起。2021年，Gartner魔力象限在关于低代码的报告中指出，41%的非IT从业人员使用低代码/无代码工具来定制、构建数据,或提出技术解决方案。同时Gartner预测到2025年底,将有一半的新增低代码用户来自从事非IT 行业的商业客户。

​低代码/无代码工具提供支持拖放的交互界面,使得即使非程序员也能够创建或修改应用程序。从而，用户能够开发出新的数据驱动的应用程序，而且无需再依赖传统的开发团队。低代码/无代码框架允许企业通过使用预建的应用组件“块”轻松创建可快速部署的应用程序。

低代码/无代码平台以及工具针对的是两类完全不同的用户。一类是非技术人员，他们使用这些工具来创建自己的应用程序，通常是为了简化自己的工作流程,以及连通那些可能还互不通信的产品。另一类用户则是传统开发人员，使用这些预建的组件使他们的工作变得更简单，同时帮助他们快速组合这些预建的关键业务应用组件。

最近进行的一项调查显示，64%的IT专业人士认为低代码是他们首选的开发解决方案。另外多达59%的低代码项目都是业务团队和IT团队协作完成的，这意味着你需要像考虑其他第三方代码组件一样去考虑软件供应链中的低代码/无代码组件。

低代码/无代码的风险

与使用基于容器的架构或Serverless计算的传统开发模式一样，采用低代码/无代码模式同样存在与软件供应链相关的业务风险。任何模式的实现都依赖于提供的框架建立在安全可靠的基础上，要求他们不能含有那些可能违反法规或发生网络安全事件时会直接影响企业商誉的功能。

举一个关于使用容器的案例：我们曾看到大量的相关报告，恶意用户在容器镜像中植入隐藏的流氓软件，然后将镜像发布到公共Docker注册。这是一个很大的库，因为其信誉良好从中提取容器镜像的用户很少会再去检查一下。然而一旦没有对那些问题镜像进行确切的检查，任何引用它们的部署都将会为各种网络威胁打开大门，包括威胁数据安全的非预期功能。这就是软件供应链成为网络安全团队首要考虑的原因之一。

框架与第三方 API 的交互

2021年教会了我们一件关于软件的事情就是供应链很复杂！攻击者通过利用我们对开发范例的信任不断寻找漏洞。

向非技术人员推出低代码/无代码产品带来的安全风险可能比用户了解到的更为复杂。非技术人员可能也知道他们的应用有数据隐私相关的需求，但是完全不清楚框架如何与第三方API进行交互，满足需求更是无从谈起。从而可能无意中使他们的企业违反了相关法规要求。例如加利福尼亚隐私权法案(CPRA)定义了几种新的个人身份信息(PII)隐私权法案，并为相关数据传输的安全要求扩展了相关法案(CPPA)的定义。熟悉 CCPA 需求并使用低代码/无代码框架的非技术人员可能不知道如何正确处理这些新需求，甚至不知道框架是如何处理它们的。所以购买低代码/无代码解决方案的企业应在其供应商选择过程中关注以下内容：

• 全面结合通用安全框架的安全审查，如 NIST 800-218《安全软件开发框架V1.1》。
• 供应商提供的软件物料清单(SBOM)需要描述支持低代码/无代码框架的软件供应链的复杂性。
• 审查数据传输和 API 使用情况，以确定数据处理的监管影响。
• 了解低代码/无代码供应商针对处理漏洞补丁的服务级别协议。

底线，它仍然是代码

虽然低代码/无代码框架为开发人员以及非技术人员提供了一种简单的开发模式，但它们仍然需要代码提供支持的。“低代码”和“无代码”是指用户需要知道多少代码来实现应用，而不是它们包含多少代码。

与所有当下的软件一样，低代码/无代码框架也是依赖许多的代码库构建的：商业的第三方服务商、开源组件以及云 API 服务，这其中的每一个都代表一个独立的代码分支，每个分支又可以再包含自己的代码分支。这些分支一起构成了现在的服务供应链，因此该链中的任何妥协都可能带来相关攻击。这就是为什么要了解你的软件供应链是如此重要的原因。即使对于低代码/无代码框架也是如此，因为仍然有代码为这些应用程序提供支持。如果框架提供者没有能力管理相关风险，那么最终承担这些风险的就是该框架的使用者了。