Why 60% of security experts are concerned about low-code/no-code apps

Last week Dark Reading released an enterprise application security survey which raised serious concerns by IT and security teams about the state of low-code/no-code applications. The survey exposed a deep lack of visibility, control and knowledge necessary to maintain the level of security maturity expected in the enterprise. In this blog post, we will look at concrete concerns raised by the survey, examine their root cause and offer recommendations on ways to address them today.

The following concerns were raised under the question “what security concerns do you have regarding low-code/no-code applications?”.

Concerns #1: Governance

According to 32% of respondents, “There is no governance over how these applications are accessing and using our data”.

Indeed, many useful low-code/no-code applications are reliant on storing some kind of data. This data could be stored in managed storage provided by the platform or in another platform via a connector. The tricky part is that low-code/no-code platforms make it extremely easy for makers to essentially bake their identity into the applications, so that every application user ends up triggering operations on behalf of the maker. Within enterprise environments, it is not uncommon for useful business applications to store their data in the maker’s personal DropBox or OneDrive account.

Another popular use of low-code/no-code are data-movers or operation-stitchers. They connect together source and destination, either by moving data between multiple points or by linking together an operation in one system to another in a different system.

As an example, a popular automation flow typically observed in enterprise scenarios is email forwarding. Users build an application which monitors their professional inbox for new emails, copies their content and pastes it in their personal email for various reasons. Note that by copying the data, users are easily able to bypass DLP controls that would have prevented email forwarding.

Concerns #2: Trust

According to 26% of respondents, “I don’t trust the platforms used to create the applications”.

Low-code/no-code platform vendors are increasingly directing their attention to provide strong security assurance for their platforms, but there is a long way ahead. While enterprise customers have gotten used to the security benefits provided by public cloud vendors, with their mature security teams, vulnerability disclosure programs and state-of-the-art SOCs, low-code/no-code platforms are just getting used to the fact that they are now business-critical systems.

Of course, vendors investing in the security of their platform is not enough. Customers have to hold their part of the shared responsibility model too. While platform vendors are improving their security posture, enterprises using low-code/no-code platforms must figure out how to approach these applications with the same level of security vigor as they would their pro-code applications. After all, the impact of both types of applications on data, identity and the enterprise as a whole is the same.

Concerns #3: AppSec

According to 26% of respondents, “I don’t know how to check for security vulnerabilities in these applications”.

How do I make sure my code makes sense, and that it is secure and robust, without access to that code? This point is tricky, and history shows that new solutions are required to tackle it.

When public cloud providers started introducing the concept of Platform as a Service for compute services such as managed VMs, managed Kubernetes clusters or serverless functions, the same kind of concerns were raised. Our entire strategy, as a security community, to secure compute instances, was based on our ability to observe and leverage the host machine running our applications. While stripping away the complexities of managing VMs, cloud providers also stripped away the ability of security teams to observe and protect them. As a result, novel solutions were introduced to provide the same level of security assurance with cloud-native building blocks.

The same approach is desperately needed in low-code/no-code applications. Instead of trying to apply existing tools like code scanning or web security monitoring to artifacts generated by low-code/no-code, security teams should adopt solutions that understand the language of low-code/no-code, to identify logical vulnerabilities in those applications.

Concerns #4: Visibility

According to 25% of respondents, “The security team doesn’t know what applications are being created”.

This point is particularly important because, as the saying goes, “you can’t protect what you can’t see”. Most low-code/no-code platforms have zero to little capabilities to allow admins to view applications built on these platforms. Basic questions like “How many applications do we have?” are simply unanswerable without pervasive measures. For example, some platforms allow admins to make themselves the owners of every application separately, but do not allow them to see the application otherwise. So admins must resort to an active change on the platform to take a look at the application. Other platforms go even further, allowing business users to create applications in a private folder which administrators cannot review, other than knowing the number of applications that exist in them. A maker could be exfiltrating data through a private application, and the admin is left with no way to even know anything besides the fact that the application exists.

Concerns #5: Knowledge and Awareness

According to 33% of respondents, “I don’t have any security concerns”.

According to 33% of respondents, “Other”.

According to 33% of respondents, “Don’t know”.

Since low-code/no-code platforms often find their way into the enterprise through business units rather than top-down through IT, they can easily slip between the cracks and be missed by security and IT teams. While security teams are in most cases part of the procurement process, it’s easy to treat a low-code/no-code platform as just another SaaS application used by the business, not realizing that the result of adopting this platform would be empowering a whole array of new citizen developers in the business.

Security and IT teams are always in a state where the backlog of concerns is much larger than their ability to invest. To make sure resources are allocated to the most critical security risks, teams must first be aware of the criticality of low-code/no-code applications to the business and the security risks that they introduce. For the former, this means that low-code/no-code applications’ impact on the enterprise must be demonstrated and clear. Security teams must be part of the discussion when thinking about adopting citizen development. For the latter, we as a community have to research, categorize and share concrete security risks we identify to help others to build more secure applications. Bringing IT and security into the low-code/no-code conversation would allow the adoption of these technologies and to accelerate, unleashing their full potential to increase business velocity and productivity.