Low Code Does Not Mean Low Risk
The past few years have seen the rise of low-code and no-code tools and platforms rolling out across the enterprise landscape. The 2021 Gartner Magic Quadrant report on low code notes that 41% of employees outside of IT customize or build data or technology solutions using low/no-code tools. By the end of 2025, Gartner predicts that half of all new low-code clients will come from business buyers that are outside of IT organizations.
Low/no-code tools use a drag-and-drop interface to allow nonprogrammers to create or modify applications, enabling users to develop new data-driven applications without having to rely on traditional development teams. Low/no-code development enables businesses to easily create rapidly deployable applications by using prebuilt “blocks” of application components.
Low/no-code platforms and tools are aimed at two entirely different sets of users. One set are nontechnical people, sometimes referred to as “citizen developers,” who use these tools to create their own applications, usually to streamline their workflows and connect products that might not communicate with one another.
The other set of users are traditional developers, who use these prebuilt blocks to make their own jobs easier and to help them put together business-critical prebuilt application components quickly. A recent survey conducted by Mendix shows that 64% of IT professionals agreed that low code is their go-to work-around development solution.
As many as 59% of projects using low code are a collaboration between business and IT groups, which means you need to account for low/no-code components in your software supply chain just as you would any other third-party code components.
Low-Code/No-Code Risks
The business risk associated with software supply chains is just as present in the low/no-code world as it is with the more traditional development paradigms that use a container-based architecture or serverless computing.
Implementation of any of these paradigms is dependent on the assurance that the provided framework is built on a secure foundation. There is an assumption that they contain no spurious capabilities that might impact regulatory compliance or directly impact business reputation in the event of a cybersecurity incident.
For instance, using the container world as a baseline example, we’ve seen numerous reports of malicious users planting cryptomining malware inside container images that are then published to public Docker registries. This is a rich target since users who pull containers from reputable registries rarely inspect them. And if container images haven’t been inspected for their precise contents, any deployment referencing them opens the door to multiple cyberthreats, including unintended functionality that might impact data protection.
This is one reason that software supply chains are top of mind for cybersecurity teams.
Scaffolding Interaction to Third-Party APIs
One thing 2021 taught us about software is that supply chains are complex and that attackers consistently find weaknesses by exploiting the trust we place in our development paradigms.
Rolling low/no-code products out to citizen developers poses security risks that could be more complicated than those users realize. A citizen developer might know the data privacy requirements for their application yet be completely unaware of how the scaffolding interacts with third-party APIs, leaving their organizations open to inadvertently violating regulatory requirements. For example, the California Privacy Rights Act (CPRA) defines several new classes of personally identifiable information (PII) and expands data transfer requirements beyond what the California Consumer Privacy Act (CPPA) defined. A citizen developer familiar with the requirements of CCPA and working with a low/no-code framework might not understand how to properly handle these new requirements or even have visibility into how the scaffolding addresses them.
Organizations investing in low/no-code solutions should include the following as part of their vendor selection process:
- A comprehensive security review that aligns with common security frameworks such as NIST 800-218 version 1.1, Secure Software Development Framework.
- A vendor-supplied software bill of materials (SBOM) to describe the complexity of the software supply chain powering the low/no-code framework.
- A review of data-transfer practices and API usage to determine the regulatory impact of data manipulation.
- An understanding of the service-level agreements from the low/no-code supplier for patches related to vulnerability management efforts.
Bottom Line, It’s Still Code
While low/no-code frameworks enable a simple development paradigm for developers and citizen developers, they’re still powered by code. The terms “low code” and “no code” refer to how much code the user needs to know to implement them, not how much code they contain. As with all modern software, low/no-code frameworks are built from code libraries that derive from many sources: commercial third-party providers, open source components and cloud API services. Each of these elements represents an independent stream of code, and each stream can contain its own code streams. Put together, they form the supply chain for a modern service, so any compromise within this chain is a supply chain attack
This is why knowing your software supply chain is so important, even for frameworks with low or no code. There is still code powering those applications, and if the framework provider isn’t equipped to manage the associated risks, then it’s the consumer of that framework who ultimately bears them.