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