如今,一股“全民开发者”的风潮正在兴起,由非开发人员对应用进行开发和创造。通常,这种模式由低代码或者无代码框架辅助进行。这些框架和工具允许非开发人员通过GUI抓取或者移动组件,创建逻辑友好的业务应用。
让更多的IT人员和业务社群创建应用来驱动业务价值,有非常明显的吸引力。但这不代表低代码和无代码平台本身没有安全问题。就像其他软件产品一样,开发平台和其相关代码的安全问题,不容忽视。
何为低代码/无代码开发?
无代码工具和平台通过一个“抓取和放下”的界面,让像商业分析师这样的非程序员能够创建和修改应用。在某些情况下,还是需要一些代码能力(低代码)和其他应用进行整合,或者生成报告和修改用户界面等功能。这通常会用像SQL或者Python这样的高级语言实现。
低代码/无代码平台的例子包括Salesforce Lightning、FileMaker、Microsoft PowerApps和Google App Maker。这些平台有四个比较重要的安全顾虑。
1、低代码/无代码应用的低可视性
使用外部开发的平台总是会有可视性问题。企业只是在使用软件,但不知道源代码是怎样的、相关的安全隐患或者平台已经完成的测试情况和出现的问题。
这个问题可以通过向供应商索要一份SBOM(软件物料清单)来缓解。SBOM能够提供关于其所有的软件组件信息以及其相关漏洞。SBOM的使用数量正在上升,最近Linux Foundation的研究显示,78%的组织计划在2022年使用SBOM。这表示,SBOM的使用正在逐渐成熟,行业对操作、流程和工具还有很大的优化空间。
2、不安全的代码
和可视性相对应的是代码的安全性问题。低代码和无代码平台依然会有代码存在:只不过这些是抽象的代码,让终端用户可以直接使用预设的代码功能。这对非开发者来说无疑是一个福音,因为他们不必再自己写代码了。但是问题就在,使用的代码可能是不安全的,并且可能会通过低代码和无代码平台跨组织、跨应用进行传播。
解决方式之一是和平台供应商合作,要求平台中使用代码的安全扫描结果。SAST和DAST的扫描结果能够给客户一定的保证,确保他们不是在复制那些不安全的代码。在组织控制之外创建的代码不是什么新鲜事,在开源软件大量使用的时代十分常见。有近98%的组织使用开源代码,同时还伴随着如基础设施即代码(infrastructure-as-code, IaC)模板等其他供应链相关威胁。
另一个需要考虑的方面,在于许多低代码和无代码平台通常都是SaaS化提供。这就需要向供应商要求像ISO、SOC2、FedRAMP等其他行业证明。这些能够给组织的运营和安全控制提供更进一步的保障。
SaaS应用本身也会呈现出许多安全风险,需要适当的治理和安全控制。如果对使用的SaaS应用和平台不进行管制,组织就可能会暴露在风险之下。如果低代码和无代码平台开发的应用会暴露组织或者客户的敏感数据,就会加剧这种风险。
3、无法监管的影子IT
由于低代码和无代码平台允许没有开发背景的人快速创建应用,这就会导致影子IT泛滥。影子IT在业务部门和人员创建的应用同时暴露在内部和外部的时候发生。这些应用可能有组织、客户或者监管的敏感数据,从而一旦发生泄漏事件,就会对组织形成一系列的负面影响。
4、业务中断
从业务连续性角度看,依赖低代码和无代码平台的服务可能在平台发生中断时,打断自身的业务。组织需要和包括低代码和无代码平台的供应商,为业务关键应用建立SLA。
降低低代码/无代码平台风险的一些建议
一些常见的安全最佳实践都能够缓解上述的风险,无论涉及的相关技术有哪些。这些最佳实践包括:
思考企业的安全文化也同样重要。尽管说平台本身的使用者不一定是开发者或者安全人员,他们依然应该理解他们使用和创建的应用与低代码/无代码平台的安全隐患。“力量越大,责任越大”,这一点在低代码和无代码平台上也一样。
数世点评
企业总是以业务为优先——这是必然的。当业务人员自己有能力开发应用的时候,无疑会大大减少因沟通产生的成本以及潜在的团队不和谐问题。但是,运用第三方平台也必然会产生软件供应链的隐患。文章提出了一些预防低代码/无代码平台中潜在的安全隐患,但是,进一步来看,仅仅预防是不够的。一旦第三方平台出现安全漏洞,业务团队和安全团队如何去修复和解决同样会成为问题,企业的业务运作和安全的“刹车”在这个时候依然会再次碰撞。
因此,低代码和无代码平台尽管说必然是未来企业发展的方向,但是同样也预示着软件供应链安全体系依然有极大的发展空间。
来源:数世咨询