译者|徐蕾评论|孙书娟过去几年，低代码和无代码的工具和平台在企业中兴起。2021年，Gartner魔力象限在一份关于低代码的报告中指出，41%的非IT从业者使用低代码/无代码工具来定制、构建数据或提出技术解决方案。同时，Gartner预测，到2025年底，一半的低代码新增用户将来自从事非IT行业的商业客户。低代码/无代码工具提供了一个拖放界面，即使是非程序员也可以创建或修改应用程序。因此，用户可以在不依赖传统开发团队的情况下开发新的数据驱动应用程序。低代码/无代码框架允许企业使用预构建的应用程序组件“块”轻松创建可快速部署的应用程序。低代码/无代码平台和工具针对两种截然不同的用户。一类是非技术人员，他们使用这些工具来创建自己的应用程序，通常是为了简化自己的工作流程并连接可能尚未相互通信的产品。另一类用户是传统开发人员，他们使用这些预构建的组件来简化他们的工作，并帮助他们快速组装这些预构建的关键业务应用程序组件。根据Mendix最近进行的一项调查，64%的IT专业人员认为低代码是他们首选的开发解决方案。此外，多达59%的低代码项目是由业务团队和IT团队协作完成的，这意味着您需要像考虑其他第三方一样考虑软件供应链中的低代码/无代码组件代码组件。低代码/无代码风险与使用基于容器的架构或无服务器计算的传统开发模型一样，采用低代码/无代码模型会带来与软件供应链相关的相同业务风险。任何模型的实现都依赖于提供的框架建立在安全可靠的基础上，要求它们不包含在网络安全事件发生时可能违反规定或直接影响企业声誉的功能。举个使用容器的例子：我们已经看到许多恶意用户在容器镜像中植入隐藏恶意软件的报告，这些恶意软件随后被发布到公共Docker注册表。这是一个很大的存储库，因为从中提取容器镜像的信誉良好的用户很少费心去检查它。然而，如果不对这些有问题的图像进行明确检查，任何引用它们的部署都会为各种网络威胁打开大门，包括威胁数据安全的意外功能。这就是软件供应链成为网络安全团队最关心的问题的原因之一。框架与第三方API的交互2021年告诉我们关于软件的一件事是供应链很复杂！攻击者不断利用我们对开发范例的信任来寻找漏洞。向非技术受众推出低代码/无代码产品的安全风险可能比用户意识到的更复杂。非技术人员可能也知道他们的应用程序有数据隐私相关的需求，但完全不清楚框架如何与第三方API交互，更不用说满足需求了。这可能会无意中使他们的业务违反相关监管要求。例如，加州隐私法（CPRA）定义了几个新的个人身份信息（PII）隐私法案，并针对相关数据传输的安全要求扩展了相关法案（CPPA）的定义。熟悉CCPA要求并使用低代码/无代码框架的非技术人员可能不知道如何正确处理这些新要求，甚至不知道框架如何处理它们。因此，购买低代码/无代码解决方案的企业在选择供应商过程中应注意以下几点：全面的安全审查结合常见的安全框架，如NIST800-218《安全软件开发框架V1.1》。供应商提供的软件物料清单（SBOM）需要描述支持低代码/无代码框架的软件供应链的复杂性。审查数据传输和API使用以确定数据处理的监管影响。了解低代码/无代码供应商处理漏洞补丁的服务级别协议。归根结底，它仍然是代码虽然低代码/无代码框架为开发人员和非技术人员提供了一种简单的开发模型，但它们仍然需要代码来为其提供动力。“低代码”和“无代码”是指用户需要知道多少代码才能实现应用程序，而不是它们包含多少代码。像今天的所有软件一样，低代码/无代码框架是针对许多代码库构建的：商业第三方服务提供商、开源组件和云API服务，每一个都代表一个独立的代码分支，每个分支都可以在turn包含自己的代码分支。这些分支共同构成了现在的服务供应链，因此该链中的任何妥协都可能引发相关攻击。这就是了解您的软件供应链如此重要的原因。即使对于低代码/无代码框架也是如此，因为仍然有代码为这些应用程序提供动力。如果框架提供者没有能力管理相关风险，那么最终承担这些风险的是框架的用户。译者介绍徐磊，51CTO社区编辑，某领先电商公司技术副总监，专注于Java后端开发、技术管理、架构优化、分布式开发等领域。原标题：LowCodeDoesNotMeanLowRisk，作者：TimMackey
